5 ms·

Empowering the 'User' (hardware owner) should have always been the focus. From that mindset what makes sense are hardware vendors including a cache of trusted

by mjevans 8mo ago

Empowering the 'User' (hardware owner) should have always been the focus. From that mindset what makes sense are hardware vendors including a cache of trusted third party root certificates from known other vendors. Today this would include Microsoft, the same said hardware vendor, probably various respected Linux organizations/groups (Offhand, Linux Foundation, ArchLinux, Debian, IBM/RedHat, Oracle, SUSE, etc), similar for BSD... Crucially the end user should then be ASKED which to enable. None should be enrolled out of the box. They might also be enabled only for specific things. E.G. HW vendor could be enabled only for new system firmware signatures (load using the existing software) rather than generic UEFI boot targets. The user should also be able to enroll their own CA certs as well; multiple of them. Useful for Organization, Division Unit, and system local signatures. It would also, really, be nice if UEFI mandated a uniform access API (maybe it does) for local blobs stored in non mass-storage space. This would be a great place to stash things like UEFI drivers for accessing additional types of hardware drivers, OS boot bits + small related files, etc. I would have said 1GB of storage would be more than sufficient for this - however Microsoft has proven that assumption incorrect. Still it'd be nice to have a standard place and a feature that says the system ships with this much reliable secondary storage included (or maybe 1-2 micro-SD card slots, etc).

mistrial9 8mo ago
> Crucially the end user should then be ASKED which to enable except, on the other side of the "strange fellows" are people who rose to executive authority by ruthless focus on control of every aspect of their business, and profit including excluding others who did actual work. There is zero point zero chance of any argument that relies on "should" to work IMHO this is a political situation by definition -- vastly different yet connected members of society and economics, seeking the rule of law to enable stable markets. hint- some of the same decision makers are the ones that pay to put spy code in your large new TV or appliances.
NekkoDroid 8mo ago
> From that mindset what makes sense are hardware vendors including a cache of trusted third party root certificates from known other vendors. Today this would include Microslop, the same said hardware vendor, probably various respected Linux organizations/groups (Offhand, Linux Foundation, ArchLinux, Debian, IBM/RedHat, Oracle, SUSE, etc), similar for BSD... IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys. This way it is entirely agnostic of any cherrypicked list of "trust me" vendors. You'd still have most of the benefits of easy secure boot enrolling for those that don't know what it even is/how to do it while also allowing easy choosing of other OSes (at least on initial first boot). The main problem currently is option-ROM which has a tendency to cause the system to not even POST if secure boot is enabled without MS keys. Recently bricked a MoBo this way and even though it has 2 BIOS I can't actively choose which one to boot, it just has some "trust me, I know when" logic that chooses... well guess how well that is working for me...). The Asrock board I replaced it with though has an option for what it should do with such option-ROM when secure boot is active (don't run, always run, run if signed, ...) > The user should also be able to enroll their own CA certs as well; multiple of them. Useful for Organization, Division Unit, and system local signatures. Isn't this already the status quo?? > It would also, really, be nice if UEFI mandated a uniform access API (maybe it does) for local blobs stored in non mass-storage space. [...] I think UEFI is already complex enough and most of this can in a way already somewhat be handled by the EFI System Partition, e.g. systemd-boot can tell the UEFI to load (file system) drivers off of it (https://wiki.archlinux.org/title/Systemd-boot#Supported_file_systems https://wiki.archlinux.org/title/Systemd-boot#Supported_file...), I don't know if UEFI technically supports other types of drivers to be loaded.
- bitwize 8mo ago
  > IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys. Nobody wants to "install" an operating system. Computers should come with an OS preinstalled and ready to run. Everything else is a dead letter in terms of the marketplace.
  - NekkoDroid 8mo ago
    I was talking about the same "install" that is already done (pre-installed on the drive that is first booted). Enrolling certs into the UEFI isn't something that needs to be done manually when "Setup Mode" is enabled, the bootloader can automatically enroll them. This already is a thing with the exception of the ship in "Setup Mode" part. Though some motherboard UEFI implementations are shit (as to be expected) and shit their pants when this happens. See last paragraph in this section as example: https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html#Files https://www.freedesktop.org/software/systemd/man/latest/syst...
    - bri3d 8mo ago
      What would be the point of this change? It erodes security in some moderately meaningful way (even easier to supply chain new computers by swapping the boot disk) to add what amounts to either a nag screen or nothing, in exchange for some ideological purity about Microsoft certificates?
      - NekkoDroid 8mo ago
        It really doesn't. UEFI are still not by default locked behind a password (can't be locked since you couldn't change settings in the UEFI if that were the case), so anyone that has access to change a drive can also disable secure boot or enroll their own keys if they want to do an actual supply chain attack. If your threat model is "has access to the system before first boot" you are fucked on anything that isn't locked down to only the manufacturer.
bitwize 8mo ago
This is what you get when a programmer designs a system. The end user wants to be able to just pick up a computer from Best Buy and have it work, out of the box. Microsoft can't even conceptualize why you would want to run anything but the Windows that came with the machine. If the expected Windows kernel and files aren't there, or have been altered, that is evidence of malicious tampering—malware that must be stopped. (I'm deliberately steelmanning their perspective here.) Streaming services want a secure content path. Game vendors want protection against cheating. In order to comply with local/regional/national laws, web sites need you to verify your age, and they need to know your computer is not lying (remote attestation). Nobody wants to be hacked. The incentives for everyone else besides techies align against techies getting to run arbitrary code on their devices. The Secure Boot system is working precisely as designed.
- dist-epoch 8mo ago
  > Game vendors want protection against cheating Gamers, gamers want anti-cheats. Vendors couldn't care less.
  - rcxdude 8mo ago
    Gamers want no cheaters, vendors want to be seen to be trying in the cheapest way that has credibility.
  - josefx 8mo ago
    It is 2026, people still use cheat software on public servers. It works about as well as DRM. > Vendors couldn't care less. There are more than enough games that are designed around microtransactions that use grind and gambling mechanics to encourage spending. Throw bots and cheats at that and the entire thing breaks down.
Joker_vD 8mo ago
> Empowering the 'User' (hardware owner) should have always been the focus. The "user" and "hardware owner" are not necessarily the same person.
UltraSane 8mo ago
In companies the user is often not the actual owner of hardware.
RupertSalt 8mo ago
"Your right to swing your arms ends just where the other man’s nose begins." Every time I see someone campaigning to exercise their civil liberties via hardware or software, I wonder if their devices are connected to any network. Because once you connect to a network, especially a WAN, your liberties are tempered by the rights of all other users. If your device hosts malware, botnets, scammers, spammers, or other malicious activity, no you do not have a right to the liberty of your hardware. The network and the service providers have a fiduciary responsibility of harm reduction and threat mitigation. Sure, some hackers are very very good at preventing malware and keeping the botnets at bay. You may be better at it than cloud providers or your ISP. In fact, it is the inexperienced users that we can't really trust. They'll get pwned and their browser will have a million toolbars with spyware. Their PC will join botnets and host CSAM. It is their ignorance and ineptitude that gets them into trouble. And so because WANs, particularly the public Internet, are common property, and not your private domain or sandbox, this is why things like device trust and attestation are being added. Because you could do all you wanted with your Commodore 64 and your Apple ][. The blast radius was limited to your family and every friend who traded cracked software. But once you're hooked up on a network, you need to stop swinging your fists at my nose.
netdevphoenix 8mo ago
> Crucially the end user should then be ASKED which to enable This doesn't work for literally 99.9% of the users out there. This is a classic HN's Dropbox symptom. You need overridable defaults.

by mjevans 8mo ago

mistrial9 8mo ago

> Crucially the end user should then be ASKED which to enable except, on the other side of the "strange fellows" are people who rose to executive authority by ruthless focus on control of every aspect of their business, and profit including excluding others who did actual work. There is zero point zero chance of any argument that relies on "should" to work IMHO this is a political situation by definition -- vastly different yet connected members of society and economics, seeking the rule of law to enable stable markets. hint- some of the same decision makers are the ones that pay to put spy code in your large new TV or appliances.

NekkoDroid 8mo ago

> From that mindset what makes sense are hardware vendors including a cache of trusted third party root certificates from known other vendors. Today this would include Microslop, the same said hardware vendor, probably various respected Linux organizations/groups (Offhand, Linux Foundation, ArchLinux, Debian, IBM/RedHat, Oracle, SUSE, etc), similar for BSD... IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys. This way it is entirely agnostic of any cherrypicked list of "trust me" vendors. You'd still have most of the benefits of easy secure boot enrolling for those that don't know what it even is/how to do it while also allowing easy choosing of other OSes (at least on initial first boot). The main problem currently is option-ROM which has a tendency to cause the system to not even POST if secure boot is enabled without MS keys. Recently bricked a MoBo this way and even though it has 2 BIOS I can't actively choose which one to boot, it just has some "trust me, I know when" logic that chooses... well guess how well that is working for me...). The Asrock board I replaced it with though has an option for what it should do with such option-ROM when secure boot is active (don't run, always run, run if signed, ...) > The user should also be able to enroll their own CA certs as well; multiple of them. Useful for Organization, Division Unit, and system local signatures. Isn't this already the status quo?? > It would also, really, be nice if UEFI mandated a uniform access API (maybe it does) for local blobs stored in non mass-storage space. [...] I think UEFI is already complex enough and most of this can in a way already somewhat be handled by the EFI System Partition, e.g. systemd-boot can tell the UEFI to load (file system) drivers off of it (https://wiki.archlinux.org/title/Systemd-boot#Supported_file_systems https://wiki.archlinux.org/title/Systemd-boot#Supported_file...), I don't know if UEFI technically supports other types of drivers to be loaded.

bitwize 8mo ago
> IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys. Nobody wants to "install" an operating system. Computers should come with an OS preinstalled and ready to run. Everything else is a dead letter in terms of the marketplace.
- NekkoDroid 8mo ago
  I was talking about the same "install" that is already done (pre-installed on the drive that is first booted). Enrolling certs into the UEFI isn't something that needs to be done manually when "Setup Mode" is enabled, the bootloader can automatically enroll them. This already is a thing with the exception of the ship in "Setup Mode" part. Though some motherboard UEFI implementations are shit (as to be expected) and shit their pants when this happens. See last paragraph in this section as example: https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html#Files https://www.freedesktop.org/software/systemd/man/latest/syst...
  - bri3d 8mo ago
    What would be the point of this change? It erodes security in some moderately meaningful way (even easier to supply chain new computers by swapping the boot disk) to add what amounts to either a nag screen or nothing, in exchange for some ideological purity about Microsoft certificates?
    - NekkoDroid 8mo ago
      It really doesn't. UEFI are still not by default locked behind a password (can't be locked since you couldn't change settings in the UEFI if that were the case), so anyone that has access to change a drive can also disable secure boot or enroll their own keys if they want to do an actual supply chain attack. If your threat model is "has access to the system before first boot" you are fucked on anything that isn't locked down to only the manufacturer.

bitwize 8mo ago

This is what you get when a programmer designs a system. The end user wants to be able to just pick up a computer from Best Buy and have it work, out of the box. Microsoft can't even conceptualize why you would want to run anything but the Windows that came with the machine. If the expected Windows kernel and files aren't there, or have been altered, that is evidence of malicious tampering—malware that must be stopped. (I'm deliberately steelmanning their perspective here.) Streaming services want a secure content path. Game vendors want protection against cheating. In order to comply with local/regional/national laws, web sites need you to verify your age, and they need to know your computer is not lying (remote attestation). Nobody wants to be hacked. The incentives for everyone else besides techies align against techies getting to run arbitrary code on their devices. The Secure Boot system is working precisely as designed.

dist-epoch 8mo ago
> Game vendors want protection against cheating Gamers, gamers want anti-cheats. Vendors couldn't care less.
- rcxdude 8mo ago
  Gamers want no cheaters, vendors want to be seen to be trying in the cheapest way that has credibility.
- josefx 8mo ago
  It is 2026, people still use cheat software on public servers. It works about as well as DRM. > Vendors couldn't care less. There are more than enough games that are designed around microtransactions that use grind and gambling mechanics to encourage spending. Throw bots and cheats at that and the entire thing breaks down.

Joker_vD 8mo ago

> Empowering the 'User' (hardware owner) should have always been the focus. The "user" and "hardware owner" are not necessarily the same person.

UltraSane 8mo ago

In companies the user is often not the actual owner of hardware.

RupertSalt 8mo ago

"Your right to swing your arms ends just where the other man’s nose begins." Every time I see someone campaigning to exercise their civil liberties via hardware or software, I wonder if their devices are connected to any network. Because once you connect to a network, especially a WAN, your liberties are tempered by the rights of all other users. If your device hosts malware, botnets, scammers, spammers, or other malicious activity, no you do not have a right to the liberty of your hardware. The network and the service providers have a fiduciary responsibility of harm reduction and threat mitigation. Sure, some hackers are very very good at preventing malware and keeping the botnets at bay. You may be better at it than cloud providers or your ISP. In fact, it is the inexperienced users that we can't really trust. They'll get pwned and their browser will have a million toolbars with spyware. Their PC will join botnets and host CSAM. It is their ignorance and ineptitude that gets them into trouble. And so because WANs, particularly the public Internet, are common property, and not your private domain or sandbox, this is why things like device trust and attestation are being added. Because you could do all you wanted with your Commodore 64 and your Apple ][. The blast radius was limited to your family and every friend who traded cracked software. But once you're hooked up on a network, you need to stop swinging your fists at my nose.

netdevphoenix 8mo ago

> Crucially the end user should then be ASKED which to enable This doesn't work for literally 99.9% of the users out there. This is a classic HN's Dropbox symptom. You need overridable defaults.