Hacker News new | past | comments | ask | show | jobs | submit login

A requirement they later dropped: https://tech.slashdot.org/story/15/03/20/2039251/oems-allowe...

First they require a lock, but also that the user gets the key. Next they require a lock, but the key may be withheld from the user. I wonder what they will require next. Their Surface RT line of laptops came without unlockable secure boot, so no alternative OS could be installed.




This is the problem with people not understanding how Secure Boot works, then reading specs that require such understanding.

For max-level compatibility with Windows 10 Enterprise, there's a requirement that owner of the device can change all the keys. It doesn't require a "disable Secure Boot" setting. Worst case, the device won't permit you to keep it in what's called "Setup Mode" without some inconvenience, however you have to be able to enter Setup Mode.

What's Setup Mode?

Setup Mode is when the PK variable (PlatformKey) is empty, effectively disabling SecureBoot. This mode exists so that you can load new PK value. According to UEFI Secure Boot spec, it's supposed to be frozen by manufacturer. However, being able to set your own one is critical to some of the Windows Enterprise features, and as such a way to enter that mode is required by Windows certification.


What you're saying is that, technical details aside, Windows 10 Enterprise certification effectively requires the ability to install alternative OSes.

Is that also true for non-Enterprise certification? Because the (dated) article implies otherwise. And it remains a fact that the Surface RT line was locked down so no-one could install an alternate OS on it without MS's permission. I don't know how much clearer MS could make their ambitions for control.


Yes, as there's no distinction for enterprise vs. non-enterprise certification. All systems that pass Windows logo certification have to be able to disable Secure Boot AND load user provided keys.[0]

If I had to guess, Microsoft locked down the Surface RT and wondered if they could get away with it, then once there was backlash and they realized that high-security environments wouldn't like it, they never spread the requirement to x86. That or antitrust fears.

0: https://docs.microsoft.com/en-us/windows/security/informatio...


Well, in locking down ARM devices, they were essentially following the accepted standard in ARM world.

Unfortunately, we don't know for sure unless maybe someone manages to subpoena emails about that from MS. Everything else is modern kremlinology.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: