If only it were garbage in, garbage out - that would be solvable by better training data.
But it's much worse than that, because even if you'd only feed it good stuff, the output would still deteriorate.
pointing index finger at imaginary baloon: pfffffffffft
Congrats on being a parrot in the "oh noes, taken over by bots!" securitah echo chamber.
W7 is just fine. Daily driver on multiple machines, never been "taken over" or turned into a crypto miner or a hub for a bot network, never had a single virus or other issues.
I use Firefox and uBlock Origin, but I'm also routing everything through AdGuard Home on an RPi5 (my router points to the RPi for DNS), and it's been an eye-opening experience.
Just checked AGH, and it's blocking 49.56% of my DNS queries for everything that's connected. I cannot recommend AGH on an RPi highly enough. It's amazing.
Nevertheless, it is trivial to make any BIOS-based computer at least as secure as the most secure UEFI/secureboot-based computers.
For that, any SSDs/HDDs included in the computer should be non-bootable and fully-encrypted.
Then the BIOS will happily run whatever an intruder will attempt to run, but nonetheless the intruder will not have any access, neither for reading nor for writing, to the data hosted by the computer.
The owner can boot from a removable USB memory, used as a computer key, whose content cannot be modified by someone else as long as the owner keeps it.
All Intel/AMD CPUs have backdoors in the form of the System Management Mode and of various hardware management engines, which can be exploited by a malicious BIOS or UEFI firmware to monitor what the operating system that is controlled by the user does, but SecureBoot also offers no protection against such backdoors. ARM CPUs are no better, because many of them have copied Intel, so they have the equivalent of the SMM: EL3.
If you run yourself a hostile application after booting, then SecureBoot also does not offer any protection against that.
> Nevertheless, it is trivial to make any BIOS-based computer at least as secure as the most secure UEFI/secureboot-based computers.
Mmm....no.
I use my own keys and removed vendors keys from my secureboot setup. Hard disk is encrypted and automatically pulls keys from the TPM to boot into a guest OS, which is running something akin to prey. If the hard drive is removed, it can't be read or examined, and you can't replace the HDD with a different OS to get it to boot.
How would you recreate that setup with just a BIOS?
The setup that I have described has identical behavior, except that I use a removable USB memory (containing a bootable OS kernel and encrypted SSD/HDD keys) instead of a TPM and a firmware implementing SecureBoot, which are included in the computer motherboard.
In my variant, you do not need to trust anyone but yourself, because an attacker will have access only to a system where the component that needs to be secure is not present. In your variant, you must trust the vendors of the TPM and of the firmware, that their products do not have either intentional backdoors or bugs that would allow the extraction of the secret keys.
Having seen first hand how the development of "secure" products is done even at the companies that do not have bad intentions, I do not trust anyone, except myself.
> The setup that I have described has identical behavior, except that I use a removable USB memory
That's a huge difference though!
With my setup, if someone steals the device, they get a fully useable laptop with no password, locked down and restricted - they can join wifi networks, use the browser, download etc, but can't access the 'real' OS, and the laptop won't boot from anything other than the encrypted HDD it has the keys for.
It sounds like your setup leaves out the guest OS aspect, and is just set to boot into an encrypted OS only if a hardware key is present, which is quite a bit different.
> In my variant, you do not need to trust anyone but yourself,
That's true for my setup as well. Secureboot has an opensource reference implementation that has been in Coreboot for a long time, and it's not necessary to keep or add any vendor keys.
The open source feature of Secureboot is true only if you have replaced the laptop firmware with Coreboot, which is compatible only with few, mostly old, laptops.
Even in that case, a laptop with Coreboot will still use closed-source components that cannot be trusted, at least for the auxiliary CPUs of Intel and AMD (ME/PSP) and for the CPU of the TPM, i.e. for the parts that are the most important for security.
If someone steals the device, I cannot see any difference between our 2 setups. In both cases, the thiefs can use the laptop, but without accessing the internal SSD/HDD, unless they format it, which will remove any of the original information stored on it.
Even if you configured a laptop with UEFI/SecureBoot to not display the boot device selection menu without a password and to not boot from the internal SSD without a password, that can stop only someone with momentary access to the device, the same as in my setup, where an intruder would see the error message that no bootable disk has been found. Thiefs will erase the non-volatile UEFI settings, so they will be able to boot your laptop from an external device, regardless of your configuration, but the original internal SSD/HDD will remain inaccessible in any of the 2 setups.
However in the case that relies on the internal firmware and TPM to protect the keys, there are more sophisticated hardware attacks against the motherboard, e.g. using fault injections, logic analyzers, desoldering the relevant chips and replacing them, etc., which may succeed in some cases. Such hardware attacks are impossible when the component that must be attacked is not present, because it is a removable key (which is temporarily inserted only during booting).
> The open source feature of Secureboot is true only if you have replaced the laptop firmware with Coreboot, which is compatible only with few, mostly old, laptops.
Plenty of newer stuff that is explicitly open like the system 7 and framework stuff also.
> Even in that case, a laptop with Coreboot will still use closed-source components that cannot be trusted,
As does any solution relying on a BIOS.
> If someone steals the device, I cannot see any difference between our 2 setups.
In my setup, if the laptop is stolen, the thief is able to use a limited OS that give them all the functionality they would need while running a locator service in the background, allowing the hardware to be recovered, while preventing access to encrypted data.
It doesn't sound like your setup allows for that.
> However in the case that relies on the internal firmware and TPM to protect the keys, there are more sophisticated hardware attacks against the motherboard,
No matter what, using a BIOS makes you a lot more vulnerable than using any form of secure boot. It's a significantly more vulnerable standard.
When you can figure out how to setup a foss secure boot implementation with verified boot, then maybe I'll consider your input on bootloader security worth considering.
Until then, I don't think it makes sense to continue this discussion. I assume you'll claim it isn't possible, but anyone who expends the slightest effort will see how far from reality that is.
reply