Seems like this could be easily mitigated with a read only root filesystem using dm verity
Store the root hash of the dm verity formatted rootfs in the PCR. If a malicious partition is presented to initrd, its root hash will not match the trusted one stored in the TPM.
Or if you need a writeable rootfs, use fs verity and store the signature of init into the PCR. The trusted init signature won’t match signature of malicious init.
LUKS for encryption and verity for integrity/verification.
The fact the initramfs is not signed/verified on any desktop Linux distro means secure boot is completely pointless right now on Linux, and is very dissapointing.
I know Fedora has been musing with shipping prebuilt initrds, but it raises problems with things like Nvidia where you need the driver to be in the initramfs to have a proper boot screen. There's also UKIs that have the kernel + initramfs in the same EFI binary (and thus signed) for booting by secure boot, but they can become too big for the small EFI partition computers ship with.
> The fact the initramfs is not signed/verified on any desktop Linux distro means secure boot is completely pointless right now on Linux, and is very dissapointing.
It is not. There are other, very real and very important problems with that fact and reasons why it should be fixed, but this is not it. The point of SecureBoot is to protect the firmware from userspace. It works very well for that purpose, as evidenced by the facts that exploits to bypass it have to continuosly be found.
Android too in a way via Android Verified Boot. I think ChromeOS uses AVB as well.
Android Verified Boot extends the System on chip Hardware based secure boot to the kernel and rootfs.
Root of trust is fused into the SoC, and second stage bootloaders are signed. Second stage boot loader eg uboot,UEFI/edk2 contains a public key that is used to verify a signed AVB partition. This signed partition contains signed rootfs dm verity metadata and signed hash of the kernel(+initrd). AVB validates kernel hash with expected hash and loads kernel if good. It provides the trusted rootfs verity hash to kernel via cmdline. Then when kernel reads rootfs, the dmverity system will calculate hash and check if matches the expected one. If not, the system reboots and the AVB metadata is flagged to indicate tampering/failure of the rootfs.
edit to add:
If the SoC supports hardware based full disk encryption, the filesystem can be encrypted as well, with the key being stored in Androids secure key store. Android though has moved away from FDE in favor of file based encryption.
The ingredients are there as Chrome OS and Android have shown, but robust hardware-bound disk encryption has just never been a priority for the general purpose distros.
That's similar to how Apple does it. The base system is signed (and has a tree of signatures so you don't need to strictly re-calculate the entire RO volume your base OS sits on), and the signature is recorded in the boot configuration.
Granted, you could disable that, but they have thought of that too, you can only disable it from a recovery OS that is signed the same way. But disabling that doesn't disable it for the recovery OS, so you can't evil maid the recovery OS later to make it appear as if it is still enabled.
I’m not sure if this is the exact process for openSUSE Aeon, but it’s very close philosophically so I image the rest is a question of hardening this over time.
Not sure about TA, but definitely saw radio station in Indianapolis using RDS to broadcast advertisements. In between the artist/song info, ads for an injury lawyer appeared. Thought it was super lame use of RDS.
I found the learning curve to be much easier with buildroot and compared to yocto whose build system is python but uses mixed shell/python to describe the build.
Builroot errors seemed to happen much less, and easier to understand compared to Yocto errors. Also seemed easier to corrupt the Yocto environment to the point of having to wipe and start fresh
Buildroot kconfig and TUI menuconfig was super simple to find and add packages to the rootfs, even custom ones patched in to tree to out of tree directories that could be added in with a config option.
Yocto AFAICT does not have a package discovery via TUI. You have to guess at package names, add them to you config and wait for build error to say not found. It will at least sometimes recommend similar named packages or the actual package name that eg provides the library you wanted. Otherwise it’s a search on openembedded to find package recipes that are not in the Yocto poky reference.
Adding OOT tree code to Yocto is pretty simple, once you figure out to write shell/python recipe
The makefile/Kconfig way of buildroot seemed much more intuitive especially given the kernel, busybox and uboot all use kconfig. So if you’re used to those, buildroot just seemed a natural extension to the rootfs.
> Yocto AFAICT does not have a package discovery via TUI
Depends what you mean by package discovery, but `oe-pkgdata-util find-path` may be helpful in determining what package would produce a certain binary.
Other than searching on open embedded like you mention, I am not aware of a way to do this if you have not already added the layer containing the recipe.
Not OP but Hatchet was an assigned book when I was in 5th grade (American Midwest school), it’s pretty common for early school age kids to read. It’s got some slightly intense scenes in it, but nothing that 5th grade me was too scarred by (the scene where he has to go into the lake to get something from the plane and sees the corpse of the dead pilot was pretty scary to 10-year-old me but that’s about as bad as it got.)
Hatchet was one of my favorite books growing up. I believe the first time I read it I was in 4th grade if that helps you gage (it was pretty common in 4th and 5th grades if I recall correctly). That said, my mother was a librarian and didn't care what I read as long as I was reading (including Faulkner and East of Eden when I was in 6th grade which was way too mature for that age :-)) so depending on your son maturity your milage may vary. That said, Hatchet is a great a book and I give it some credit to my life long love of the outdoors and adventure.
He’s 7.5yo. Don’t think he really understood The Secret Brian’s mom had, and probably still hard for him grasp severity of the situation, but he was very engaged and enjoyed the book. I don’t recall how old I was when i first read it… but I do recall accidentally finding a Gary Paulson book in the adult literature section of the library and quickly realizing it was not for a young juvenile :D
Don’t let your kids read Roald Dahls adult literature either, Switch Bitch is no Giant Peach
I found Hatchet when I was in grade 4, and damn near read it straight from the library checkout counter until I was done a few hours past midnight. I'm pretty sure that my parents made me take a break for dinner.
I’m a first time kimchi maker, used the a Baechu ( napa cabbage ) Kimchi recipe from “Fiery Ferments” ISBN-13 978-1612127286
Came out really good despite not having some of the ingredients because I’m disorganized (left out carrots, ginger, scallions). My Taiwanese neighbor suggested adding apple to sweeten it up a bit, cut the sour, and less Korean pepper flakes.. but I like mine spicy.
Working on a second batch now.
The book has a couple other kimchi recipes in addition to dozens of other fiery ferments.
For full software no hardware kvm solution, there is Microsoft Garage Mouse Without Borders. Wish it was open source. Mostly useful for multi monitor setup where you don’t need to change sources just change keyboard and mouse. For soft switching source I use a script to send DDC commands to the monitor
Isn't that functionnaly the same as Synergy (which was opensource but isn't anymore), and it's opensource fork Barrier (https://github.com/debauchee/barrier) ?
I suspect this ZF motor is like what is described in this paper [1]. An air gapped transformer is used to transmit power to the rotor and diodes rectify it. See Figure 1.
This [2] appears to give a good summary of PSM vs ASM vs EESM and introduces iEESM (i is for inductive excitation instead of brushes, sounds like the ZF motor) at slide 14.
[1] Design of Inductive Power Transmission into the Rotor of an Externally Excited Synchronous Machine
reply