Intel Planning To End Legacy BIOS Support By 2020, Report Says (phoronix.com)

Coreboot by Anonymous Coward · 2017-11-20 02:09 · Score: 1

Hopefully Coreboot will be more widespread by then and UEFI can just be a compatibility layer on top of Coreboot.

Re:Coreboot by Anonymous Coward · 2017-11-20 02:14 · Score: 0

They will lock out linux dists from modern hardware
Re:Coreboot by Anonymous Coward · 2017-11-20 02:38 · Score: 0

nice troll, 9/10. -1 point for "Miscrosoft".
Re:Coreboot by Anonymous Coward · 2017-11-20 02:39 · Score: 5, Funny

You should stick to secure MINIX, as Intel intended.
Re:Coreboot by DontBeAMoran · 2017-11-20 03:00 · Score: 1

Apple only patches the last few versions of macOS and the latest versions of macOS require new hardware.
You can only rely on Apple for security patches for a few years, after that you're considered a non-paying customer.

--
#DeleteFacebook
Re:Coreboot by Anonymous Coward · 2017-11-20 03:09 · Score: 0

After one or two years I'll have a new Apple device anyway. This is an irrelevant issue When they stop updating the awesomeness you know it's time to get a new device to remain awesome.
Re:Coreboot by MightyYar · 2017-11-20 03:29 · Score: 1

latest versions of macOS require new hardware.
What is your definition of "new hardware"? The latest OS runs on my late-2008 MacBook Pro. That it works at all is a wonder - it owes me nothing.

--
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Re:Coreboot by Opportunist · 2017-11-20 04:05 · Score: 1

Intel is not stupid. They certainly don't want to lose the server market, and this is basically what would happen.

--
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Re:Coreboot by Anonymous Coward · 2017-11-20 04:39 · Score: 0

ooh, sarcasm!!
Re:Coreboot by omnichad · 2017-11-20 04:42 · Score: 1

Are you sure you're on the latest release? Neither Sierra nor High Sierra list support for any Macbook Pro before mid-2010.
https://support.apple.com/en-u...
Re:Coreboot by TheRaven64 · 2017-11-20 05:39 · Score: 1

Following the links a bit, it looks as if El Capitan is still getting security updates and supports Mid-2007 15" and 17" MacBook Pros (MacBooks Pro?), and all 13" ones. It's not the latest OS, but High Sierra is such a QA clusterfuck that there's little incentive to upgrade (scaled resolution on an external display pegs CPU at 100%, so good luck having a battery last for an entire presentation, and it's crashing on a lot of hardware that was stable with Sierra) and Sierra didn't include much by way of useful additional features.

--
I am TheRaven on Soylent News
Re:Coreboot by omnichad · 2017-11-20 05:42 · Score: 1

I'm on a Hackintosh and I'll never upgrade to Sierra, because I'll lose Final Cut Pro permanently and probably Adobe Creative Suite too. They ave done far too many backward-compatibility breaking changes over the years.
Re:Coreboot by Anonymous Coward · 2017-11-20 06:44 · Score: 0

yas, Intel don't change the subject! What about this zero day flaw in all hardware
Re:Coreboot by jazzis · 2017-11-20 06:46 · Score: 1

Hopefully Coreboot will be more widespread by then and UEFI can just be a compatibility layer on top of Coreboot.
FYI: https://eshop.macsales.com/gui... Plue Safari /Security, URFI and major Apps back to Lion (10.7.x) 64 bit
Re:Coreboot by Hognoxious · 2017-11-20 09:30 · Score: 0

Unless systemd does it first.

--
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Re:Coreboot by Anonymous Coward · 2017-11-20 09:44 · Score: 0

I think Intel (as a system supplier) is already irrelevant in the server market. Amazon, for example, already contracts out all of their drive, server and SAN builds to their own specifications.
Re: Coreboot by Malc · 2017-11-20 10:47 · Score: 1

This isnâ(TM)t quite true. My Late 2007 MacBook Pro recieved the 2017-0004 security update recently.

Force secure boot on unconditionally? by ReluctantRefactorer · 2017-11-20 02:11 · Score: 5, Insightful

As long as the user can always install their own platform key, so they retain ultimate control of their own computer, then this isn't such a big deal. But there needs to be a standardised interface for installing platform keys in the UEFI settings.

--
RR

Re:Force secure boot on unconditionally? by omnichad · 2017-11-20 02:22 · Score: 0

That's not even required in EFI Class 3, per the article:

that's not going to force on UEFI Secure Boot unconditionally: Secure Boot enabled is considered UEFI Class 3+.
Re:Force secure boot on unconditionally? by Junta · 2017-11-20 02:27 · Score: 5, Insightful

Well, one, SecureBoot is not mandated. Been UEFI booting since before SecureBoot existed.
Two, *if* it were mandated, using UEFI settings menu interactively isn't going to cut it, as large deployments need less manual attention. Some automation friendly mechanism is needed. The challenge being that it's hard to make an automation friendly capability that isn't also malware friendly.
I would have liked the mechanism to ship unlocked until an OS vendor installs, which would then have optionally locked the platform to that vendors or enduser keys. But instead we get the joy of Microsoft's keys being the arbiter of the whole SecureBoot platform.

--
XML is like violence. If it doesn't solve the problem, use more.
Re:Force secure boot on unconditionally? by Rockoon · 2017-11-20 02:28 · Score: 1, Insightful

a standard interface probably means it can be hacked by malware - careful what you wish for

--
"His name was James Damore."
Re:Force secure boot on unconditionally? by mark-t · 2017-11-20 03:00 · Score: 1

That's fine... the OS can be written to disallow an arbitrary user from being able to access the interface via software. Root or admin user should still be able freely use the API as it is designed.
If an otherwise unauthorized person somehow gets root/admin privileges, then... well... you were boned already.

--
File under 'M' for 'Manic ranting'
Re:Force secure boot on unconditionally? by Anonymous Coward · 2017-11-20 03:14 · Score: 0

As long as the user can always install their own platform key, so they retain ultimate control of their own computer...
AFAIK the standard does not require users to be able to install platform keys.
If it does now, then I don't expect it will come 2020.
Re:Force secure boot on unconditionally? by butzwonker · 2017-11-20 03:26 · Score: 5, Insightful

Looks like a false dichotomy to me. Why can't they make chipsets/motherboards that allow me to change UEFI settings (incl. installing my own keys for secure boot or switching it off) and switch off/on Intel ME by flipping physical switches, while at the same time offering chipsets/motherboards with less secure, but corporate-friendly automated mechanisms?
My guess is that they don't want to allow the first option because someone asked them not to allow it. In fact, I have no other explanation. Adding two jumpers and adjusting the firmware in an appropriate way doesn't seem like a major price point or technical obstacle that Intel just can't afford or solve.
Re:Force secure boot on unconditionally? by Anonymous Coward · 2017-11-20 03:59 · Score: 0

I would have liked the mechanism to ship unlocked until an OS vendor installs, which would then have optionally locked the platform to that vendors or enduser keys. But instead we get the joy of Microsoft's keys being the arbiter of the whole SecureBoot platform.
That would be a great idea. Ship systems with no OS. Customer installs image on machine, bootloader includes a UEFI call to install a certificate, certificate is authenticated and UEFI won't accept a new certificate without some physical intervention.
Re:Force secure boot on unconditionally? by omnichad · 2017-11-20 04:44 · Score: 3, Funny

installing my own keys.....by flipping physical switches
You want to have 2048 dip switches for entering your secure boot key? I'd rather use a GUI for that.
Re:Force secure boot on unconditionally? by thegarbz · 2017-11-20 05:12 · Score: 1

I would have liked the mechanism to ship unlocked until an OS vendor installs, which would then have optionally locked the platform to that vendors or enduser keys. But instead we get the joy of Microsoft's keys being the arbiter of the whole SecureBoot platform.
The latter is the result of implementing the former in a world where every computer is sold with a Microsoft OS. You got what you want, it just wasn't thought through.
Re:Force secure boot on unconditionally? by Cid+Highwind · 2017-11-20 05:14 · Score: 1

But there needs to be a standardised interface for installing platform keys in the UEFI settings.
There already is. If your board supports it, and if secure boot is in setup mode, then efi-updatevar can write UEFI secure boot keys. (Mine doesn't, I have to use the UEFI menu to replace keys.)
The process of enabling secure boot for self-signed kernels is not for the faint of heart but it can be done.

--
0 1 - just my two bits
Re:Force secure boot on unconditionally? by Anonymous Coward · 2017-11-20 05:26 · Score: 0

Switch 1: Enforce Secure Boot
Switch 2: Secure boot key store RO/RW
Re:Force secure boot on unconditionally? by b0s0z0ku · 2017-11-20 05:28 · Score: 1

How about designing it to read a boot ROM, including install keys, off of a micro-SD card?
Re:Force secure boot on unconditionally? by TheRaven64 · 2017-11-20 05:42 · Score: 1

If you want to use SecureBoot and the TPM to provide a chain of trust then you don't want an attacker to be able to flip a DIP switch and disable it. The kind of customers that really want this sort of thing are people who want to stick a load of machines in a data centre that's managed by someone else and be sure that no one on site can tamper with them without being detected.

--
I am TheRaven on Soylent News
Re:Force secure boot on unconditionally? by Anonymous Coward · 2017-11-20 06:54 · Score: 0

installing my own keys.....by flipping physical switches
You want to have 2048 dip switches for entering your secure boot key? I'd rather use a GUI for that.
I think the GP meant: installing keys is impossible to do by default, unless you flip a switch or enable a jumper, in which case only then does the motherboard add new keys. Once your own keys are installed, you change the physical item back, and it is now impossible to alter the keys.
This would help in mitigating motherboard-level root kits.
Re:Force secure boot on unconditionally? by Anonymous Coward · 2017-11-20 07:34 · Score: 0

Of course that's what I meant, the parent poster intentionally misunderstood me.
Re:Force secure boot on unconditionally? by skids · 2017-11-20 09:12 · Score: 1

There's a solution to that: When the DIP switch is flipped, everything gets completely erased before any access to the key-loading utility is allowed. It's already done that way on some brands of ethernet switches... you can always bring the switch back to baseline if you forgot the password, but if you set it up in this certain mode, doing so erases all your keys and configuration (though I doubt it is actually very secure to a JTAG case intruder).
So, that reduces the problem to: someone who can flip a dip switch can totally destroy your computer. Which isn't a big deal because if they are in a position to do so, they could also just spill coffee on it, or otherwise fry it.

--
Someone had to do it.
Re:Force secure boot on unconditionally? by Anonymous Coward · 2017-11-20 09:44 · Score: 0

Maybe not. He could just be retarded.
Re:Force secure boot on unconditionally? by Junta · 2017-11-21 07:17 · Score: 1

Well SecureBoot and TPM don't really relate.
SecureBoot merely validates that the OS booting is 'a' legitimate OS (for some value of legitimate). For the most part it means 'microsoft thinks this isn't malware'.
TPM gets into more specifics, and even it explicitly has the concept of physical presence as a way to 'recover' things.
However, a best practice there is for you to have an encrypted volume, with the keys sealed to TPM PCRs. Any TPM 'recovery' will make that sealed copy forever unrecoverable. So someone with physical presence can always reinstall the box, they may get forever locked out of the contents. Generally the key is additionally passphrase protected, so the sealing to TPM PCRs is a measure to allow automated boot so long as no shenanigans happen (breaking into firmware setup, breaking into grub cfg, etc).

--
XML is like violence. If it doesn't solve the problem, use more.
Re:Force secure boot on unconditionally? by Junta · 2017-11-21 07:18 · Score: 1

In consumer market, true, and there the mandatory 'replace key using firmware config menu' is passable.
In business market, it is exceedingly common to ship computers without OS image and the business receiving is responsible for OS load choice, which is where scalable automation is critical.

--
XML is like violence. If it doesn't solve the problem, use more.
Re:Force secure boot on unconditionally? by thegarbz · 2017-11-21 09:58 · Score: 1

Indeed, and in that market it is even more common to find Windows, hence it makes sense that the Windows key is preloaded.

From the motherboard by omnichad · 2017-11-20 02:13 · Score: 2

I doubt this would prevent someone from running a BIOS emulation layer through an EFI boot loader, just removing it from the EFI firmware. Can anyone confirm?

Re:From the motherboard by Junta · 2017-11-20 02:30 · Score: 1

Note that usually BIOS boot is a BIOS emulation layer ('CSM') hosted in the firmware.
The usual approach has been that Intel reference platform included that emulation. Moving forward, they plan not to, however system vendors may opt to include it of their own volition.
Of course, in order to suspend UEFI runtime services, the UEFI would have to cooperate, so emulating BIOS without the cooperation of the firmware platform would be pointless, since you have the relatively small downsides of UEFI without the upsides.
Note that every OS in a long time has been UEFI boot capable. RHEL6 is UEFI bootable, SLES11 is UEFI bootable, and those are the two likely oldest distributions likely to be executed nowadays.

--
XML is like violence. If it doesn't solve the problem, use more.
Re: From the motherboard by Anonymous Coward · 2017-11-20 02:36 · Score: 1

Hell, Intel could do this today with their MIMIX in the north bridge. Whole system boots clean and secure. BIOS comparability is an add on module to MINIX. Hell, they can (and do) be a hyper visor. So Linux and windows and the rest of the OSes can run side by side out the door.
Re: From the motherboard by Anonymous Coward · 2017-11-20 03:05 · Score: 0

So I have a.out and .so files in firmware? Can't wait to get these two guys together.

As one who works at a vendor.... by Anonymous Coward · 2017-11-20 02:13 · Score: 5, Interesting

Intel has set deadlines for the death of BIOS and they came and passed and there was still BIOS.

This time they seem a bit more serious about it, but the UEFI vendors are planning to continue allowing CSM so long as they have customers.

Intel NICs may stop providing BIOS boot roms, new Intel storage devices may be only UEFI bootable. It will get harder and harder and more and more cases will require UEFI boot.

UEFI boot has gotten pretty normalized, it's a bit weird to formalize vfat as a required portion of the standard, but it is better than the MBR approach. UEFI runtime services are not as good as they should have been, but they do however take some memory away from the OS that BIOS and BIOS style boot of UEFI did not have to reserve.

Re:As one who works at a vendor.... by wierd_w · 2017-11-20 02:46 · Score: 5, Informative

Low memory is also significantly less important on a UEFI system, because it boots straight into protected mode. Eventually, Intel will completely do away with trappings like v86 mode and pals, because they wont really be needed or useful, and will just be gobbling up die space.
What complicates intel's master plan, is that DOS (especially since the freedos project is very mature and has no licensing fees) is a very approachable target for many applications even in the modern era (Many things, from airport metal detectors to vinyl cutters, to industrial robots and pals), and that requires BIOS to operate. That you do not need to lug around a huge OS stack (DOS lives comfortably in less than 1mb of RAM), and dont have to contend with hundreds of multitasking processes (So your single task-oriented solution does not end up competing for resources or hardware events, because it is operating at realtime instead of time slices or having to wait for spin locks to disengage, etc) makes DOS a very approachable platform even today.
Intel just does not like that. It sees UEFI and their management processor security device model being the future in modern computing, and much like AMD, probably will only give up the keys to the management engine's castle after the vandals storm the place. (Meaning CoreBoot and pals will have to find ways to smash down the custom minix's doors and take over by force to overcome the designed security features of the processor, and hand them over to proper user control.) This is because the premise of the technology defacto asserts that the end user is not capable of being trusted with the security of the platform, and that only trusted persons or entities (orgs) can be vested with that responsibility. (This is at odds with GNU's philosophy.) Intel has many deep-pocketed orgs demanding this level of digital lordship, (microsoft *AND* apple being among the big ones), so the money is in giving the big pocketed groups what they want, which is mutually exclusive to projects like coreboot.
Re:As one who works at a vendor.... by swb · 2017-11-20 03:17 · Score: 1

Isn't the bigger question "When will virtualization vendors stop supporting it?"
It almost doesn't matter as long as the major virtualization platforms continue to support BIOS boot. Supporting older software on new hardware has long been a strength of virtualization.
Re:As one who works at a vendor.... by TheRaven64 · 2017-11-20 05:46 · Score: 2

Eventually, Intel will completely do away with trappings like v86 mode and pals, because they wont really be needed or useful, and will just be gobbling up die space.
I'd be very surprised if they weren't entirely microcode today. Who cares if every real mode instruction takes 10 cycles to complete - no customers large enough to care about have performance critical real-mode code, and the few that do are probably happy if it's a few thousand times faster than their 80286. If it's in microcode, it's taking a trivial amount of die space and none in performance-critical parts.

--
I am TheRaven on Soylent News

As expected... by Anonymous Coward · 2017-11-20 02:20 · Score: 3, Insightful

Deliberately limiting customer choice and putting the machine that much closer to just being outright owned by the manufacturer, no matter who paid for it.

And as per usual, it's in the name of "security." The current UEFI standard means that the manufacturer doesn't have to let you add boot signature keys to the firmware, either. While there will be machines that can bypass this "upgrade," they'll be sure to slowly be priced sky high.

Let's see how long it takes Microsoft to try to cram Windows 10 S down all our throats and choke out any programs they can't control, and pay off the manufactures not to include facilities to add keys by end users except for an ever-increasingly expensive high end. After that, who knows what they'll try to force you into? They've already been talking about forbidding users from accessing websites they don't like. Or the "anti-cheating" features they're adding? You'll be able to turn them off... just like you could turn off UEFI secure boot, in the beginning.

Re:As expected... by Anonymous Coward · 2017-11-20 08:49 · Score: 0

Linux works just fine with UEFI and secure boot.

so I Have to reflash my SAS cards to uefi mode? by Joe_Dragon · 2017-11-20 02:21 · Score: 0

so I Have to reflash my SAS cards to uefi mode? why do I really need a full GUI for a server that's only vga out is used for the impi card?

Re:so I Have to reflash my SAS cards to uefi mode? by Anonymous Coward · 2017-11-20 03:54 · Score: 0

Is this an issue with SAS cards? I just got an Avago SAS3081E-R 3Gb/s card for $16. From the initial testing on my FreeNAS 11 file server, I could probably transfer my hard drives to this card without any problems. When I rebuild my file server in five years, I'll probably have a different SAS card if my replacement hard drives are greater than 2TB.

Completely Untrue by Anonymous Coward · 2017-11-20 02:24 · Score: 4, Insightful

'Removing the legacy BIOS support will mitigate some security risks, needs less validation by vendors, allows for supporting more modern technologies,

Don't twist the wording - tell the truth.

Last time I looked I have NEVER seen a bios attack, excluding published NSA exploits.
The correct wording would be obsoleting older devices and pathways that support unconditional video decoding, and preventing other means to turn off underhanded telemetry and back door audits.

UEFI has plenty of proven security risks including a back door management interface that cannot be turned off. UEFI is flawed by design, and is pandering to Hollywood generally.

The sad thing is that Raspberry Pi or similar will soon be capable of 4K video processing, as are some streaming boxes now, so Hollywood has already lost out to sub $80 boxes.

Re:Completely Untrue by thegarbz · 2017-11-20 05:17 · Score: 4, Informative

Last time I looked I have NEVER seen a bios attack
Found a millennial. Those of us with a few more grey hairs on our beards remember BIOS modifying related malware basically showing up as one of the originals during the birth of PC malware.
That's to say nothing of the fact you've had your eyes closed to multiple cases over the past few years, to say nothing of the several that have been discussed on Slashdot in the past.
Re:Completely Untrue by Anonymous Coward · 2017-11-20 07:56 · Score: 0

Attacks against a properly written BIOS are very rare. Attacks against UEFI are extremely common. Malicious BIOS is very easy to get rid of. Malicious UEFI modules cannot, in most cases, be removed and require that the entire computer be crushed and binned.
The default UEFI contains malicious modules by design that cannot be removed or disabled. The BIOS boot loader does not.
Bad design of the BIOS boot code leaves it susceptible to boot malware such as the Monkey Virus, for example.
Bad design of UEFI leaves it susceptible to all sorts of malicious crap that has been in the news over the years since EFI was introduced.
Re:Completely Untrue by Anonymous Coward · 2017-11-20 09:13 · Score: 0

"The default UEFI contains malicious modules by design..."
Do you have a credible source for that statement? Or are you just bloviating?
Re:Completely Untrue by sexconker · 2017-11-20 10:07 · Score: 1

UEFI is flawed by design, and is pandering to Hollywood generally.
Give it a few days. Someone will step forward and #metoo accuse UEFI of sexually harassing them, then UEFI will be axed.
Re:Completely Untrue by Anonymous Coward · 2017-11-20 10:15 · Score: 0

Hey, I'm a millenial and:
a) I have plenty of gray hair on my beard.
b) I remember the CIH/Chernobyl malware, and how it destroyed BIOSes.
The oldest millenials were born in the early 80s, and grew up using MS-DOS and coding in BASIC, so we know plenty about computers.
Re:Completely Untrue by redmasq · 2017-11-20 12:57 · Score: 1

Last time I looked I have NEVER seen a bios attack
Found a millennial.
Hardly a discerning statement for millennials. A BIOS that has a physical switch to prevent reflashing is difficult to attack, put not impossible. Non-volatile memory used for configuration is a potential vector, but would likely need to be specific to BIOS vendor and version. In the case that a physical control is not present, or just left on, malware could, after gaining a privilege execution level attempt to replace or patch the BIOS. I would imagine some systems protect against this with a non-flashable ROM portion that verifies the signature of the flashable BIOS prior to executing. In infection would effectively (hopefully soft) "brick" the system, but the integrity could be at least partially preserved. (I have also heard tall tales about keyboard buffers [or was it initialization firmware] and the A20 line [part of the bus] being used as an attack vector, but never actually bothered to check the validity)

UEFI does remove the potential vector of "boot sector infections" since it uses a different method of loading the operating system. While I lack knowledge of specifics, I am aware that UEFI does have a means of providing extensions as well as its own support for non-volatile storage. Hypothetically, these are vectors for attack. Concerning secure-boot, I would consider it, on paper, to be more secure; however, in the same fashion someone getting their hands on the private key to sign a BIOS or other firmware could attack the system, someone could also sign a UEFI loader application and have a privilege-escalated malware use it for an attack vector. Also, as with any loader chaining, if an already signed loader is exploitable, there is still a vector of attack.

For the TL;DR, pretty much everything is attackable. If security matters to you, understand what kind of system you have and what are the acceptable risks for the cost and effort you are willing to undertake.

Also, concerning a thought from another comment that UEFI is malicious by design, there is an economic pressure that major OS vendors would have on Intel and motherboard manufacturers to keep things in their court, but there is also pressure from consumers (both retail and business) that wish to maintain control of their systems.

ok now force Vendor to give you impi bios updates by Joe_Dragon · 2017-11-20 02:27 · Score: 2

ok now force Vendor to give you impi bios updates with out needing to buy an addon key to unlock that.

Walled garden for bootloaders? by lucasnate1 · 2017-11-20 02:34 · Score: 1

Does this mean that from now on, just like apps on a mac, everything we run during boot time has to be signed by a corporate?

--
Avantgarde Hebrew science fiction

Re:Walled garden for bootloaders? by Anonymous Coward · 2017-11-20 02:46 · Score: 0

Maybe if you buy hardware from a company like Apple that locks it down. Otherwise you can just turn secure boot off, or load your own key.
Re:Walled garden for bootloaders? by Anonymous Coward · 2017-11-20 02:47 · Score: 0

Does this mean that from now on, just like apps on a mac, everything we run during boot time has to be signed by a corporate?
No. I patch and sign modules all the time to run my LG Ultrawide monitor in its native resolution on my Mac Mini. Nothing signed by corporate about it.
Re:Walled garden for bootloaders? by Dog-Cow · 2017-11-20 03:30 · Score: 1

I run unsigned apps on my mac, literally every day.
Re:Walled garden for bootloaders? by lucasnate1 · 2017-11-20 04:28 · Score: 1

Shit, I meant unhacked iphone :(

--
Avantgarde Hebrew science fiction
Re:Walled garden for bootloaders? by Anonymous Coward · 2017-11-20 08:41 · Score: 0

Don't spread lies. Apple is NOT locked down, your just to stupid to own a computer AND/OR post on /.
Re:Walled garden for bootloaders? by Hognoxious · 2017-11-20 09:41 · Score: 1

your just to stupid

There's a lot of it around.

--
Confucius say, "Find worm in apple - bad. Find half a worm - worse."

Mere Mortal question by McLae · 2017-11-20 02:35 · Score: 3, Interesting

OK, so what does this mean for me? Too much jargon to decipher. And this is new systems, right?

References?

Re:Mere Mortal question by Narcocide · 2017-11-20 03:22 · Score: 2

The short version is that now all your new computers will be capable of contracting viruses that you can't get rid of just by reformatting all drives and reinstalling your OS.
Re:Mere Mortal question by Anonymous Coward · 2017-11-20 06:39 · Score: 0

This means that after less than 40 years of existence, the PC will be dead and buried.
No more MS-DOS, PC-DOS, DR-DOS, CP/M-86, UCSD P-System, 16-bit OS/2, Windows 3.1 or Minix 1.5,
so your old games no longer run.
Re:Mere Mortal question by Anonymous Coward · 2017-11-20 06:43 · Score: 0

That and we're one step closer to being prevented from installing our os of choice on our machines. All it takes is one automatic "security" upgrade because [insert flimsy pretext here] and your desktop ceases being a pc and becomes an oversized ipad/phone - a locked-down ad-serving revenue spewer that lives or dies at the whim of $software_company.

Will Google end Intel support? by Anonymous Coward · 2017-11-20 02:37 · Score: 2, Funny

Replace Your Exploit-Ridden Firmware with Linux

Google has already been thinking about switching to POWER chips. Maybe this UEFI thing will be the final push they need?

End 16 bit real mode mode? by halfdan+the+black · 2017-11-20 02:49 · Score: 1

Does this mean x86 no longer has to support 16 bit mode? My understanding is that with EFI, the processor never enters real mode, and initializes directly in protected mode.

Re:End 16 bit real mode mode? by Dwedit · 2017-11-20 04:20 · Score: 1

Even Windows 10 32-bit edition will still run 16-bit Windows 3.1 Applications. So as long as people install the 32-bit edition of Windows 10, the processor will need to have 16-bit support.
Re:End 16 bit real mode mode? by halfdan+the+black · 2017-11-20 04:32 · Score: 1

I thought those ran on a virtual machine. Even if NT4, if I remember right, DOS/16 bit apps did not have direct hardware access and ran in some sort of virtual machine enviornmnet.
Re:End 16 bit real mode mode? by omnichad · 2017-11-20 04:50 · Score: 1

It runs the same instructions directly on the CPU, but Windows implements the DOS system interrupts differently.
If it was a virtual machine environment, then 16-bit apps would work on 64-bit Windows. They don't.
Re:End 16 bit real mode mode? by Anonymous Coward · 2017-11-20 04:59 · Score: 0

Yes, but that environment is created by the CPU. If you remove the 16-bit real support, the OS would have to use emulation, not VM methods.
Re:End 16 bit real mode mode? by Anonymous Coward · 2017-11-20 05:31 · Score: 1

As per the Intel 64 and IA-32 Architectures Software Developer's Manual on page 8-20 in Volume 3A, the boot processor comes up in real mode and begins executing whatever is in memory at 0xFFFF_FFF0h. On step 8 out of 15 it switches the processor into protected mode.
Re:End 16 bit real mode mode? by TheRaven64 · 2017-11-20 05:52 · Score: 1

That said, DOSBox on non-x86 hardware does emulate 16-bit and works very well. It was fast enough to run Worms (which I originally played on a Pentium) on my 1GHz PowerPC Mac and has emulated CPU speed control so I could use it to run a bunch of things that hadn't worked correctly since the original PC because they assumed that they could use delay loops for timing.

--
I am TheRaven on Soylent News
Re:End 16 bit real mode mode? by Hal_Porter · 2017-11-20 06:06 · Score: 2

My understanding is that with EFI, the processor never enters real mode, and initializes directly in protected mode.
All current x86/x64 chips start in real mode. So EFI has to make a switch to protected mode with long mode enabled.
However Intel has sold chips which boot up in protected mode in the past. E.g.
https://en.wikipedia.org/wiki/...

The Intel 80376, introduced January 16, 1989, was a variant of the Intel 80386SX intended for embedded systems. It differed from the 80386 in not supporting real mode (the processor booted directly into protected mode) and having no support for paging in the MMU. The 376 was available at 16 or 20 MHz.
Of course so long as the PC standard includes the Bios, such a chip can't be PC compatible. Actually the 376 is a perhaps a bad example because it didn't have an MMU. However suppose you had a legacy free x64 chip which booted up in long mode and didn't support real mode. Such a device would be able to run EFI. And since v86 mode isn't supported in long mode - the reason 64 bit Windows can't run Dos or Win16 applications whereas 32 bit Windows can - it would be possible to disable v86 mode too.
I'm not sure how you'd handle running 32 bit applications on a 64 bit OS - presumably a legacy free chip would either implement bits of the normal protected mode architecture - the GDT for example so it could distinguish 32 bit code segments from 64 bit ones - or it might have some sort of mode bit in a register to decide.
Or you could rip out 32 bit mode support too, and just handle it via JITting the code to 64 bit.

--
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Re:End 16 bit real mode mode? by K.+S.+Kyosuke · 2017-11-20 09:24 · Score: 1

It IS a virtual machine. It's a virtual 8086. But that doesn't work in the long mode, which is why there's no 16-bit mode anymore on 64-bit Windows. That functionality depended on hardware support, so when the hardware support disappeared, so did this Windows feature.

--
Ezekiel 23:20
Re:End 16 bit real mode mode? by Anonymous Coward · 2017-11-21 15:14 · Score: 0

And Dosbox on linux was slow on my 2.9GHz PC when I tried to run doom with music (fine, without)

and give AMD the server market? by Joe_Dragon · 2017-11-20 02:57 · Score: 3, Insightful

and give AMD the server market?

Re:and give AMD the server market? by gweihir · 2017-11-20 04:26 · Score: 1

Indeed. I know one large financial institution that is moving to Linux and another one that is planning it. They both also have a small number of Windows application servers, and these cause a large part of the problems with the software-landscape.
Nobody serious runs anything mission-critical on Windows. It is either Linux, one of the free BSDs or a commercial Unix. Even on the mainframe it becomes more and more Linux, because it is easier to get developers for that than for traditional mainframe coding.
Intel will not even dream of making use of Linux hard on the server. They will make very sure that at least their server offerings are as compatible as possible.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Time to by DontBeAMoran · 2017-11-20 03:01 · Score: 1

Yeah! FreeBSD for the win!

--
#DeleteFacebook

Or ARM by Anonymous Coward · 2017-11-20 03:15 · Score: 0

I just replaced my main home server with a RPI3. A little slower, but sufficient.

RPI3 for TV box too. (OSMC).

For Intel to come back into my home server, it would need to have competitive performance per power consumption (heat), be cheap and small (board), and have effortless Linux support (Linux is primary OS on RPI3 and other ARM boards, unlike most all shipped Intel devices).

UEFI has been proven to no be that secure by evolutionary · 2017-11-20 03:21 · Score: 0

UEFI isn't that secure anyway. It isn't that hard to break. Personally I think the only reasons for putting it in place was to give Linux a hard time (make i hard for people to move to Linux, thank you M$) while at the same time to give a false sense of security. Given that Intel (and AMD in some processors) have an OS on the CPU that can effective be a full privileged back door, I wouldn't be surprised if UEFI had elements of the same:

https://threatpost.com/cert-wa...

It would be nice if computer hardware was actually made to fully protect the purchaser rather than other interested parties. (In OS we have Linux)

--
"Imagination is more important than knowledge" - Einstein

Redhat 5 (2007) and maybe RHEL4 too by raymorris · 2017-11-20 03:22 · Score: 1

I believe Redhat 5 (from 2007) had EFI support, and a quick Google search suggests people booted RHEL4 from EFI, but I don't know if that involved any hacks.

Windows 10 S anti trust and eu browser choice iss by Joe_Dragon · 2017-11-20 03:59 · Score: 1

Windows 10 S has antitrust and eu browser choice issues. and no Linux on windows 10 s as well.

Why does it matter? by thogard · 2017-11-20 04:21 · Score: 5, Insightful

BIOS and EFI should only hand the boot loader an bit of RAM and boot image and enough extra stuff to load anther few megabytes off the boot source. I don't care if you call the BIOS something else like UEFI . Everything else should be up to the boot loader and the OS. I don't need the BIOS (or its successors) to test all the memory, just the 1st gig or so. If it is booting off disk, I don't need it to know about the network. I don't need it to know about the video or even the keyboard unless there is a problem. I only need it to know about NVE if I'm booting off that. The OS should rescan all the hardware and ignore anything provided by the BIOS.

Excessively complicated BIOS is a security risk not matter what it is called.

Re:Why does it matter? by b0s0z0ku · 2017-11-20 05:46 · Score: 1

Better yet, divorce the boot source and "BIOS" firmware -- load most firmware into a special area of RAM (or dedicated RAM) from a specially-formatted micro-SD card. Removable ROM would also remove any possible issues with "bricking" a system due to a bad update.
Re:Why does it matter? by drinkypoo · 2017-11-21 00:43 · Score: 1

I would care if I still ran DOS, or a Windows booted from DOS. Otherwise, there's just no reason to give a damn.

--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"

Trading one security risk for another by Anonymous Coward · 2017-11-20 04:33 · Score: 0

Except you wouldn't know and can't do anything about it. Thanks ME.

Coinciding with the Windows 7 EOL by Anonymous Coward · 2017-11-20 04:44 · Score: 1

This will stop 7 users which already don't get supported updates anymore. This will continue 10's spyware regime with the alternatives being $ystemD infected Linux, obscure BSDs or having to go to Macs or Chromebooks, which won't have the games and business apps. Otherwise people will have to use old hardware which will go up in price.

Captcha: hooked.

Intentionally Myopic. Always Useful. by Anonymous Coward · 2017-11-20 04:50 · Score: 0

Intentionally Myopic. Always Useful.

None of this is about security.. it's corp control by Anonymous Coward · 2017-11-20 04:51 · Score: 0

A five-cent component, a simple switch on the mobo wired inline with the flash WP/ line, would give us a secure unhackable BIOS. It's unbelievable how much BS the industry is creating in order to craft a corporate lockdown on boot firmware.

The fact that Microsoft weaseled its way into being the gatekeeper for UEFI boot is just ridiculous. If it gets bad enough we'll have to start using OpenCore/Wishbone based systems made in people's garages to truly have systems we can audit, control and trust. Back to the homebrew days I guess, assuming it isn't outlawed by then.

Security Fundamentals 101 by Anonymous Coward · 2017-11-20 04:53 · Score: 0

Removing the legacy BIOS support will mitigate some security risks

The above statement is b.sheet. UEFI is everything except secure.
In computing, simpler systems are ALWAYS easier to secure.

The end for redundant software RAID on Linux by Anonymous Coward · 2017-11-20 04:57 · Score: 0

Imagine you having a RAID 6 array. To which of the drive do you install the EFI partition? Current UEFI implementations do not allow multiple such partitions, as far as I know.

Re:The end for redundant software RAID on Linux by Anonymous Coward · 2017-11-20 08:58 · Score: 0

With Gigabyte, ASUS or Asrock motherboards I've experienced no problems with multiple VFAT boot partitions. The UEFI just shows it as multiple places to choose to boot from. It's no different whether you're dual booting Windows and Linux vs Linux GRUB2-EFI bootloader installed on multiple drives.

Remove AMT/IME first! by Anonymous Coward · 2017-11-20 05:04 · Score: 0

If at Intel they are really concerned about security they should destroy their AMT & IME ecosystem.

Re: Windows 10 S anti trust and eu browser choice by b0s0z0ku · 2017-11-20 05:14 · Score: 1

Surface Laptop is a Windows 10S device -- AFAIK, Secure Boot can be turned off on it, though it has compatibility issues with its keyboard and Linux.

Re:Time to by Archangel+Michael · 2017-11-20 05:37 · Score: 1

Do people really run OS on iron still?

I always put virtualization OS on first, and then Install the OS on top. Yes, even when the Guest OS is the only one. Makes for moving to another hardware platform easy.

--
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.

Re: Time to by Anonymous Coward · 2017-11-20 05:56 · Score: 0

Short answer: yes. Long answer: there are many legacy applications that require the high transaction processing while maintaining near perfect accuracy like in banks.

There's a lesson here by boudie2 · 2017-11-20 05:58 · Score: 1

Once again we're left at the mercy of a multinational corporation who doesn't give a shit about anything except maximizing profits. Intel and google like to peddle their vendor lock-in as security features. They're so dishonest, but that's good. Every so often you have to remind yourself that despite the nice talk, they're not your friend. Just pretending.

Brian Richardson by Anonymous Coward · 2017-11-20 06:33 · Score: 0

Before everyone gets worked up, this Brian Richardson guy is a dumbass. He is supposed to be doing "UEFI Marketing." He does not have the authority to make these type of decisions, he pulled this out of his ass, hoping it would stick so he has something to put on his performance review this year. Most of the senior UEFI people within Intel don't listen to him.

It just so happens that most of the product teams decided that they weren't going to put CSM in to their reference firmware implementations by year 2020, just to reduce the amount of effort Intel spends on the reference firmware implementations. The rationale there was pragmatic... we aren't using CSM really, and it really complicates the UEFI implementation. There is usually at least one tricky bug every year in the CSM. All it takes is one big customer saying they still want CSM and its back regardless of what Brian says. Nothing is being done to prevent AMI, Phoenix, Insyde, etc. from shipping 2020+ systems with CSM.

Big Brother Baked In! by Anonymous Coward · 2017-11-20 06:35 · Score: 0

Thanks Intel, you traitorous whores!

Intel UEFI by jazzis · 2017-11-20 06:53 · Score: 1

https://firmware.intel.com/sit... OS X /macOS has been IFI /UEFI for Decades so if you need a UNIX for Intel UEFI.... Look no futher/

Re:Intel UEFI by b0s0z0ku · 2017-11-20 07:07 · Score: 1

Problem is that MacOS is increasingly locked down (hiding the disable for Gatekeeper) and hobbled by Apple. It's also tied to Apple hardware. Some of us want to run a really free OS, not the watered-down thing that OS X has become.

shared USB bus for networking and disk limits by Joe_Dragon · 2017-11-20 07:44 · Score: 1

shared USB bus for networking and disk limits the over all use.

Pure 64? Ever? by Zo0ok · 2017-11-20 08:18 · Score: 2

How about dropping everything except 64 bit mode. Boot straight to 64 bit, no turning back, no legacy, no compability?
How many CPUs actually ever run anything than 64 bit today?
(I do understand many windows desktops do, but apart from that: servers, linux computers, chromebooks should never need anything less than 64 bit mode)

Re:Pure 64? Ever? by Anonymous Coward · 2017-11-20 09:18 · Score: 0

The thing is, I suspect that one of these days MS will announce the end of 32-bit support in Windows. They've been super-supportive of offering 32-bit and 64-bit in parallel for nearly 20 years now. One has to wonder though, how long they will continue to do so.
The support for legacy hardware pushes them to say Yes. The endless stream of 64-bit capable new hardware pushes them to say No.
At this stage, I wouldn't be too sad to see the end of 32-bit support. 32-bit was a good platform but that era is drawing to a close.
Re:Pure 64? Ever? by Zo0ok · 2017-11-20 09:43 · Score: 1

I agree. Especially since x64 is a much improved/changed instruction set compared to x86. It is probably not that much more expensive for Intel or AMD to deliver both 32/64 in the same chip, but it must come at some cost. I think Xeon processors, and ultra low end (made for Chromebooks), could benefit from 64-bit only.
For instruction sets like PPC where 32/64-bit were essentially the same its a different story.
Re:Pure 64? Ever? by Anonymous Coward · 2017-11-21 00:17 · Score: 0

as long as virtual 32,16 and 8? bit machines are supported by some random 64 bit virtualization program such as ie. virtualBox... then I see no problems with ditching support for software written for 32 bit and below instruction sets
Re:Pure 64? Ever? by toddestan · 2017-11-22 07:00 · Score: 1

My guess is that would, at the absolute soonest, would be sometime in 2025 for ending 32-bit support on Windows assuming that Windows 10 follows the same 10-year support cycle, and 32-bit Windows 10 is the last of the 32-bit line. That's as far as the desktop goes, things like embedded versions of Windows would likely still have support for at least several more years on top of that (heck, even embedded XP is still supported until 2019...)
Right now, the 32-bit Windows is what I call the compatibility Windows as it works with all kinds of legacy stuff, both hardware and software, and in many ways surprisingly well (I've successfully installed drivers written for Windows 2000 on 32-bit Windows 10 and it just worked). Microsoft has always been a bit hesitant to cut support for something if enough of their enterprise customers demand it, but maybe in 8 years it might be time.
On the server side, 32-bit support is coming to an end in 2020 as the last version of Windows Server to support 32-bit is 2008. My guess is few Windows Servers are still on 32-bit, and the majority of the ones that still run it are old.

Re:Redhat 5 (2007) and maybe RHEL4 too by Anonymous Coward · 2017-11-20 08:35 · Score: 0

Many Linux distributions support UEFI and secure boot now.
SUSE Linux Enterprise Server
openSUSE
Redhat Enterprise Linux
CENTOS
Fedora
Ubuntu Server
Oracle Linux

Re: Time to by JackieBrown · 2017-11-20 09:36 · Score: 1

Short answer: yes. Long answer: there are many legacy applications that require the high transaction processing while maintaining near perfect accuracy like in banks.

That's a long answer? We really have become the twitter generation...

Re:Time to by sexconker · 2017-11-20 10:01 · Score: 1

There are people who still run on big iron, i.e., mainframes.
Mainframes are resilient, fault tolerant, upgradable without downtime (many have hot-swapable RAM, CPUs, etc.), and in general fucking reliable.

Even with HA / fault tolerant VM systems, you're relying on communication between external systems to identify failure, recover/transition automatically, and rectify any data inconsistencies. For many transactional systems, that's a no go. Many systems use distributed databases, fault tolerant / HA VMs, etc. behind the front-end, but transactions won't be considered truly confirmed until they hit the mainframe.

This is why we need open hardware. by Anonymous Coward · 2017-11-20 11:30 · Score: 0

We have open software. The entrenched vendors don't like it.

It is time that we start producing low cost open hardware platforms from the BIOS on up. No ARM does not count.

UEFI is crap by Anonymous Coward · 2017-11-20 12:01 · Score: 0

UEFI has not solved anything just created new problems and broken compatibility. To be honest it's essentially garbage. I would much rather have something like coreboot (I run libreboot on this laptop and it's great!).

Who here actually has gained anything from UEFI anyway?

The real problem by DaMattster · 2017-11-20 12:09 · Score: 1

The real problem is not UEFI but Intel's ME.

Re:Time to by Anonymous Coward · 2017-11-20 20:13 · Score: 0

Virtualization has about a 10% performance overhead. When turn around time is important, 10% matters. None of our compute servers are virtualized.

And the winner is ... by Anonymous Coward · 2017-11-22 05:16 · Score: 0

Also, concerning a thought from another comment that UEFI is malicious by design, there is an economic pressure that major OS vendors would have on Intel and motherboard manufacturers to keep things in their court, but there is also pressure from consumers (both retail and business) that wish to maintain control of their systems.

Yes, and this unfortunately shows which side is winning.

Slashdot Mirror

Intel Planning To End Legacy BIOS Support By 2020, Report Says (phoronix.com)

122 comments