SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
In the file README_UEFI.TXT in the slackware64 iso's and tree
Quote:
To use UEFI, or not to use UEFI? Unless your computer came with a preinstalled version of Windows that requires UEFI, switching to Legacy Boot (aka, traditional BIOS) is an option.
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.
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"
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.
Last edited by Timothy Miller; 12-18-2020 at 07:01 PM.
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.
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.
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.
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.
Last edited by ZhaoLin1457; 12-19-2020 at 05:16 AM.
A computer shop can make an agreement with Slackware, Inc. to install in the shipped computers an particular master key provided by.
No, a computer manufacturer (OEM) could theoretically do that, but we all know that isn't going to happen.
Quote:
Originally Posted by ZhaoLin1457
Then, any signed kernels shipped by Slackware could be upgraded seamlessly on those computers.
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.
Quote:
Originally Posted by ZhaoLin1457
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.
Assuming the user is allowed to manage the keys, yes. Which you can currently do on x86, but not on Microsoft's ARM systems.
Quote:
Originally Posted by ZhaoLin1457
Is not the fault of the hardware companies that a particular Linux distribution choose to ignore the requirements of Secure Boot on UEFI.
Nobody's ignoring anything. PV could make keys all day, Intel (and certainly Microsoft!) will just refuse to put them on their systems.
Until our BDFL is kind to consider the Secure Boot, at least we can sign OUR OWN kernels.
No Devil Company handshake is required.
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.
I did this Secure Boot of Slackware (and Android) in the near past. Your statements instead feels as some kind of radicalism...
Quote:
Originally Posted by Ser Olmy
OK, then install the ARM version of Slackware on a Surface device. That's right, you can't.
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?
Quote:
Originally Posted by Ser Olmy
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.
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.
Last edited by LuckyCyborg; 12-19-2020 at 10:21 AM.
I did this Secure Boot of Slackware (and Android) in the near past. Your statements instead feels as radicalism...
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.
Quote:
Originally Posted by LuckyCyborg
With all respect, I do not care at all about ARM computers, unless they are in the form of an Android smartphones, with a good OS shipped by the factory.
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?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.