this post was submitted on 13 Aug 2026
242 points (99.2% liked)

Technology

87279 readers
3609 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related news or articles.
  3. Be excellent to each other!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
  9. Check for duplicates before posting, duplicates may be removed
  10. Accounts 7 days and younger will have their posts automatically removed.

Approved Bots


founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] Laser@feddit.org 18 points 5 days ago (2 children)
  1. The spec allows changing keys by the user as far as I know
  2. I'm unaware of a proposal of a better concept that stops attacks at this layer
[–] WhyJiffie@sh.itjust.works 2 points 3 days ago

well Android Verified Boot also allows changing keys! but like 15 niche phones implement that function out of thousands. out of which it is broken on several such thatit bricks the phone permanently. further, android hardware attestation can make use of AVB, but virtually no apps use it, every app doing such a verification depends on google play integrity, for which you can't change keys and still pass the ckecks.

google has already implemented on android what microsoft is only just dreaming of to pull off, despite preparing it since much earlier. I don't know what they are waiting for, everyone knows there would be no negative consequences to them.

[–] Truscape@lemmy.blahaj.zone 2 points 4 days ago (2 children)

For #2, Full Disk Encryption (including bootloader)

[–] Laser@feddit.org 4 points 4 days ago

These protections work at different layers and hence, you use both.

First off, you can't really encrypt the first boot loader by design, your UEFI needs something it can read and run. You need to protect this first boot stage somehow, and this is what Secure Boot is for; it verifies the signature of the payload it starts to protect it against tampering.

[–] wonderingwanderer@sopuli.xyz 1 points 4 days ago

My disk and bootloader are both encrypted but I can get to my UEFI menu without decrypting. I've been meaning to password protect that but I get nervous about changing anything in UEFI.

I didn't know much about secure boot or TPM or PAM so I was planning on setting those up, but I'll skip it if it's just about corporate capture. Not that my hardware is from some big name corpo or anything, it came with linux by default. But still.

Also I'm worried about locking myself out of booting from live USBs, especially if I ever need to use a recovery drive. But I think if I understand correctly then most official ISOs should still work, but I'm not 100% certain.

Clearly, I still have a lot to learn...