Measured boot is actually better for that: You can still boot whatever you want however you want, but hashes are different which can be used for e.g. remote attestation. Secure boot has to prevent that "unauthorized" code (whatever that means for each setup) can ever run. If it does, game over. That means less freedom and flexibility.

And Kalpa is that just with Plasma as DE.

That is nonsense.

Comments URL: https://news.ycombinator.com/item?id=42918300

Points: 8

# Comments: 1

No, that's not an effective mitigation. The signed kernel+initrd would still boot into the impersonated root.

> however it means whenever you update you need to unlock manually. On Redhat-based distros this can be done with PCRs 8 and 9, though IIRC this may change on other distros. > Also AFAIK there is no standard way to guess the new PCRs on reboot so you can't pre-update them before rebooting. So you either need to unlock manually or use a network decryption like dracut-sshd.

With some logic to update the values on kernel updates and re-seal the secret this can be handled transparently. That's the design with sdbootutil in openSUSE (https://en.opensuse.org/Systemd-fde, https://github.com/openSUSE/sdbootutil).

Package managers are way more modern than that and their design does by itself not require root (see pip). You can in fact run most package managers without root, you just won't be able to modify system files. You can use them to install a chroot as regular user, e.g. `zypper --installroot ~/tw install bash`.

FUSE doesn't really relate to single vs. multi-user AFAICT.

Users are perfectly sandboxed if you configure the system that way. Depending on the distribution that's even the default.

The latency shows after how many cycles the result of an instruction can be consumed by another, while the throughput shows how many such instructions can be pipelined per cycle, i.e. in parallel.

For comparison, QEMU basically just needs glibc, glib and zlib for basic functionality.

As long as I can use the OS I like and how I like, I don't care about metrics like market share.

Yep, this can be a pain also in regards to firmware bugs (broken TCG event log anyone?). In the worst case you need to enter the recovery key or if you know in advance, exclude some component from measurement temporarily while supervising the next boot. If something goes wrong with the trust chain like a key got revoked but the bootloader didn't update correctly, you end up with an unbootable device and can't even go back easily.

> UEFI updates can also be a problem if they wipe the TPM as part of the update and thus destroy the sealed secret entirely (as my PC mobo does).

Ouch, that's bad design. The firmware is measured into the TPM on boot so there's no reason to do that..

Depends on how it's set up. Currently most setups that use measured boot (systemd-pcrlock, partially BitLocker) ask for a recovery key if unsealing fails due to measurement mismatches and offer other options.

> I assume the TPM in this case would only have a partial decryption key?

That's also possible, but so far I haven't seen that. The sealed secret is sent to the TPM which then uses its hidden internal seed to derive the master key for volume decryption and sends it back. (In the case of bitlocker with TPM < 2 that could trivially be sniffed on the LPC bus...)

> I think something similar could be accomplished with SSS, no?

If you mean Shamir's secret sharing, possibly. Question is what to do with the shares.

2. Yeah, for your local machine this is a working approach, if you make sure that really only your own key works. Another reason against PKI is also that the trusted authority can't retroactively sign a backdoored executable to gain access to devices, as the measurements are independent from authority and ideally device specific.

3. Signature verification isn't just needed at the start of boot, it's ideally from start of booting until user authentication, which is the part that can be tampered with. I'd argue that the software side for measured boot is simpler, while the hardware side may be more complex.

> For example, iphones or google-pixel devices encourage the user to use a low-entropy password like a 4-digit PIN.

Using TPM+PIN is actually not that bad: Only if measurements match it's possible to unlock with a PIN and the TPM uses a counter in nonvolatile memory to prevent brute force attacks. It's not unfathomable that some manufacturer screws that up, but it's IMO stronger than relying on multiple parties (CPU, BIOS, OEMs, OS) developing an actually secure trust chain.