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.
I don't quite understand this. The Intel presentation talks about ending BIOS, but that's provided by the motherboard firmware, not the CPU: how many motherboards are made by Intel? Have manufacturers like MSI or Gigabyte made a similar proposal?
Intel can force this by not having their next gen processors start in, or even support, real mode. They can dictate motherboard and firmware design through their control of the processor.
Eliminating legacy BIOS support, and real mode in the processor, might not be such a bad idea. Forcing UEFI is a step in the right direction, as long as secureboot remains optional, which IIRC it will be.
Intel can force this by not having their next gen processors start in, or even support, real mode. They can dictate motherboard and firmware design through their control of the processor.
Eliminating legacy BIOS support, and real mode in the processor, might not be such a bad idea. Forcing UEFI is a step in the right direction, as long as secureboot remains optional, which IIRC it will be.
How will AMD respond though? They can decide to go the opposite route then; this could be a boom for AMD for users that do not want to be forced into UEFI anytime soon.
How will AMD respond though? They can decide to go the opposite route then; this could be a boom for AMD for users that do not want to be forced into UEFI anytime soon.
I wouldn't bet a single ¢ on that. Bear in mind that most desktop users are not bothered by UEFI at all, as probably they don't even know if they have one. That would certainly put AMD in a dead end.
How will AMD respond though? They can decide to go the opposite route then; this could be a boom for AMD for users that do not want to be forced into UEFI anytime soon.
This whole thread is alarmist drivel. UEFI is trivial to support, and Slackware does it courtesy of elilo and grub, both of which are freely available open source projects. rEFInd is also available (I have it installed) and it works fine - and is better than grub on traditional BIOS.
Slackware supports UEFI out of the box, and has done for some time.
# ./intel_sa00086.py
INTEL-SA-00086 Detection Tool
Copyright(C) 2017, Intel Corporation, All rights reserved
Application Version: 1.0.0.128
Scan date: 2017-11-21 21:40:50 GMT
*** Host Computer Information ***
Name: kjhlt6
Manufacturer: Notebook
Model: P7xxDM(-G)
Processor Name: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
OS Version: Slackware 14.2 (4.4.100.kjh)
*** Intel(R) ME Information ***
Engine: Intel(R) Management Engine
Version: 11.0.0.1168
SVN: 1
*** Risk Assessment ***
Based on the analysis performed by this tool: This system is vulnerable.
Explanation:
The detected version of the Intel(R) Management Engine firmware is considered vulnerable for INTEL-SA-00086.
Contact your system manufacturer for support and remediation of this system.
For more information refer to the SA-00086 Detection Tool Guide or the Intel security advisory Intel-SA-00086 at the following link:
https://security-center.intel.com/ad...nguageid=en-fr
Last edited by kjhambrick; 11-21-2017 at 04:01 PM.
Reason: safe -> safe to download and run
Haha... said I might be vulnerable. You think they'd have a quick check to see the brand of the CPU.
Code:
jbhansen@craven-moorhead:~/intel-detect$ ./intel_sa00086.py
INTEL-SA-00086 Detection Tool
Copyright(C) 2017, Intel Corporation, All rights reserved
Application Version: 1.0.0.128
Scan date: 2017-11-22 00:12:11 GMT
*** Host Computer Information ***
Name: craven-moorhead
Manufacturer: To Be Filled By O.E.M.
Model: To Be Filled By O.E.M.
Processor Name: AMD Ryzen 7 1800X Eight-Core Processor
OS Version: Slackware 14.2 (4.14.0)
*** Risk Assessment ***
Detection Error: This system may be vulnerable, please install the Intel(R) MEI/TXEI driver (available from your system manufacturer).
For more information refer to the SA-00086 Detection Tool Guide or the Intel security advisory Intel-SA-00086 at the following link:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr
*** Host Computer Information ***
Name: rich-laptop
Manufacturer: ASUSTeK COMPUTER INC.
Model: Q500A
Processor Name: Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz
OS Version: Slackware 14.2 (4.4.88)
*** Intel(R) ME Information ***
Engine: Intel(R) Management Engine
Version: 8.1.2.1318
SVN: 0
*** Risk Assessment ***
Based on the analysis performed by this tool: This system is not vulnerable.
Hardware manufacturers work according to certain standards. Intel introduced the "EFI" in order to work on servers, where addressing and disk sizes are more than BIOS can support. "UEFI" was later developed as the standard for new generations (EFI is actually proprietary of Intel).
But, still, Intel pretty much drives it forward. Considering that processors drive the motherboard's specs, it is not a surprise.
I must say, this was inevitable. I don't like UEFI but if we want to move forward with larger drives using GUID and CPU-independent firmware in our boot managers, we have to deal with it.
This will not stop/slow Linux's progress. We will always adapt. I have installed dual boot Windows/Linux on many machines using UEFI. With each newer machine it seemed like the hardware was becoming more rigid to any modification I needed to make in order to boot Linux. But, I always managed to do it. Ok, I had to start using grub-efi, but in the end, it worked.
Someday there will be something else replacing UEFI, and we will still be finding new ways to do our work.
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,011
Rep:
Quote:
Originally Posted by bassmadrigal
Haha... said I might be vulnerable. You think they'd have a quick check to see the brand of the CPU.
Code:
jbhansen@craven-moorhead:~/intel-detect$ ./intel_sa00086.py
INTEL-SA-00086 Detection Tool
Copyright(C) 2017, Intel Corporation, All rights reserved
Application Version: 1.0.0.128
Scan date: 2017-11-22 00:12:11 GMT
*** Host Computer Information ***
Name: craven-moorhead
Manufacturer: To Be Filled By O.E.M.
Model: To Be Filled By O.E.M.
Processor Name: AMD Ryzen 7 1800X Eight-Core Processor
OS Version: Slackware 14.2 (4.14.0)
*** Risk Assessment ***
Detection Error: This system may be vulnerable, please install the Intel(R) MEI/TXEI driver (available from your system manufacturer).
For more information refer to the SA-00086 Detection Tool Guide or the Intel security advisory Intel-SA-00086 at the following link:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr
You can get the same result with intel
Code:
./intel_sa00086.py
INTEL-SA-00086 Detection Tool
Copyright(C) 2017, Intel Corporation, All rights reserved
Application Version: 1.0.0.128
Scan date: 2017-11-22 13:37:13 GMT
*** Host Computer Information ***
Name: My_MSI
Manufacturer: Micro-Star International Co., Ltd.
Model: GT60 2OC/2OD
Processor Name: Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz
OS Version: Slackware 14.2 (4.14.1)
*** Risk Assessment ***
Detection Error: This system may be vulnerable, please install the Intel(R) MEI/TXEI driver (available from your system manufacturer).
For more information refer to the SA-00086 Detection Tool Guide or the Intel security advisory Intel-SA-00086 at the following link:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr
./intel_sa00086.py
INTEL-SA-00086 Detection Tool
Copyright(C) 2017, Intel Corporation, All rights reserved
Application Version: 1.0.0.128
Scan date: 2017-11-22 13:37:13 GMT
*** Host Computer Information ***
Name: My_MSI
Manufacturer: Micro-Star International Co., Ltd.
Model: GT60 2OC/2OD
Processor Name: Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz
OS Version: Slackware 14.2 (4.14.1)
*** Risk Assessment ***
Detection Error: This system may be vulnerable, please install the Intel(R) MEI/TXEI driver (available from your system manufacturer).
For more information refer to the SA-00086 Detection Tool Guide or the Intel security advisory Intel-SA-00086 at the following link:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr
I think that happens when the module isn't loaded... but you would think they would use a quick if statement to not run if the CPU isn't Intel based. I just thought it was funny
Distribution: Debian /Jessie/Stretch/Sid, Linux Mint DE
Posts: 5,195
Rep:
Quote from one of the slides in the presentation pointed to in the first post:
Quote:
Intel is removing legacy BIOS support from client & data center platforms by 2020
Since the majority of data center platforms runs Linux you can be pretty sure that Intel will provide support to developers to solve problems with boot loaders. Certainly Intel does not want to be incompatible with, say, Red Hat.
As it is pointed out in the presentation, UEFI enables secure boot. It does not imply secure boot.
This step finally might give a boost to the development of boot loaders which just work with UEFI.
Although I am not 100% convinced that BIOS booting is as bad as pointed out in the presentation. Even if the principle is 40(?) years old. The processor architecture as we know it is even older. Old does not necessarily mean bad.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
