Skip to content

OE4T Meeting Notes 2022 09 08

Jump to bottom Edit New page
Dan Walkes edited this page Sep 8, 2022 · 4 revisions

Video

https://youtu.be/VIWKJ9FVjuU

Attendees

7

Topics

  • Jetpack 5 test status
  • Jetpack 5 Revision 1 just posted this morning with Deepstream 6.1.1
    • Deeptream 6.1.1 is building from recipes and tests with samples worked.
    • Changed a bunch of BSP packages. Some have new date and timestamps in version strings. Thought there may have been others which didn’t have new dates/timestamps but have new md5sums. -Clarified after the meeting this wasn't actually an issue - see thread at https://gitter.im/OE4T/community?at=631a4a33999499629355efef
    • No update to "Jetson Linux" (formerly L4T). Changes are probably only in multimedia API and gstreamer support for Deepstream support.
    • Release notes aren’t clear about differences between Rev 1 and prior version, believe it was probably all related to Deepstream 6 support.
  • OPTEE sample apps and Jetpack 5
    • Some strange toolchain issue with OPTEE build from source.
      • Works with GCC9 or earlier, anything after version 9 fails, does not pass tests and causes system to hang.
      • Attempted to track down problems. Did a test with OPTEE on QEMU64, that worked fine. Likely some issue with NVIDIA sources. Works with kernel 5.10 and 5.19 without NVIDIA sources.
      • Sources are still outstanding as PR, plan to keep source OPTEE support out of the master branch until issues are resolved.
      • Preparing documentation to share with maintainers of OPTEE.
    • Potential issues with host contamination, Tim is not able to build. Tim/Ilies to work to understand.
  • Tim upstreaming work for OPTEE/ELC
    • Kirkstone and Jetpack 4.6.2 in progress, Tim is working to wrap this up.
    • Not sure if Matt is planning to port keystore to OPTEE, probably not.
    • Have patches on top of Matt’s tegra test distro. Ultimately should be targeting tegra-demo-distro
    • New initrd for crypt, tegra sysinstall tools, quite a few things which need to be there.
    • Is it the right thing to spend time on Kirkstone given Jetpack 5 availability?
      • Biggest issue is that keystore won’t be on OPTEE anytime soon.
      • Haven’t verified that the OP-TEE port of luks-srv app works the same. Hoping for a drop-in replacement. In that case it shouldn’t be hard to forward port to Jetpack 5. May make sense to wait until forward port to Jetpack 5/master after ELC.
    • Should be other avenues that are more upstream compatible than NVIDIAs special LUKSERV app. Will take some investigation to learn about which services NVIDIA is offering, whether OP-TEE has access to that. Not sure about the direction NVIDIA is going with OP-TEE support. Encrypted filesystem support structured similarly on Jetson and moving to imx8. Imx8 security engine does have a hardware unique key. The way NXP provided the support into Linux enables doing that without OP-TEE app at all, which is nice, however NXP specific. Upstream support in the linux kernel as a config option. Secure keys or encrypted keys either come from OP-TEE or from CAM. CAM is the security processor on NXP.
    • Hesitate to invest time and effort based on what we see today with both pieces (OP-TEE and UEFI), not knowing what direction NVIDIA is going to go. Might be worth a discussion with NVIDIA. Are they going mainstream with UEFI stuff/OPTEE stuff and are they providing a bridge which will ultimately go away?
    • Related standards in ARM Trusted Substrate and SystemReady. How many vendors will follow along with this or will something else emerge. How applicable is this to the embedded space, is it targeting desktop and server systems.
    • Would be helpful to know about replacement path for luks-srv going forward. Is the luks-srv TA in the OP-TEE tree the only path forward or backwards compatibility? More modern upstream way would be to have the OP-TEE TA provide trusted keys directly to the kernel rather than going through userland. Cryptsetup or dmsetup can make use of kernel resident keys for doing the encryption setup. Trusted keys and encrypted keys in the kernel. Under the kernel source tree Related links: https://www.kernel.org/doc/html/latest/security/keys/trusted-encrypted.html and https://www.linaro.org/blog/securing-a-device-with-trusted-substrate/
    • Secureboot with jetpack 5 - have an Xavier NX EMMC which is fused. Found a couple of issues that need straightening out in the flashing scripts when interfacing with signing scripts. All should be fixed now. On t19x you should be able to run a build, do signing as a part of the build or after the fact, then successfully download signing or encrypted. Haven’t tried with Orin.
  • UEFI issues when building from source
    • Only a problem with Orin.
    • Ilies is looking into this.
    • Might be a toolchain issue. For Orin only NVIDIA provides .a files with some binary only crypto routines. May be that we need to use a different toolchain, can’t use GCC 12.
    • Not using upstream UEFI today, using NVIDIA sources. Have a repo with upstream and overlaid NVIDIA source on top. Mostly 3.16 upstream, NVIDIA has their own separate repo rather than putting in the edk2 repo.
  • Display status on Jetpack 5.
    • Working X and Wayland on Orin
    • Can run real GDM. Able to build kmscube without making any changes. May be new things we can do now with different compositors
    • nvdcsi and nvallocator - not sure what this uses. All GDM backend stuff is symlinked to this component. Different ways to hook in and be happy with buffers created. New in GDM is fact that EGL has all the right extensions, responding through calls in EGL to get buffers, didn’t do this correctly before.
    • sway “just works” with GDM, may be possible to run sway now, haven’t tried yet.
    • Haven’t tried xwayland at all.
  • Discussed strategy for using sstate across SOC builds for build speedup
    • PACKAGE_ARCH is key for this, need to ensure you are using this for SOC specific builds for any custom recipes.
Add a custom footer
Add a custom sidebar
Clone this wiki locally