In the file README_UEFI.TXT in the slackware64 iso's and tree

But with upcoming UEFI Class 3, Compatibility Support Module will be dead as the Dodo and no BIOS interface will be present.

I don't think that the moto "" To use UEFI, or not to use UEFI? "" will be here to stay in the foreseen future.



https://www.uefi.org/sites/default/f...ntel_Final.pdf

That presentation is all about promoting what the author calls "UEFI Mode 3+", meaning UEFI Mode 3 w/Secure Boot.

That will indeed be the end of all Slackware installation issues, since we won't be able to boot from unsigned media at all.

The writers of bios/uefi have never seemed to read or follow the standards. UEFI has many features that one may wish to use and in some cases have to use.

You will be able to find current models for some time I suspect.
When uefi/efi first came out there was a death cry from linux users. Still running.

"
UEFI machines can have one of the following "classes", which were used to help ease the transition to UEFI.

Class 0:Legacy BIOS
Class 1:Legacy BIOS with UEFI code, although it does not support UEFI booting.
Class 2:UEFI with CSM
Class 3:UEFI without CSM"

https://www.quora.com/What-is-class-...option-in-BIOS

Class 3 has been used in some laptops for a while now. I know several HP's that I've read about do not have the ability to turn on CSM. I don't BELIEVE I've seen a Dell or Lenovo yet that can't, but I'm not sure, since I think getting rid of CSM will be one of the best things ever, since it'll eliminate the single major reason people have failed UEFI installs nowadays.

I bit the bullet and have ditched csm and legacy boot about a year ago on all my machines (except for an ancient laptop). I saw the writing on the wall. As far as Class 3+, I'm confident linux in general will adapt and work out a way to co-exist with or mitigate secure boot.

That is literally impossible.

Which is why it wasn't (and still isn't) possible to install Linux on the old ARM-based Surface laptops. You would need Microsoft-signed boot files, and Microsoft is the only party who has the keys.

Hmmmm.... is there a UEFI equivalent to good ol' "modbin"?

No. The UEFI firmware images are all signed.

You are quite wrong.

A computer shop can make an agreement with Slackware, Inc. to install in the shipped computers an particular master key provided by.

Then, any signed kernels shipped by Slackware could be upgraded seamlessly on those computers.

Also, Slackware, Inc. may make public a master key to certify its signed kernels, which eventually can be added manually even by the end-users to UEFI's Secure Boot, then any signed kernels shipped by Slackware could be upgraded seamlessly on their computers.

Is not the fault of the hardware companies that a particular Linux distribution choose to ignore the requirements of Secure Boot on UEFI.

No, I'm not.
No, a computer manufacturer (OEM) could theoretically do that, but we all know that isn't going to happen.
No, any Slackware kernel and boot loader signed by that OEM would run on those computers. They would never hand their keys over to a third party like PV/Slackware.
Assuming the user is allowed to manage the keys, yes. Which you can currently do on x86, but not on Microsoft's ARM systems.
Nobody's ignoring anything. PV could make keys all day, Intel (and certainly Microsoft!) will just refuse to put them on their systems.

Aparently, some people here believes that Secure Boot signing is some kind of Nazis Secret Weapon...

There: https://wiki.archlinux.org/index.php...ce/Secure_Boot

Yeah, it is just a SSL signing.

Until our BDFL is kind to consider the UEFI's Secure Boot, at least we can sign OUR OWN kernels and other things alike.

So, no Devil Company handshake is required.

That's just a nonsensical statement.
OK, then install the ARM version of Slackware on a Surface device. That's right, you can't.

The title of this thread is "UEFI Class 3", and the Intel paper in the first post talks about UEFI Class 3 with Secure Boot enabled ("Class 3+"). Sure, that's not where we are today, but we know exactly how it would work, because we already have ARM devices where Secure Boot can't be turned off and the keys are not user-manageable.

The whole point of Secure Boot is to establish a chain of trust that looks like this:

Chipset -> UEFI Firmware -> Boot Loader -> OS

Note how you, the user, is not a part of that chain. And that is the whole idea.

4 members found this post helpful.

I did this Secure Boot of Slackware (and Android) in the near past. Your statements instead feels as some kind of radicalism...

I do not cares about ARM Microsoft Surface's issues. In fact, I do not use other ARM devices than those shipped by default with Android. I accept that my family owns some Android smartphones, after all...

But, it wasn't supposed that the ARM devices have uBOOT as low level bootloader and no BIOS or UEFI at all?

With all respect, I do not care at all about he ARM computers, unless they are in the form of Android smartphones, with a good Google made OS shipped by the factory.

Advocating for UEFI Class 3 without a compatibility module to become mandatory on x86 hardware is quite radical, and opens up the possibility for vendor-locked x86 hardware.
You're missing the point. The Intel document is about x86, and what they're advocating for will make locked devices a possibility (which means it will be a reality).

Consider this: Intel has spent millions of dollars on UEFI. Can you name a single advantage of UEFI Class 3 (without Secure Boot) over BIOS?

They are at least capable to boot from an USB 3.x card, which BIOS cannot.

That single and very reason made me to even add the UEFI DUET (an EFI layer over BIOS) even to my BIOS-only computers.