Modifying BIOS settings from within an operating system

[greenboard]

This is purely a theoretical question

Is it possible for an operating system to access / modify BIOS settings? Is the BIOS settings menu run just like an operating system, or does it have extra privileges and access that an operating system does not? If so where are these settings stored, and what mechanism is used to protect access to them?

I know they will be stored in an extremely non-standarised manner and it would be stupid to try and read or modify them, but I am just asking out of curiosity, to try and better understand the boot process. Would it be possible to create an OS that replicated the functionality of a BIOS settings screen?

Thanks in advance

[Octocontrabass]

Is it possible for an operating system to access / modify BIOS settings?

Sometimes yes, sometimes no. It really depends on the particular hardware (and firmware).

UEFI provides a runtime service for accessing and modifying the firmware settings. You may not be able to modify all settings this way.

Is the BIOS settings menu run just like an operating system, or does it have extra privileges and access that an operating system does not?

In newer PCs, the settings menu typically has privileges that your operating system does not.

If so where are these settings stored, and what mechanism is used to protect access to them?

In very old PCs, the settings are stored in the battery-powered RAM built into the RTC. Nothing prevents access.

In less-old PCs, the settings are stored in the firmware ROM, which is actually a type of EEPROM. Most chipsets can be programmed to block all writes to the firmware ROM until the CPU is reset. This way, the settings menu can have full access, then when it's time to boot an OS, the chipset is locked down. (In theory, a chipset could also block reads, but I'm not aware of any that can.)

With SMM, the chipset and firmware can work together to ensure only an authenticated user has access to rewrite the firmware ROM. This is probably how the UEFI runtime service works.

Would it be possible to create an OS that replicated the functionality of a BIOS settings screen?

Yes, but you might need to bypass several firmware security features to make it work.

[Ethin]

UEFI runtime services doesn't let you modify everything -- or it shouldn't. There are certain variables like the secure boot database that are (supposed) to be read-only to all system software after boot services have been terminated; if your able to write to those, then you've found either a vulnerability in the firmware or a non-compliant firmware implementation. And if you've found a non-compliant firmware implementation, I would be wary of everything else it tells you, purely because once you've found one thing that doesn't comply with the standard, there's a good chance that there's probably more that doesn't, too. But that's just me.

[bzt]

This is purely a theoretical question

Is it possible for an operating system to access / modify BIOS settings?

Yes.

Is the BIOS settings menu run just like an operating system, or does it have extra privileges and access that an operating system does not?

Neither. An operating system can access BIOS settings if they really want.

If so where are these settings stored, and what mechanism is used to protect access to them?

For BIOS, in the CMOS, so you can access them with IO ports just like you access the RTC date and time. There's absolutely no protection, only security by obscurity (meaning it is not specified what is stored and where; some positions are standard, but most of the time they are manufacturer specific. One example: there's two centuries variable on that list because different BIOSes use different offsets for that.)

n less-old PCs, the settings are stored in the firmware ROM, which is actually a type of EEPROM.

I've never seen such a BIOS, but I can imagine they exists.

I know they will be stored in an extremely non-standarised manner and it would be stupid to try and read or modify them, but I am just asking out of curiosity, to try and better understand the boot process. Would it be possible to create an OS that replicated the functionality of a BIOS settings screen?

Absolutely, so much that early Phoenix BIOSes did not provide a BIOS menu at all, rather a DOS application on a floppy to modify the settings. (There's also an unofficial "Phoenix BIOS Editor" application for Windows for later BIOS versions.)
For UEFI, no need for the UEFI run-time (which restricts your access), you can always reverse engineer the functions (or just check the source) and use the same instructions from your OS that the UEFI firmware does. Again, security by obscurity only. (Obviously Intel and M$ do not want you to know this, but in reality it is that simple. Many rootkits take advantage of this, and this is how a malicious OS application infects the UEFI with a trojan.)

Cheers,
bzt

[Korona]

"The BIOS uses the same instructions as the OS" is not the full story though. Lots of hardware has lock bits that can only be cleared by asserting the reset vector.

[bzt]

"The BIOS uses the same instructions as the OS" is not the full story though. Lots of hardware has lock bits that can only be cleared by asserting the reset vector.

True, but UEFI TianoCore isn't using any of those. There's only a simple software check. If you replace AtRunTime with a simple "return false", all the checks will be turned off. Reimplementing UpdateVariable in your kernel without "AtRunTime" checks would allow you to set anything you want without any restrictions. Like it would be before ExitBootServices (secure boot keys included, this is exactly what UEFI trojans actually do).

BTW, if you can figure out the address of mEfiAtRunTime variable (which is in one of the EfiRunTimeData areas), then you can clear it on-the-fly, disabling the checks and then use the standard SetVariable service as you like...

Cheers,
bzt

[zaval]

Even though UEFI is supposed to run in EL1/2 in the aarch64 state, nothing prevents it to use underlying "underfirmware" running in EL3 for "doing some stuff". Some controllers (and SRAM) aren't even visible in EL1/2 system spaces. Then the answer is NO. I don't know for x86, but won't be surprised if it has (a lot) of similar stuff.

[Ethin]

I must clear up a misconception you seem to have here, bzt. Your misconception is that if a kernel hunts down the appropriate bit or byte, they can do anything with UEFI. This is not so. As Korona pointed out, hardware has lock bits and other things that prevent you from actually modifying certain settings. Additionally, you make the false assumption that every UEFI implementation is EDK2. EDK2 is just a reference implementation for UEFI using OVMF; the probability that manufacturers of computers just threw EDK2 on them is highly unlikely. You cannot guarantee that, on this system76 computer using American Megatrends Inc. UEFI firmware, it has that same layout. Furthermore, you can't guarantee that the UEFI implementation doesn't have software underneath it protecting parts of it to ensure that you don't modify it to be able to bypass security features. (Also, secure boot is most likely going to prevent you as well, as is the UEFI runtime services.)

[bzt]

I must clear up a misconception you seem to have here, bzt. Your misconception is that if a kernel hunts down the appropriate bit or byte, they can do anything with UEFI. This is not so.

The TianoCore source says otherwise. It is not a "misconception", rather the result of the analysis of the TianoCore source code. You've been warned not to fall for the propaganda and marketing bs, I wrote: "Obviously Intel and M$ do not want you to know this, but in reality it is that simple."

Additionally, you make the false assumption that every UEFI implementation is EDK2.

Nope, I've never said that. Read my post carefully, I've specifically talked about TianoCore UEFI only.

the probability that manufacturers of computers just threw EDK2 on them is highly unlikely.

Quite the contrary, it is extremely very likely. Manufacturers are only interested in profit, not in a properly written firmware, which means they just add the minimum necessary drivers to TianoCore for their boards and get on with it. No manufacturers will spend money on implementing and testing a completely new firmware from ground up unless they really really have to.

Also, secure boot is most likely going to prevent you as well, as is the UEFI runtime services.

That's not so, empirically proven by many UEFI rootkits. Secure boot can't stop you from modifying the run-time services (either data or code), and I've already shown two ways how to circumvent the run-time service checks, so that is doable as well. (And here's a third one: with a UEFI driver, hijack ExitBootServices to patch SetVariable not to check AtRunTime or use a different variable). I'd advice you to study sources of rootkits (many are available on github and in MSF) and CVE tickets to learn about the many many ways how you can circumvent run-time checks.

If you expect security from UEFI, then you're the one who is mistaken. Not only it was written by non-security experts, never actually verified to be correct, but even the U.S. government forces it to be unsecure and law mandates backdoors to be placed in it. Which is conceptually wrong, because anybody can use those backdoors, not just the CIA.

Cheers,
bzt

[Ethin]

I must clear up a misconception you seem to have here, bzt. Your misconception is that if a kernel hunts down the appropriate bit or byte, they can do anything with UEFI. This is not so.

The TianoCore source says otherwise. It is not a "misconception", rather the result of the analysis of the TianoCore source code. You've been warned not to fall for the propaganda and marketing bs, I wrote: "Obviously Intel and M$ do not want you to know this, but in reality it is that simple."

Sighs* Here we go again, more of your conspiracy theories that you can't prove. If MS and friends didn't want you to know about it, it wouldn't be in the damn code! Obviously!

Additionally, you make the false assumption that every UEFI implementation is EDK2.

Nope, I've never said that. Read my post carefully, I've specifically talked about TianoCore UEFI only.

This is the only time where I can agree with you on this matter, and the only point in your entire post that is correct.

the probability that manufacturers of computers just threw EDK2 on them is highly unlikely.

Quite the contrary, it is extremely very likely. Manufacturers are only interested in profit, not in a properly written firmware, which means they just add the minimum necessary drivers to TianoCore for their boards and get on with it. No manufacturers will spend money on implementing and testing a completely new firmware from ground up unless they really really have to.

You can't actually prove that. That's an assumption. By that logic, all the BIOS implementations are most likely the same, which clearly isn't the case. UEFI may be more complicated, but firmware is firmware.

Also, secure boot is most likely going to prevent you as well, as is the UEFI runtime services.

That's not so, empirically proven by many UEFI rootkits. Secure boot can't stop you from modifying the run-time services (either data or code), and I've already shown two ways how to circumvent the run-time service checks, so that is doable as well. (And here's a third one: with a UEFI driver, hijack ExitBootServices to patch SetVariable not to check AtRunTime or use a different variable). I'd advice you to study sources of rootkits (many are available on github and in MSF) and CVE tickets to learn about the many many ways how you can circumvent run-time checks.

If you expect security from UEFI, then you're the one who is mistaken. Not only it was written by non-security experts, never actually verified to be correct, but even the U.S. government forces it to be unsecure and law mandates backdoors to be placed in it. Which is conceptually wrong, because anybody can use those backdoors, not just the CIA.

Cheers,
bzt

More stuff you can't prove (and more stuff you completely and (probably deliberately) misinterpret). If secure boot wasn't made by security experts and your the security expert who knows all about firmware security, then please write me a UEFI application that I can successfully run when secure boot is enabled. I'll only load my own certificates into the secure boot databases. Your application may or may not be signed, and in either case, it needs to successfully trick the firmware into loading it and running it, even if the embedded digital signature is not within the secure boot database. You are only allowed to use exploits of your own creation; exploits designed to hijack ExitBootServices() or other UEFI boot or runtime services will be counted against you. If you can manage to do this, then you will have proven that secure boot isn't secure. But until then, I, along with anyone else who knows more about this than you do, and who can actually debate rationally, will continue to dismiss your points because all your points regarding the insecurity of secure boot are invalid because they are vulnerabilities that are exploited after the secure boot stage has already concluded and the application/driver has already been loaded and executed. It really makes one wonder if you actually understand what secure boot really is. The more you talk about it, the less it appears you seem to actually understand. I'd strongly encourage you to re-read chapter 32, "Secure Boot and Driver Signing," of the UEFI specification, version 2.9. In particular, I point you to sections 32.2 (UEFI Driver Signing Overview), 32.3 (Firmware/OS Key Exchange: creating trust relationships), 32.4 (Firmware/OS Key Exchange: passing public keys), and 32.5 (UEFI Image Validation).

[bzt]

The TianoCore source says otherwise. It is not a "misconception", rather the result of the analysis of the TianoCore source code. You've been warned not to fall for the propaganda and marketing bs, I wrote: "Obviously Intel and M$ do not want you to know this, but in reality it is that simple."

Sighs* Here we go again, more of your conspiracy theories that you can't prove.

Here we go again, yet another sad little attack attempt against me without thinking first. Personal insult instead of reasoning, is that really the best you can come up with? ROTFL! What were you thinking? That this will make me upset or something? It just make me feel sorry for you.

For your information, I've linked the source. I obviously know the answer, but just for the fun of it, I ask you, because I'm interested in *your* response, what do you think what will happen if you replace that AtRuntime() function with the following?

Code: Select all

/**
  Return TRUE if ExitBootServices () has been called.
  @retval TRUE If ExitBootServices () has been called.
**/
BOOLEAN
AtRuntime (
  VOID
  )
{
  return false;
}

If you think that this is a "conspiracy theory" as you say, then I kindly suggest you to see a theraphist for your own good.

And if you think governments aren't trying to force backdoors into software, then you've probably lived under a rock in the last decade (either that, or the New York Times as well as the The Guardian, Wired and Forbes must be all conspiracy theorists too because they all keep talking about backdoors and agencies...)

Have a nice day,
bzt

[Ethin]

The TianoCore source says otherwise. It is not a "misconception", rather the result of the analysis of the TianoCore source code. You've been warned not to fall for the propaganda and marketing bs, I wrote: "Obviously Intel and M$ do not want you to know this, but in reality it is that simple."

Sighs* Here we go again, more of your conspiracy theories that you can't prove.

Here we go again, yet another sad little attack attempt against me without thinking first. Personal insult instead of reasoning, is that really the best you can come up with? ROTFL! What were you thinking? That this will make me upset or something? It just make me feel sorry for you.

For your information, I've linked the source. I obviously know the answer, but just for the fun of it, I ask you, because I'm interested in *your* response, what do you think what will happen if you replace that AtRuntime() function with the following?

Code: Select all

/**
  Return TRUE if ExitBootServices () has been called.
  @retval TRUE If ExitBootServices () has been called.
**/
BOOLEAN
AtRuntime (
  VOID
  )
{
  return false;
}

If you think that this is a "conspiracy theory" as you say, then I kindly suggest you to see a theraphist for your own good.

And if you think governments aren't trying to force backdoors into software, then you've probably lived under a rock in the last decade (either that, or the New York Times as well as the The Guardian, Wired and Forbes must be all conspiracy theorists too because they all keep talking about backdoors and agencies...)

Have a nice day,
bzt

First, I have made absolutely no personal attacks towards you in this thread. I have stated the truth. In fact, I could go as far as to say that I have never made any personal attacks towards you at all on this forum. I have nearly done so, but I haven't actually crossed that line. A personal attack is an abusive remark on or relating to somebody's person instead of providing evidence when examining another person's claims or comments. I examined your claim that M$ and friends wouldn't want us to know how to backdoor UEFI and that it could be done and ruled it as just another one of your conspiracy theories. That is not an attack on your person, as it doesn't fit the definition of a personal attack; that was a ruling on your claim using evidence and logical reasoning.
Second, I am very aware of governments wanting backdoors in computer software. In fact, those very news sources you linked to are happy to publish such attempts. However, backdoors require two things: an implemented exploit and a trigger. Since TianoCore is open-source, the only areas a backdoor could be present are in binary blobs that come with the image or that are embedded in BIOS images like Coreboot. I know TianoCore's developer process, and it does not lend itself well to slipping in backdoors. It would be noticed. Perhaps not immediately, but it would be noticed and removed eventually.
Third, this reply of yours that I quoted in this post doesn't actually prove anything you said. You nitpicked. You found something you could latch onto and latched onto it and are now trying to use it against me. Unfortunately, it won't work. Try again.

[thepowersgang]

Reminder to both bzt and Ethin;
Please don't attack other forum members (even if it seems like they attacked you first), instead post clarifications and counter-arguments in a civil manner. Remember to read and follow the forum rules and most importantly, be nice to one another.

[bzt]

First, I have made absolutely no personal attacks towards you in this thread.

Yes, you did, called me a conspiracy theorists, several times.

A personal attack is an abusive remark on or relating to somebody's person instead of providing evidence

Which is exactly what you did. No matter how you put it, calling someone a conspiracy theorists is an abusive remark. It is hard not to notice that you haven't answered my question at all, instead you have repeated your insults.

Third, this reply of yours that I quoted in this post doesn't actually prove anything you said.

You just say so, but I kindly ask you, where is your evidence or PoC? What makes you think it doesn't prove anything? As you have noticed, I always back up my statements with links and examples, so should you too.

Please don't attack other forum members (even if it seems like they attacked you first), instead post clarifications and counter-arguments in a civil manner.

Thank you very much for the reminder. I'll keep that in mind. I'd also kindly ask you to take a look at this topic too, where some members are clearly trying to provoke fights. Thank you.

Cheers,
bzt

[Ethin]

First, I have made absolutely no personal attacks towards you in this thread.

Yes, you did, called me a conspiracy theorists, several times.

A personal attack is an abusive remark on or relating to somebody's person instead of providing evidence

Which is exactly what you did. No matter how you put it, calling someone a conspiracy theorists is an abusive remark. It is hard not to notice that you haven't answered my question at all, instead you have repeated your insults.

I did not answer your question because (1) you never answered mine and (2) your question was irrelevant to this discussion. And calling someone a conspiracy theorist is not a personal attack. It is a statement of fact based on previous observations of your behavior. You have yet to answer my question.

Third, this reply of yours that I quoted in this post doesn't actually prove anything you said.

You just say so, but I kindly ask you, where is your evidence or PoC? What makes you think it doesn't prove anything? As you have noticed, I always back up my statements with links and examples, so should you too.
No, you haven't actually provided any examples that would actually work in a secure boot context. All you have done is prove that functions of UEFI can be hijacked. You have yet to prove that those very PoCs would run if secure boot were on and those executable images signatures' were not in the database of trusted signatures, which is what all of us who have taken up this debate with you have asked you to prove. You have said that secure boot is not secure yet you have failed to ever prove it. I do not have to provide POCs because I am not stating that something isn't secure. Therefore, I am not obligated to prove anything with actual code.

Please don't attack other forum members (even if it seems like they attacked you first), instead post clarifications and counter-arguments in a civil manner.

Thank you very much for the reminder. I'll keep that in mind. I'd also kindly ask you to take a look at this topic too, where some members are clearly trying to provoke fights. Thank you.

Cheers,
bzt

I'd like to note that no personal attacks have actually been done in this thread. If bzt chooses to deliberately view what I have said as a personal attack, that is not my problem. I have stated fact. I have yet to see any evidence to prove that I attacked his person (e.g.: I have never in this topic -- or in any other -- called him an idiot, because that would be a personal attack, for example). I have suggested that he may have reading comprehension difficulties, which is something I still believe, but that is purely a statement of fact based on behavioral patterns and observations and is not a personal attack.