- WINDOWS 10 STOP QUICKBOOT SERIAL
- WINDOWS 10 STOP QUICKBOOT SOFTWARE
- WINDOWS 10 STOP QUICKBOOT CODE
- WINDOWS 10 STOP QUICKBOOT PASSWORD
The TPM can then refuse to give up its secrets if that measurement doesn't match what it expects.īooting is complicated, and when you're mucking around with stuff like grub, it's easy to accidently break the chain without realizing it. Grub can be configured to give the TPM a measurement of what it's actually loading, i.e. I don't think the configuration matters much either.
The grub image itself being on an unencrypted partition doesn't matter, though, because it is signed secure boot won't run it if it isn't authentic. It's been around a long time, and existed before secure boot. Your point about grub being insecure in some ways is likely true. Secure boot is literally what keeps the system secure while booting, before the TPM is configured.
WINDOWS 10 STOP QUICKBOOT CODE
Secure boot is the mechanism by which that boot-up code can load more code off a storage device and authenticate it. The initial known state is provided by boot-up, where the first code to run comes from ROM or an EEPROM or flash chip. The idea is that everything is chained off of an initial known to be trustworthy state. All the TPU can do is watch the sequence of measurements being fed to it, and decide whether or not it looks suspicious.
WINDOWS 10 STOP QUICKBOOT SERIAL
The TPM is notionally just a peripheral hanging off a low speed serial bus. Malicious code running on the CPU can tell the TPM whatever it wants to tell it. I think the critical point is that the measurements are made by the CPU, not the TPM. The OS changes the measurement before it starts running untrusted code, and so the TPM no longer gives the same access. The TPM will only give the CPU the key when it asks if the current string of measurement matches what the TPM expects. I think we're both saying the same thing, just with different terminology. I mean the API for accessing the disk encryption key is disabled, not that the whole TPM is disabled. On some "embedded" computers, it's practically impossible to turn secure boot once it's been enabled there's literal fuses inside the chip that get blown.
WINDOWS 10 STOP QUICKBOOT PASSWORD
That's why bios typically have their own password protection. Secure boot alone doesn't really help much for foiling bad actors with physical access, since you can just go into the bios settings and disable it.
WINDOWS 10 STOP QUICKBOOT SOFTWARE
As you say, though, the vast majority of software running once the OS is booted isn't necessarily secure. They would still need to get that image on your computer of course. If you don't have secure boot enabled, someone could boot a malicious image that has access to the TPM's API before it's disabled, and therefore gain access to your storage. Secure boot provides the mechanism to make that possible. From that point on the kernel has the key in RAM, and there's no way for unprivileged code to access it (other than bugs). Typically, once the OS reads out the storage encryption key, the OS then immediately asks the TPM to disable its API until a subsequent boot. You can't depend on any secrets outside of the TPM before decrypting the storage (otherwise you wouldn't need a TPM), so instead you need to guarantee that the code accessing the TPM's API isn't malicious. If you're storing your disk encryption key in a TPM, there needs to be an API for the OS init routine to access the key from the TPM. That's still necessary even if you have a TPM. It prevents the system from starting to run code that isn't trusted in the first place. Secure boot doesn't prevent code from doing whatever it wants once it's running. Have this setup on my Debian box but used actually the superior documentation form the Arch wiki to get there. No need for complex setups that validate the initrd after the fact, as everything is included in the UKI and signed as a whole. No change to the boot-manager needed.Īlso a UKI has a better security story compared to all other options. You only need to recreate the UKI with an updated command line.
> to change the cmdline with kenel parameters you now need to run efibootmgr You can, for example, have even one with a whole recovery system included in the initrd part! > no more choice between different kernels in case the newest one broke something Just go and select your UKI in the EFI boot-manger. > the same disk is now impossible/harder to boot in another system/mainboard. It's the most simple boot setup I've ever used, and it doesn't have the mentioned issues: I'm using an "Unified Kernel Image" directly through the EFI boot-manager.
0 kommentar(er)
