When the topic of banned function like memcpy https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/memcpy-wmemcpy?view=msvc-170 come up I have to smile since sometimes 'compatibility' (aka 'the software you choose to run) argues that this is still inherent service for software. This includes 'copymem', the UEFI variant of memcpy, as a fundamental system service in UEFI https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html#efi-boot-services-copymem and encouraged in https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/4_general_driver_design_guidelines/44_optimization_techniques/443_copymem_and_setmem_operations.html#443-copymem-and-setmem-operations.
So if existing software still uses these services, what to do? One option is to provide isolation to contain the damage, viz, https://uefi.org/sites/default/files/resources/Enabling%20RUST%20for%20UEFI%20Firmware_8.19.2020.pdf
with EBC or ring's https://cdrdv2.intel.com/v1/dl/getContent/671411
or virtualization http://masters.donntu.ru/2020/fknt/yakubov/library/article5.pdf https://dblp.uni-trier.de/rec/conf/csreaSAM/Zimmer08.html
Moving forward, though, leveraging modern languages and types to enforce safety https://stanford-cs242.github.io/f18/lectures/07-1-sergio.html still feels like the right trend. Speaking of Rust in firmware https://cfp.osfc.io/media/osfc2020/submissions/SLFJTN/resources/OSFC2020_Rust_EFI_Yao_Zimmer_NDK4Dme.pdf, the GSOC produced first-class UEFI support in Rust in the form of the UEFI crate https://crates.io/crates/uefi for applications. As noted in the above prezo, the retrofit is touch for a large codebase, but a smaller unit of execution like a UEFI application, namely OS loaders, makes sense, especially in light of incidents like https://vulcan.io/blog/boothole-vulnerability-cve-2020-10713/.
And it looks like beyond all-Rust efforts like https://github.com/oreboot/oreboot, coreboot is now pursuing adding Rust support https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/3QRO6A5BCFWCGHE7ZUCFGR7VL7AJ2XKQ/. The mention of payloads first makes sense since this is a stand-alone entity and doesn't entail the challenges of mixing non-borrow-checker aware C code with Rust.
This Rust-as-a-payload aligns with https://universalscalablefirmware.github.io/documentation/ POL thinking, too
I cannot recall if I mentioned in the past how even chatting w/ the Google Chrome folks from Kirkland WA and VMWare Research guy from their Bellevue office during UW lunch event how they eschew the mixing and instead are targeting Rust for more stand-alone execution regimes like plug-ins for the browser and a service for the virtualization environment, respectively.
As noted in the Stanford lecture, types can help but there has been a complaint that subsets of type-safe languages like Ada Spark are the true gold standard. That's where work on 'Ghost types' is so interesting with the Rust community. I first heard about this from Parno and followed-up on some of this work in https://arxiv.org/abs/2303.05491 https://arxiv.org/pdf/2303.05491.pdf https://github.com/verus-lang/verus and discussions with the community in https://docs.rs/ghost/latest/ghost/ https://github.com/rust-lang-nursery/wg-verification/issues/14. Ghost types will allow for no-harm source augmentation to have more verification-ready language conditions, as opposed to going to some intermediate or non-standard verification-friendly language like Dafny or F*. The important part of adding software assurance is to avoid taxing the developer as much as possible.
As always, keep watching the Rust space for firmware.
Beyond languages, I recently received
shirt in the mail.
A few interesting fragments caught my attention, such as hedge funds bringing cases to PTAB. This reminded me of Trammell Hudson and his Two Sigma hedge fund https://www.twosigma.com/ and some of the rationale for research like Thunderstrike https://trmm.net/Thunderstrike2_details/ agsint folks like Apple when we chatted in person years back.
Other discussions about recusal for conflict of interest made me smile. I hearken back in the mid 90's when in my Compaq Computer Corporation new employee orientation down in Houston how I was chided not to transact stocks in 'customer, competitor, supplier,...' of Compaq. At the time this pretty much covered most companies on the stock exchanges. This early career lesson has stuck with me in that for the past 30 years working in tech I have been afraid to buy any shares outside of my employer and outside of my employer's stock program.
The other interesting podcast I caught was https://www.lawfareblog.com/lawfare-podcast-rob-joyce-nsa-director-cybersecurity. Hearing the director of the NSA casually opine on large language models and post-quantum cryptography is such an amazing change from my recollection of the NSA growing up. In my early years it was 'no such agency' typified by reading books like https://www.amazon.com/Puzzle-Palace-National-Intelligence-Organization/dp/0140067485. Quite the change.
Well, so much for banned functions, Rust, and podcasts. On to the next weekend to-do's.
