4 ms·
Agree. There's separate issues at play: the mechanism, what value it adds or subtracts and how it can be used. The critical component is allowing end users to c
by zahllos 4y ago
Agree. There's separate issues at play: the mechanism, what value it adds or subtracts and how it can be used. The critical component is allowing end users to control their own devices.
Fair disclosure, I've been involved in products supporting secure boot, have run my own laptop with my own keys such that only my signed stuff runs. I also have one of those Talos 2 boards and it also supports its own secure boot, even though all of the software all the way down to the firmware is open source.
So far Microsoft have actually been pretty reasonable: they enabled the shim in the first place. No Linux distros including heavyweights like Redhat or Canonical stepped up to undergo the requirements for default inclusion in the UEFI forum.
It always strikes me as a logical fallacy to argue against having a secure boot but then be pro end to end encryption. 'Secure boot is being used to oppress us therefore secure boot is bad' is as extreme a view as 'some awful human beings share csam so end-to-end bad'.
Ultimately in both cases the problem is societal and not technical. We need consumer rights protections so we don't end up renting our devices, and we need policing and community work to eradicate csam. Frothing at the mouth misinformed 'activism' comes across very badly to people outside the tech world we necessarily need to engage to make constructive policies for the future.
- cowtools 4y agoSecure boot is opressive when you don't have the keys. So is encryption.
- trelane 4y agoIf someone else has the keys, you're not the owner, you're a renter.
- Perseids 4y agoYour arguments strike me as inconsistent. You say we need consumer rights protections so we don't end up renting our devices, but then you criticize the comment that speaks up about a consumer rights problem. > There's separate issues at play: the mechanism, what value it adds or subtracts and how it can be used. The thing is, it's absurd to separate these issues. Look at it from the perspective of most users: Secure Boot is a solution to a minuscule problem. The vast majority of exploits happen in their browsers, office suits or due to social engineering (phishing, ransomware, adware). So from the start, to sway the trade-off in favor to Secure Boot, the trouble it generates must be minuscule as well. And that is not the case: From the beginning Secure Boot has been a threat to free OS choice on PCs. Microsoft did not start by proposing a non-profit steward that will find good rules how code signing can be implemented and what rules you have to follow to be let in. That would have been "pretty reasonable". Instead they declared themselves rulers and it required a massive effort of the free software community to find ways to fulfill the requirements Microsoft unilaterally declared. Being able to find a working process with Microsoft has generated some fragile trust, but all of that is in peril with news like Lenovo removing the Microsoft Corporation UEFI CA from their default installation. If you would really care about letting the mechanism stand on its own without it being intermingled with politics (and I read that you care about that from the cited line) there is only one solution: Take the private keys to the Secure Boot certificates away from Microsoft and hand them over to neutral party. (And of course that will not happen, and thus the political and technical side remain deeply intertwined.)
- Avamander 4y ago> Secure Boot is a solution to a minuscule problem. The vast majority of exploits happen in their browsers, office suits or due to social engineering (phishing, ransomware, adware). It's a minuscule problem right now because of SB. Why spend time and effort if it's likely you'll encounter a protected system. If you give adversaries the possibility of implanting something deep into the boot chain, you've lost the entire battle. Obviously things that get exposed to untrusted content get exploited first, but no good attacker would leave it at that, especially if they want to create persistent malware and botnets. Exactly due to *Secure Boot* we aren't suffering from mass-spread malware like the ones that existed. > massive effort of the free software community to find ways to fulfill the requirements Microsoft unilaterally declared. Not really massive, mostly like absolute bare minimum, if you've read them. But okay. > Take the private keys to the Secure Boot certificates away from Microsoft and hand them over to neutral party. (And of course that will not happen, and thus the political and technical side remain deeply intertwined.) We could totally have a third root CA as well, if mandated or needed, but I haven't heard anyone pushing for it. Apple doesn't care and most Linux distros barely support existing Secure Boot which requires much less effort than running your own CA does.
- AshamedCaptain 4y ago> It's a minuscule problem right now because of SB. Why spend time and effort if it's likely you'll encounter a protected system. It was a minuscule problem even before SB and even today still is without SB. For most people who are exploited up to the point were malware _can write directly to the boot hard disk_, "boot chain safety" is at that point the least of the user's problems. Their data is already uploaded to a Russian server, ransomware installed, their webcam turns on without the warning LED, and all their OS security including the root account has been compromised up to the point that the attacker can start erasing off-site backups without the owner even noticing (no need and no point to compromise the boot chain). The only scenarios were boot chain integrity would apply are evil maid scenarios where the attacker can write to the boot disk externally, i.e. _not from the user's OS itself_, and these are way outside the worries of the immense majority of users. Correctly, IMHO. > Not really massive, mostly like absolute bare minimum [effort], if you've read them. But okay. > most Linux distros barely support existing Secure Boot which requires much less effort than running your own CA does. This is a just cheap criticism (even insulting) without even providing any reasoning whatsoever. And I say that as someone who has criticized Linux distributions from trying to play under the arbitrary MS rules. Most if not all Linux distros do their own CA already. They sign packages, after all.