- Joined
- Mar 17, 2019
Great point! The Michelangelo virus has only been around for thirty years. And Snowden exposed NSA weapons that use a variety of firmware attacks.What dies this secure boot shit really achieve though? I mean is it really neccessary to have some more shit added to the hardware to fuck with programs?
you can guarantee this is going to fuck up a lot, and as much as they wank themselves off about how secure it is you can bet its going to be compromised at some point like most 'secute' software ever especially since alot of hardware is backdoored anyway.
and at that point what is the fucking point. We've added more bloat to hardware and made it less efdicient all in the name of a security problem that never existed?
But I guess MBR/UEFI violations aren't an issue.
Can you cite a case where SecureBoot has stopped people from using Linux? I understand that if it's enabled, it's more difficult to build your own kernel, you have to go through a couple steps to add and approve a signing key. Not trying to prune my kernel down to the lowest number of KB to run on a 486 with 8MB of RAM anymore, so I'm probably fine with that.View attachment 2516718
Welcome to the fucking future. At what point do we [redacted] [redacted] [redacted] [redacted]?
Now, there is a certain problem that I feel should be solved, but which even if a solution is developed could, in theory, be blocked by a cabal of 'approved' Linux (well, grub or 'shim') developers under SecureBoot. That's a mostly-deniable version of full disk encryption.
Truecrypt does have hidden volumes, but what the people really need for their phones and laptops is an option where you can enter one passphrase at boot, and get a mount of a partition that seemingly covers the entire drive, but which writes L->R, so it can be played around with by a customs official or other adversary but won't expose hidden data or even damage it, unless they fill up the entire drive. Or, if you enter a different passphrase, it mounts the hidden partition, R->L. That could be restricted in size so it doesn't damage the deniable partition.
I acknowledge that such a solution isn't perfect- there would be some patterns in flash wear that might be usable to expose that it had been used- but it could seriously impact on the ability of malicious actors to force an unlock.
If such a solution is developed, but blocked from integration into Grub etc by devs with the ability to get things signed? I'll consider SecureBoot malicious.