441
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 05 Aug 2025
441 points (99.6% liked)
Greentext
6887 readers
956 users here now
This is a place to share greentexts and witness the confounding life of Anon. If you're new to the Greentext community, think of it as a sort of zoo with Anon as the main attraction.
Be warned:
- Anon is often crazy.
- Anon is often depressed.
- Anon frequently shares thoughts that are immature, offensive, or incomprehensible.
If you find yourself getting angry (or god forbid, agreeing) with something Anon has said, you might be doing it wrong.
founded 2 years ago
MODERATORS
This is partly Microsoft's fault, for sure, but it's also more of a function of how secureboot works. A Linux system using TPM backed FDE with secureboot enabled would have the same problem going the other way.
Secureboot prevents a lot of ways the TPM could be compromised, so as part of "securely" turning it off, it wipes the keys (otherwise those protections would be pointless, the first thing an attacker would do would be to turn off secureboot).
The main problem is it turning itself on with no input from or feedback to the user, and not giving the user access to the key without using a Microsoft account. I've heard of people getting screwed by this because they set up with a local account and thus never got their secureboot key (or did, but it was hidden somewhere and they were never told to save it).
Oh yeah sorry I should have elaborated when I said it's partly Microsoft's fault. ATEOTD, this mostly happened because neither of them expected the FDE to be enabled which is on Microsoft for silently enabling it