Scali wrote:

I think it's in the same category as x86 and the PC architecture being 'forced down our throats' just because Microsoft chose that as their main platform for Windows.

Insofar as they are both industry standards decided for the consumer by a particular monopoly, yes. In terms of implication, no. Standardizing x86 instead of something like the 68000 did not have the same platform control consequences as standardizing Secure Boot. Windows did not turn the x86 into a platform Microsoft was the gatekeeper to (though I am sure this was their wet dream in the 90s, which they partly re-attempted and so far spectacularly failed with Windows 10 25 years later) but Secure Boot puts Microsoft into the position of unilaterally deciding what hardware can boot what OS. The first is an irritating inconvenience, the second it outright dystopian.

gdjacobs wrote:

As for Safeboot, we already have two digital signature paradigms that could have been implemented in lieu of the design that's been adopted. The SSL web of trust and PGP keyserver architecture both offer security with decentralization without being dependent on the blessings of one player.

The UEFI system is no different from SSL, in the sense that you can get certificates for signing from any number of certificate authority organizations. UEFI uses standard x509 certificates, the same as SSL.
The practical problem is that Microsoft is the only one that actually went and obtained a certificate from such an organization (they are not the organization themselves!), and that is the only certificate that actually became widespread.
Using any other signature paradigm would lead to the exact same situation.
The problem is not Microsoft, the problem is that no other OS dev adopted the UEFI Secure Boot standard, and as such had no certificate that could be installed on devices from the factory.

Basically it's the linux world that put Microsoft in this position, ironically enough.
Had the linux distros come together, and obtained a shared x509 certificate, and signed their bootloaders with it, then this certificate would most likely have been adopted by many vendors, and installed by default.
But as it stands, the linux people were too busy arguing about how Secure Boot was incompatible with GPLv3, and so they wanted none of it. And now they get what they want: none of it.

That is an obscenely twisted (not sure if purposeful or not but I will give you benefit of the doubt) way of looking at things. Linux's fundamental reservations about Secure Boot went way beyond its compliance to GPL v3, they just refused to go with the standard for completely valid reasons.

For anyone else who want to learn more about the issue I can refer you to this: https://www.fsf.org/campaigns/secure-boot-vs- … /whitepaper-web

SirNickity wrote:

Sometimes I feel the only solution to this is to stand up a parallel industry, where the software AND hardware is open. It wouldn't be without its problems, but it sure would be nice to have the freedom. Maybe some day, with all the hobby FPGA designs, such a platform could exist, and eventually become prolific enough that it could not be ignored. Probably a dream, but it's nice to have something to aspire to.

In the past an "open" sw concept itself felt like a fascinating alternative way instead of the usual standardization of 'everything' but in the last decade for what I can humbly understand of it, even this concept doesn't sound good anymore because at the end: some would start with that ideal, to survive most of the time would become a company and usually what may happen to live versus or thank the influence of or entirely bought by others, ending up using the "open" word for "not really that open after all" hw or sw products.
As you said maybe going back to the lowest level of eletronic, fpga, alternative hobby designs sounds like a better and useful way to not just be "a user under contracts and agreements".

appiah4 wrote:

That is an obscenely twisted (not sure if purposeful or not but I will give you benefit of the doubt) way of looking at things. Linux's fundamental reservations about Secure Boot went way beyond its compliance to GPL v3, they just refused to go with the standard for completely valid reasons.

For anyone else who want to learn more about the issue I can refer you to this: https://www.fsf.org/campaigns/secure-boot-vs- … /whitepaper-web

Whatever their exact reasons are, clearly they consciously opted-out of Secure Boot, which left Microsoft as the only major player to use it. Which leads to the situation we're in, as I already said.
I mean, the linux/FSF people can go cry about it, but this is what they wanted, so this is what they got.

Aside from that, the story of the FSF is a gross lie:

Under the guise of security, a computer afflicted with Restricted Boot refuses to boot any operating systems other than the ones the computer distributor has approved in advance. Restricted Boot takes control of the computer away from the user and puts it in the hands of someone else.

This is not correct at all. As already stated, the UEFI allows end-users to add additional keys to the repository. So yes, when you first power it on (and Secure Boot is actually enabled), you can only boot OSes that were signed by whatever CA's the computer distributor has pre-installed for you.
However, you can go into the UEFI configuration, and add your own keys. Which means the control is NOT taken away, and is not only with the computer distributor (which again is the same as SSL and related signing systems: you can import new keys into your OS keystore manually).
You can actually read how to do this on eg the Ubuntu site:
https://wiki.ubuntu.com/UEFI/SecureBoot
https://wiki.ubuntu.com/UEFI/SecureBoot/Signing
https://wiki.ubuntu.com/UEFI/SecureBoot/KeyMa … nt/ImageSigning
And some more low-level detail from Gentoo:
https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_I … ing_Secure_Boot
(Point 5 describes how your own keys can be added to the UEFI keystore)

Not to mention that you can also turn off Secure Boot altogether, in which case none of this even applies in the first place.
Fear mongering.

The issue here is that you are presenting it as if hardware developers one day came together and decided to implement a standard called Secure Boot and Microsoft agreed to it and became a key provider whereas Linux just didn't take it seriously so it is suffering.

This is not what happened. At ALL.

Microsoft decided to push UEFI and Secure Boot leveraging its massive market share and more or less mandated that future OEM PCs and IHV motherboards be compliant and include Microsoft's boot keys while at the same time assuming the post of a key producer. It was a dick move aimed at taking more control of a platform they were selling to - if you believe Microsoft initiated any of this shit with benign intentions in mind you are delusional, this all coincides with their other dick moves such as trying to shove the Microsoft Marketplace and Windows 10's App structure down the consumers' throats - they were basically trying to turn the PC into a closed Windows environment (and no wonder this also coincides with XBOX One being announced as requiring 24H Online DRM etc.. ) What Linux did was stand up and say:

They certainly did not win this fight, but they fought on the right side. If you are arguing the opposite view, you are part of the problem as far as I am concerned. Secure Boot was the wrong solution to a problem that did not exist. Linux does not need Secure Boot to do a secure boot, so if Windows 10 requires this then that means Microsoft should go back to the drawing board and design a more solid OS than the shitshow that is Windows 10. But instead their shortcoming is their excuse to further monopolize the market. And people cheer them on.

Faith in humanity -1

appiah4 wrote:

This is not what happened. At ALL.

Indeed, Microsoft is NOT a key provider. They are a key owner, because they registered with a root authority. Only these authorities can issue keys. Microsoft can not.

appiah4 wrote:

Microsoft decided to push UEFI and Secure Boot

Which does not take anything away from the fact that UEFI and Secure Boot are standards developed by the UEFI Forum, which is a committee of various big players from the hardware and software world.
The rest is just drivel that I prefer to ignore altogether.

For your information, Linus Torvalds did actually NOT side with the FSF, and was pro-Secure Boot, because of pragmatic reasons (apparently he was smart enough to figure out that whatever route Microsoft takes will be the default route for most hardware vendors, a matter of simple economics).
See here: https://www.zdnet.com/article/linus-torvalds- … efi-and-fedora/

Linus Torvalds wrote:

Yes, yes, the sky is falling, and I should be running around like a headless chicken in despair over signing keys. But as long as you can disable the key checking in order for kernel developers to be able to do their job, signed binaries really can be a (small) part of good security. I could see myself installing a key of my own in a machine that supports it.

Scali wrote:

Indeed, Microsoft is NOT a key provider. They are a key owner, because they registered with a root authority. Only these authorities can issue keys. Microsoft can not.

No, they sign code so that it runs with the default key - same difference as long as the motherboard ships with only their key.

Scali wrote:

Not to mention that you can also turn off Secure Boot altogether, in which case none of this even applies in the first place.
Fear mongering.

^^^ This ^^^

Basically the FSF are pissed because by default it doesn't come with any *nix keys, only microsoft. That FSF document actually endorses Secure boot....

Secure Boot, done right, embodies the free software view of security, because it puts users -- whether individuals, government agencies, or organizations -- in control of their machines.

just not the fact that by default it comes with microsoft...

In theory, there should be no problem. In practice, the situation is more complicated. As currently proposed, Secure Boot impedes free software adoption. It is already bad enough that nearly all computers sold come with Microsoft Windows pre-installed. In order to convince users to try free software, we must convince them to remove the operating system that came on their computers

booo hoo... just do that then!

With Secure Boot, new free software users must take an additional step to install free software operating systems. Because these operating systems do not have keys stored in every computer's firmware by default like Microsoft does, users will have to disable Secure Boot before booting the new system's installer.

So basically they want to appeal to users who don't know much about computers to use their OS in stead of the one that comes with the computer. Should be down to users to use what they want imo, if my computer doesn't run the OS because I need to do X to it, I will do X to it... if it doesn't run the OS I want by default, I either buy one that does, or live with the fact that I can't get my square into my circle...

There is no restriction on FSF, just the fact that it's not default behavoir...

The best way out of all of this (other than having all computers come pre-installed with free software) would be for free software operating systems to also be installable by default on any computer, without needing to disable Secure Boot.

And there is absolutely no restriction that MS imposes on Secure Boot...

In order to comply with Microsoft's rules as currently published, distributors of x86 computers will have to provide users both the option to customize Secure Boot by using their own security keys, and the option to disable it completely.

Anyone who is really that bothered and knows anything about this will probably go and buy a Talos Raptor (their secure boot is open source allowing the user to modify it)... but of course then we are back to square ione

appaih4 wrote:

The issue here is that you are presenting it as if hardware developers one day came together and decided to implement a standard […]
Show full quote

The issue here is that you are presenting it as if hardware developers one day came together and decided to implement a standard called Secure Boot and Microsoft agreed to it and became a key provider whereas Linux just didn't take it seriously so it is suffering.

This is not what happened. At ALL.

Microsoft decided to push UEFI and Secure Boot leveraging its massive market share and more or less mandated that future OEM PCs and IHV motherboards be compliant and include Microsoft's boot keys while at the same time assuming the post of a key producer. It was a dick move aimed at taking more control of a platform they were selling to - if you believe Microsoft initiated any of this shit with benign intentions in mind you are delusional, this all coincides with their other dick moves such as trying to shove the Microsoft Marketplace and Windows 10's App structure down the consumers' throats - they were basically trying to turn the PC into a closed Windows environment (and no wonder this also coincides with XBOX One being announced as requiring 24H Online DRM etc.. ) What Linux did was stand up and say:

Image

They certainly did not win this fight, but they fought on the right side. If you are arguing the opposite view, you are part of the problem as far as I am concerned. Secure Boot was the wrong solution to a problem that did not exist.

🤣 ... go and read that document you posted!

I really don't know what the problem is, and that FSF document you linked is nothing more than a rant, but even says itself that it's a good thing and they are just wanting a piece of the pie by default... but no one is restricted from doing anything?

Just that by default, it has MS keys and want it to have *nix keys without the need to turn it off.... it really isn't a problem or consipracy like you are making it out to be.

appiah4 wrote:

No, they sign code so that it runs with the default key - same difference as long as the motherboard ships with only their key.

It's not. There would be a severe conflict of interest if Microsoft could actually issue keys themselves.
As for default keys, as I already said, that situation was created by the linux community, not by Microsoft.
Microsoft is actually providing them with a service, because technically they shouldn't be signing third-party code with their key at all. Basically it misrepresents this third-party code as originating from Microsoft. Which more or less defeats the purpose.

Question: beside the really interesting discussion on who and why created or needed this bios/os signature process, will this limit technically the lifetime itself of the products? Cause if we make a comparison with SSL as done in the previous posts, I'd not be surprised to see like happened with not much old hardware/software (Symbian OS or various web browsers) those becoming unusable cause the security certificates are not valid anymore even if both the hardware and the software may still be capable to still be used instead of forcing in a continuous hardware and software upgrade.

386SX wrote:

will this limit technically the lifetime itself of the products?

Depends on your definitions of "lifetime" and "products".
If you buy a system with Secure Boot today, you at least know that it can boot any OS that is signed with a key that is either already in the firmware, or is added to the firmware store by the user (as described in one of my earlier posts), or that you can just turn off Secure Boot altogether.
That doesn't guarantee that future OSes won't use incompatible keys or methods of signing or whatever, which could still break them.

Again as I said, there are no guarantees. But I don't see Secure Boot making any practical difference for the longevity of products either positively or negatively.

386SX wrote:

Question: beside the really interesting discussion on who and why created or needed this bios/os signature process, will this limit technically the lifetime itself of the products? Cause if we make a comparison with SSL as done in the previous posts, I'd not be surprised to see like happened with not much old hardware/software (Symbian OS or various web browsers) those becoming unusable cause the security certificates are not valid anymore even if both the hardware and the software may still be capable to still be used instead of forcing in a continuous hardware and software upgrade.

Obviously old OS software without keys won't boot under UEFI Secure Boot.

I ended up keeping that win10pro installation that I did - a huge factor for that was that my 7pro legit key was accepted.
After tweaking (thanks for the tip on winareo schmatzler!) and some popups/features disabling all I can say is meh.
Can't say I particularly love it or hate it. It's a mix of old and new simplified stuff - I prefer the old stuff. What I like the most is the quick hybernation-like startup.
I had to remove my Auzentech X-Fi Forte 7.1 because it had no working drivers on the latest 10 update and some hacked ones did not work. Did not want to mess more and kill the system... a bummer because I really liked this card's output.
If 7 was supported longer I would not upgrade even with the tweaks 😁

appiah4 wrote:

Obviously old OS software without keys won't boot under UEFI Secure Boot.

Not directly, but with use of a shim, you can.
(Just like you can't boot legacy OSes under UEFI without a legacy function... but with use of a shim, you can)

To make it clear: Secure Boot is *only* active for the initial booting process.
Once the bootmanager is loaded, the responsibility is handed off to that bootmanager.
So it is perfectly possible to use a bootmanager with no security features whatsoever, and then sign that bootmanager, so that the bootmanager can be loaded under UEFI Secure Boot, after which the bootmanager can boot any unsigned OS you want.
So you can install a signed version of Grub (versions of Grub signed with the Microsoft key are freely available), and then use Grub to boot MS-DOS, Windows NT 3.51 or whatever else you can think of.

keropi wrote:

What I like the most is the quick hybernation-like startup.

I would like that if it would work, but Win10 likes to forget my SSD exists on anything but a full power cycle.

so even just for a simple reboot I need to shut it down first.

I suppose, yeah. Then there is also the hassle of actually booting the installation media.

Scali wrote:

Basically it's the linux world that put Microsoft in this position, ironically enough.
Had the linux distros come together, and obtained a shared x509 certificate, and signed their bootloaders with it, then this certificate would most likely have been adopted by many vendors, and installed by default.
But as it stands, the linux people were too busy arguing about how Secure Boot was incompatible with GPLv3, and so they wanted none of it. And now they get what they want: none of it.

Why would they need a shared certificate? UEFI could mandate a set of root certificates which must be preloaded, then have a mechanism for checking delegated public certificates or certificate chains included in the EFI partition. UEFI could also mandate safe boot as optional. This could probably even be included in a specification update if it's not part of the spec already.

imi wrote:

I would like that if it would work, but Win10 likes to forget my SSD exists on anything but a full power cycle.

so even just for a simple reboot I need to shut it down first.

You are probably looking at a hardware problem here.

Scali wrote:

Depends on your definitions of "lifetime" and "products". If you buy a system with Secure Boot today, you at least know that it […]
Show full quote

386SX wrote:

will this limit technically the lifetime itself of the products?

Depends on your definitions of "lifetime" and "products".
If you buy a system with Secure Boot today, you at least know that it can boot any OS that is signed with a key that is either already in the firmware, or is added to the firmware store by the user (as described in one of my earlier posts), or that you can just turn off Secure Boot altogether.
That doesn't guarantee that future OSes won't use incompatible keys or methods of signing or whatever, which could still break them.

Again as I said, there are no guarantees. But I don't see Secure Boot making any practical difference for the longevity of products either positively or negatively.

Thanks. Cause beside the questionable ability to use a very old PC nowdays for its power/hw limits, the ssl/https logic mostly accelerated their retirement even when they would be (with some patience) able to compute mostly every basic tasks and same would maybe happpens anyway with the future one then added to the cpu instructions/SSEx checking to just run a simple app..for sure that's far from the smartphone problems where a quad core cpu with giga of ram could find itself useless cause its never-updated kernel or cause since "tomorrow" all the phones running this or that version, will simply cannot run that app anymore.