Always good to have people on top of things. Software at least this go'round. Unlike some of the other issues being had on the other side of the fence. Man. Never knew these BIOS' were quite like that these days. I mean do we even need mouse support inside the BIOS? Still pretty ignorant myself on the true functional differences between this of the new standard BIOS of those ten plus years ago. I mean were BIOS issues like this an issue back then?!? And what was the cause for this sudden change to make BIOS's so GUI and all??

This is an awful lot of trouble for someone who already has physical admin access to the system.

Kool64:

This is an awful lot of trouble for someone who already has physical admin access to the system.

Exactly! The thing is, nearly all of the exploits that have popped up recently are like this. For this reason, I see little point to all of the mitigation tactics being employed that slow down the CPU. If one locks down the OS, browser(s), and other software better then the exploits can not run or be installed. This sounds like a potential application of AI to me.

What? I want it. If we can manipulate AGESA, we can get fine tuned boost and voltages.

Fox2232:

What? I want it. If we can manipulate AGESA, we can get fine tuned boost and voltages.

I agree, let me OC via less reported power used hacks 😀

DeskStar:

I mean do we even need mouse support inside the BIOS?

Nope!

DeskStar:

Still pretty ignorant myself on the true functional differences between this of the new standard BIOS of those ten plus years ago. I mean were BIOS issues like this an issue back then?!? And what was the cause for this sudden change to make BIOS's so GUI and all??

Although I prefer the legacy system, EFIs were a necessity for lots of little things here and there, like improved security, larger storage for firmware, locking down hardware to a specific OS (like Mac), and booting drives larger than 2TB (I might need to be corrected on that one). Having fancy graphics and a mouse pointer were just bonus features from getting bigger on-board chips. Though I'd like to remind everyone that this was once a thing back in the i486 days (take note of the date): https://i.ytimg.com/vi/2Im0aK5Nnrs/maxresdefault.jpg If motherboard manufacturers could pull off something like that on an EEPROM that was probably about 128KB, I don't see how a brand like MSI struggles to fit complete AGESA code with a working GUI on 16MB. I assure you MSI: people are going to be much more bothered that their motherboard is incompatible with their CPU, than to not be able to see a graphic that their motherboard is supposedly "military class".

schmidtbag:

If motherboard manufacturers could pull off something like that on an EEPROM that was probably about 128KB, I don't see how a brand like MSI struggles to fit complete AGESA code with a working GUI on 16MB. I assure you MSI: people are going to be much more bothered that their motherboard is incompatible with their CPU, than to not be able to see a graphic that their motherboard is supposedly "military class".

The impact of the graphics are really not that big. Supporting a few dozen CPUs, each with their own microcode to load, that is what takes up 90% of all that space (plus all the other mandatory stuff you won't get rid of). They could take out the splash image and fit in one more CPU or so, but its not going to make the difference of supporting *everything* on 16MB, or not being able to. It'll still not fit. Incidentally MSI has already produced "Lite" UEFI variants without the graphics due to these problems for some 300 series AM4 boards. But considering the problem already existed back in X370 days, its not going to go away with even more CPUs being added.

AMD will be releasing AGESA updates that mitigate the vulnerability which will not affect performance in any way. It seems the latest platforms are already immune to the vulnerability.

I mean, this how it's supposed to work... no perf hit, newer models already immune. Quite contrary to Intel, where there's perf hits, and older models are usually immune. *read the news again and noted this*

nevcairiel:

The impact of the graphics are really not that big. Supporting a few dozen CPUs, each with their own microcode to load, that is what takes up 90% of all that space (plus all the other mandatory stuff you won't get rid of). They could take out the splash image and fit in one more CPU or so, but its not going to make the difference of supporting *everything* on 16MB, or not being able to. It'll still not fit. Incidentally MSI has already produced "Lite" UEFI variants without the graphics due to these problems for some 300 series AM4 boards. But considering the problem already existed back in X370 days, its not going to go away with even more CPUs being added.

Isn't the microcode stored on the cpu? it gets loaded every time? i Wish i could see the real code that is there and what takes how much space.

@schmidtbag wholly hell I remember that from my father's 386-x486 days! Wow that picture struck some memories thank you. HA! Comanche was a killer then along with black thorn. That is after Prince of Persia of course. And thank you for the lesson of course.

schmidtbag:

Although I prefer the legacy system, EFIs were a necessity for lots of little things here and there, like improved security, larger storage for firmware, locking down hardware to a specific OS (like Mac), and booting drives larger than 2TB (I might need to be corrected on that one). Having fancy graphics and a mouse pointer were just bonus features from getting bigger on-board chips. Though I'd like to remind everyone that this was once a thing back in the i486 days (take note of the date): https://i.ytimg.com/vi/2Im0aK5Nnrs/maxresdefault.jpg If motherboard manufacturers could pull off something like that on an EEPROM that was probably about 128KB, I don't see how a brand like MSI struggles to fit complete AGESA code with a working GUI on 16MB. I assure you MSI: people are going to be much more bothered that their motherboard is incompatible with their CPU, than to not be able to see a graphic that their motherboard is supposedly "military class".

And I love the MSI info as well. Who would have thought so much data was taken up by nonsensical placement of their own doing. I guess they could just get rid of it and save the space without the graphical backdrop. I mean miss out, or truly "miss out!"

schmidtbag:

Although I prefer the legacy system, EFIs were a necessity for lots of little things here and there, like improved security, larger storage for firmware, locking down hardware to a specific OS (like Mac), and booting drives larger than 2TB (I might need to be corrected on that one). Having fancy graphics and a mouse pointer were just bonus features from getting bigger on-board chips. Though I'd like to remind everyone that this was once a thing back in the i486 days (take note of the date): https://i.ytimg.com/vi/2Im0aK5Nnrs/maxresdefault.jpg If motherboard manufacturers could pull off something like that on an EEPROM that was probably about 128KB, I don't see how a brand like MSI struggles to fit complete AGESA code with a working GUI on 16MB. I assure you MSI: people are going to be much more bothered that their motherboard is incompatible with their CPU, than to not be able to see a graphic that their motherboard is supposedly "military class".

First, thanks for the memories I've tried to block out......lol I actually have experience with that BIOS configuration utility..... That was back in the days of serial ports for mice and parallel ports for printers..... Actually, legacy BIOS could have used more than 2TB.... The problem is that MBR lacks support for drives larger than ~2TB.... Instead of fixing a minor problem, MS wanted to created a much larger problem.... UEFI hasn't actually improved security. It's made things worse. The reason MS wanted the move to UEFI was for OS lock, which legacy BIOS couldn't do. If we were still using legacy BIOS, CPU support wouldn't be such a problem. My last LGA775 board supported processors from Prescott all the way to Penryn.... That's more processors than any AM4 board (or any other UEFI based board) will ever support.....

In short, the vulnerability involves an attacker with elevated system privileges to manipulate the AGESA microcode of the UEFI firmware to execute arbitrary code undetected by the operating system.

This was actually impossible to pull off with legacy BIOS.....

asturur:

Isn't the microcode stored on the cpu? it gets loaded every time? i Wish i could see the real code that is there and what takes how much space.

Microcode is stored in the BIOS/UEFI..... CPUID is stored on the processor.

sykozis:

First, thanks for the memories I've tried to block out......lol I actually have experience with that BIOS configuration utility..... That was back in the days of serial ports for mice and parallel ports for printers.....

lol I remember the first time I saw it and was blown away how the BIOS was more fancy than my previous DOS-only PC.

Actually, legacy BIOS could have used more than 2TB.... The problem is that MBR lacks support for drives larger than ~2TB.... Instead of fixing a minor problem, MS wanted to created a much larger problem....

Ah right. I knew I was off about something.

UEFI hasn't actually improved security. It's made things worse. The reason MS wanted the move to UEFI was for OS lock, which legacy BIOS couldn't do.

That actually isn't what I was referring to when I mentioned security; that's actually why I mentioned "locking down hardware to a specific OS" as a separate listed item. There are other mild forms of security in EFIs too, though they're not found in all platforms to my knowledge. Also, now that open-source OSes support SecureBoot, it does actually have some functions to improve security, like requiring signed drivers. Though, SecureBoot is one of the things I disable first when working on a new PC. It's so annoying.

schmidtbag:

lol I remember the first time I saw it and was blown away how the BIOS was more fancy than my previous DOS-only PC. Ah right. I knew I was off about something. That actually isn't what I was referring to when I mentioned security; that's actually why I mentioned "locking down hardware to a specific OS" as a separate listed item. There are other mild forms of security in EFIs too, though they're not found in all platforms to my knowledge. Also, now that open-source OSes support SecureBoot, it does actually have some functions to improve security, like requiring signed drivers. Though, SecureBoot is one of the things I disable first when working on a new PC. It's so annoying.

I started out in the i386 days..... First system I built myself was actually an AMD 486DX4-100. I was surprised when I got my first board that didn't support mouse in BIOS config. You can use drives larger than 2GB with legacy BIOS, but due to limitations of MBR, you can't have a single partition larger than 2.2TB. It's an artificial limit that could have been changed, but too many in the industry wanted to get away from legacy BIOS. With legacy BIOS, the worst you had to worry about on hardware side was a bricked motherboard. With UEFI, it can be used to gain control of the system. SecureBoot doesn't prevent malicious UEFI code. Legacy BIOS could actually be write-protected so it couldn't be flashed unintentionally. UEFI lacks such function. From a security standpoint, that's a major oversight when the UEFI can cause so many security related issues.