11–20 of 61 posts
If every Linux user would boycott AMD to release their source, then we could have libreboot: https://libreboot.org/amd-libre.html ME vs PSP isn't much of a choice. Of course POWER might be an option eventually, but isn't for most of us currently.
Boycott AMD, and obviously Intel [0]. Doesn’t really leave a lot of options. [0] https://libreboot.org/faq.html#intel
Earlier quoted context omitted.
Isn't that what Bitlocker and Secure Boot do essentially? https://docs.microsoft.com/en-us/windows-hardware/design/dev...
In its typical configuration, Secure Boot can't provide any anti-theft guarantees because an attacker could just replace the contents of the disk with a new Windows installation and the workstation would be usable for them. Secure Boot as it is configured by Windows only prevents malware from inserting itself into the boot process, since all Windows installations use the same signature. Bitlocker only prevents attack…
If every Linux user would boycott AMD to release their source, then we could have libreboot: https://libreboot.org/amd-libre.html ME vs PSP isn't much of a choice. Of course POWER might be an option eventually, but isn't for most of us currently.
Or, instead of boycotting, work towards sensible laws for obliging software/hardware providers to provide sources.
I currently have a custom platform key, packet everything I need for booting into a single image (signed with the custom platform key) and everything else is in a fully encrypted partition (lvm2 on dmcrypt). "Decryption key" is inserted via keyboard on boot, which is not to everyone's liking but is what I want.
It's not really hard to setup (on arch Linux) and works like a charm. ;-)
Through the drawback is that the initRamFs is only protected by the signature/secure boot but not encrypted and combining it with some other boot related setup can be less straight forward then under a "boring" setup.
I.e. some of the thinks this project promises are already possible now, just not streamlined. Which is why it's nice to have such a project.
Slightly unrelated: I currently have a custom platform key, packet everything I need for booting into a single image (signed with the custom platform key) and everything else is in a fully encrypted partition (lvm2 on dmcrypt). "Decryption key" is inserted via keyboard on boot, which is not to everyone's liking but is what I want. It's not really hard to setup (on arch Linux) and works like a charm. ;-) Through the d…
> fTPM tampering is out of scope since the ME is the root of all trust in the system I'm wondering about this assumption. Hasn't the ME previously been shown to be fairly straightforward to exploit?
Earlier quoted context omitted.
Isn't that what Bitlocker and Secure Boot do essentially? https://docs.microsoft.com/en-us/windows-hardware/design/dev...
In its typical configuration, Secure Boot can't provide any anti-theft guarantees because an attacker could just replace the contents of the disk with a new Windows installation and the workstation would be usable for them. Secure Boot as it is configured by Windows only prevents malware from inserting itself into the boot process, since all Windows installations use the same signature. Bitlocker only prevents attack…
Looking at the Microsoft documentation, doing this with SecureBoot could be pretty complicated: https://docs.microsoft.com/en-us/windows-hardware/drivers/br...
[1] https://www.reddit.com/r/thinkpad/comments/epadb5/psa_dont_i...
If every Linux user would boycott AMD to release their source, then we could have libreboot: https://libreboot.org/amd-libre.html ME vs PSP isn't much of a choice. Of course POWER might be an option eventually, but isn't for most of us currently.
I mean I'm not a fan of DRM but then undermining it might cause browsers on Ryzen to no longer be able to run Netflix and similar.
While I guess many people on this site wouldn't care too much it's not profitable for AMD.
But then there should be a way to have both. The case which don't need/want DRM and can have a complete libre system and the case which needs DRM for whatever reason and sadly can't go libre.
Slightly unrelated: I currently have a custom platform key, packet everything I need for booting into a single image (signed with the custom platform key) and everything else is in a fully encrypted partition (lvm2 on dmcrypt). "Decryption key" is inserted via keyboard on boot, which is not to everyone's liking but is what I want. It's not really hard to setup (on arch Linux) and works like a charm. ;-) Through the d…
Regarding /boot being in the clear -- the initramfs and kernel shouldn't contain any secrets, so having them unencrypted isn't a big drawback. Signed is much more important so that an adversary with write access to the disk can't swap out the kernel.
One advantage to using the TPM for unsealing the disk encryption key is that it helps protect against attacks that re-write the firmware. If an adversary can reflash the platform key (via either a local SPI flash programmer or some code execution that gives them write access to the NVRAM region of the flash), then you can't tell that the PK has been changed and that the kernel to which you are inputting the password is no longer trustworthy. Since the secret is sealed with (among other things) the hash of the UEFI SecureBoot configuration, the TPM will not unseal it if the PK, KEK or db are changed.
If you want to take it to another level, TPM TOTP can be used to validate that the password dialog is even valid before you type in the password. I think we can integrate that fairly easily into the initramfs for the next version of safeboot.