Vogtinator

If, for example, a company wants to issue fleet computers to workers or school to students, you want to have secure boot on those devices to prevent tampering. Secure boot makes it so that physical access is not the end all of security.

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.

AFAIK that's just when plugging in a USB 3 device into a USB 2 port or using a USB 2 cable.

With https://github.com/thkukuk/account-utils (not the default yet), it's meanwhile possible to run openSUSE Tumbleweed (package based) with NoNewPrivileges= as usual.

For example, Aeon (of openSUSE MicroOS vintage) looks like all KDE Linux is aiming for, just with Gnome as DE.

And Kalpa is that just with Plasma as DE.

swapfile on linux must be directly mapped, bypassing any filesystem level checksums (see https://btrfs.readthedocs.io/en/latest/Swapfile.html)

ctrl-c sends SIGINT.

errno is in thread-local storage (TLS)

Apps on Android have no access, or ability, to directly call kernel functions.

That is nonsense.

That's the design with sdbootutil in openSUSE (https://en.opensuse.org/Systemd-fde, https://github.com/openSUSE/sdbootutil).

You can mitigate this by including PCRs that sign the kernel and initrd.

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).

For multiple users on the same server it was IMO well designed. Everyone had their ~ and could place whatever libraries/binaries/etc. in there and do whatever they wanted.

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.

For x86 cores this is visible in Agner Fog's instruction performance tables: https://agner.org/optimize/#manuals

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.

Can wine do ARM64X resp. ARM64EC to mix native aarch64 code with emulated x86(-64) code in the same process for better efficiency?

https://duktape.org is in a similar ballpark.

My envy x360 has that button as well and it even puts a physical shutter in front of the webcam in addition to disconnecting USB.

Cargo.lock has 8750 lines. Is that normal for something like this?

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

you do you, but watch your market share always be niche.

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

That said, it does require more care when you do OS updates or UEFI updates to remember to update the TPM sealed secret with the new measurements. Windows and Linux both have the former automated so it should generally be fine.

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..

1. This is interesting. So in a measured boot scenario, you wouldn't be able to boot the main OS, but it would give you access to sort of a minimal initramfs environment for debugging? It's a good idea for personal computers, like a tamper-proofing approach.

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.

Measured boot > trust chain through signature verification:

With measured boot, components in the boot chain tell some trusted component (e.g. a TPM, possibly in FW) about all of their input and only if the hashes at the end match, $something is accessible (in most cases a secret key for data decryption).

1. More flexibility (with TPM e.g. you can "seal" a secret against different parts independently)

2. No need for PKI, which gets very complex once revocations are involved (have fun looking at the "Secure Boot" DBX lists and the shim SBAT mechanism)

3. More freedom: The system still boots if the measurements don't match, you just don't get access to secrets. You're free to seal your own secrets against your new measurements and whoever did the last sealing has no access anymore. (Unlike on PCs where the Microsoft trust is in most cases not removable).

Would that actually have a positive effect? Running malicious software in the only user's context can already cause maximum damage: https://xkcd.com/1200/

This would just result in more UAC prompts and thus annoyed users who get taught to click on "Allow" whenever a dialog pops up.

I'm using Tumbleweed with btrfs snapshots, systemd-boot and transparent disk encryption (using TPM + measured boot), works fine.

Currently this needs to be set up semi-manually (select some options in the installer, then run some commands after install), but it'll be automatic soon.

iwd is an alternative to wpa_supplicant, not NetworkManager.

NM has support for iwd.

I did something similar some time ago: Booting from an RPM repository on a Tumbleweed installation DVD.

My initial goal was to write a fuse filesystem for mounting RPM packages, but I wanted to see how far it goes. Turns out, pretty far indeed: https://github.com/Vogtinator/repomount/commit/c751c5aa56897...

The system boots to a working desktop and it appears like all packages available on the DVD are installed.

The Pi 5 is still not supported mainline. Proper mainline support for older models was contributed by third-parties, not the RPi foundation, which just care about their kernel fork.

Doesn't work either: To establish the secure connection, you need some way to verify the other end (through public keys, certificates). That verification happens before any measurements can be done securely, so it can be bypassed.

Only recently. It started out as soldered to the main board.

Not shown: "systemd-run --shell" asks for the root password (or whatever set up for polkit authentication).

That some other process of the same user can influence that session with elevated privileges isn't really an issue. In fact, the terminal in which systemd-run was invoked is also owned by the user and can be "taken over" in the same way.

It only looks like that if you treat it as a C-like programming language, which it is not. Unless specified otherwise, all the statements are "executed" in parallel by the synthesized logic. There is no emulation.

some of the QT libraries or older forked versions of them are still completely under open source license

Qt is LGPLv3 + GPLv3 which are clearly open source licenses.