OSDev.org

Octocontrabass wrote:Why do you assume you must keep the UEFI runtime code and data mapped all the time? You can remove the mappings when you're not using them, and put them back when you want to call a UEFI runtime service.

Then let me ask you again, what's the point of SetVirtualAddressMap? If you must restore UEFI specific mappings for UEFI run-time temporarily anyway, then you could just as easily restore identity mapping, no? No matter from what angle we look at it, this "remapping run-time" doesn't make much sense from technical point of view at all!

Let's just admit, UEFI has a particularly badly designed and unuseful interface.

Like in this joke:

During their flight the helicopter encounters some dense fog and quickly becomes lost. After a few minutes of careful maneuvering, the two find themselves hovering next to a large building where they can see a guy in his office, sitting at his desk.

Thinking quickly, the copilot grabs a piece of paper, writes "WHERE ARE WE?" in huge letters on it, and holds it up for the officeworker to read. The officeworker grabs a sheet of paper off his desk, scribbles quickly, and holds up his response: "YOU ARE IN A HELICOPTER."

"Okay, no problem," says the pilot. "I know where we are. We're at Microsoft's headquater."

"How do you know that?" asks the copilot.

"Because," says the pilot, "the answer he gave us was technically correct but completely useless, just like a Windows message."

Cheers,
bzt

The intended usage is that you map the runtime services where you want them in kernel space. Once this is done, you don't need to remap them or do anything with the mapping, it just stays there in the kernel memory space. These services are then available to your kernel at any time. This design seems to make sense to me. It gives some flexibility to the OS by not forcing where the runtime services are to be run (unlike the BIOS which can't be relocated at all, and is not even usable from protected/long mode anyways - and no, emulation / VM86 is not "less complex" than UEFI).

Presumably your OS provides system calls that programs can use to manipulate the UEFI variables, reboot the system, update the system time, etc.

Granted there isn't a lot of runtime services available, but you get them for very little work. You are of course free to ignore them entirely.

bzt wrote:Then let me ask you again, what's the point of SetVirtualAddressMap? If you must restore UEFI specific mappings for UEFI run-time temporarily anyway, then you could just as easily restore identity mapping, no?

What do you do if UEFI wants to use an address that your kernel has already reserved for something else?

kzinti wrote:The intended usage is that you map the runtime services where you want them in kernel space.

As I've said, no sane kernel developer would ever do that, as it is an unbelievably huge security risk. And if that is really the intended usage, then as I've said, "they unarguably using UEFi as an excuse to create a backdoor in OSes." I'm no dog to any agency, and I don't want to support criminal groups either (because agencies are NEVER ABLE to protect their backdoors). Just the latest issue, but there are countless others: https://thehackernews.com/2021/02/chine ... to-us.html Chinese has stolen NSA hacking tools and were using those for YEARS. Did it worth forcing backdoors into software? U.S. digging its own grave! And in the meantime I'm happy with my backdoor-free operating system

Octocontrabass wrote:What do you do if UEFI wants to use an address that your kernel has already reserved for something else?

And how would that be possible? Under UEFI a kernel is NOT allowed to reserve any region of memory. After ExitBootServices, UEFI memmap can't change, UEFI run-time can only use regions already marked as EfiRuntimeServicesData and the kernel only allowed to use memory regions that are marked as EfiConventionalMemory. I literally can't see any way how distinct, non-overlapping regions could interfere with each other.

Cheers,
bzt

bzt wrote:

Octocontrabass wrote:What do you do if UEFI wants to use an address that your kernel has already reserved for something else?

And how would that be possible?

Let's say you load your 32-bit higher-half kernel at virtual address 0xFF000000. Now you want to use UEFI runtime services, but UEFI runtime services need access to physical address 0xFF000000. You can't identity-map the UEFI runtime services because your kernel is already using that virtual address.

In this situation, you would use SetVirtualAddressMap() to tell UEFI runtime services to use a different virtual address to access physical address 0xFF000000.

bzt wrote:As I've said, no sane kernel developer would ever do that, as it is an unbelievably huge security risk. And if that is really the intended usage, then as I've said, "they unarguably using UEFi as an excuse to create a backdoor in OSes."

Well the same would be true with any other firmware, UEFI or not. Your computer could be comprised in many other ways (ACPI, SMM, ...). So I don't know that UEFI is more or less secure in that regard. You are basically saying that you don't trust the platform your OS is running on... What makes you feel more secure by not calling the UEFI runtime services? Are you not concerned with the fact that your OS was loaded by UEFI in the first place?

If UEFI is compromised, it doesn't matter if you call back into the runtime services are not. It could have installed a rootkit or done something else before your OS was even loaded.

bzt wrote:And how would that be possible? Under UEFI a kernel is NOT allowed to reserve any region of memory. After ExitBootServices, UEFI memmap can't change, UEFI run-time can only use regions already marked as EfiRuntimeServicesData and the kernel only allowed to use memory regions that are marked as EfiConventionalMemory. I literally can't see any way how distinct, non-overlapping regions could interfere with each other.

Imagine that the UEFI services code and data are located at 0xD0000000 (physical). But you OS decided that the kernel memory space is anything above 0xC0000000 (virtual). You have a conflict: you can't map the UEFI runtime services to 0xD0000000 virtual because your kernel is already there. If you try to map the runtime services somewhere else, the code won't work because it has jmps/calls instructions to the original locations around 0xD0000000. I am sure you understand this, but I don't understand why you write something that suggests you don't.

Using SetVirtualAddressMap(), you can remap the runtime services to work from any virtual address of your choosing. You could decide to remap the UEFI runtime services to a specific location in kernel space or you could decide to map it below 0xC0000000 and run it from a dedicated memory space. There are a few possibilities here. But the basic idea is that you are not forced to run the runtime services from the initial address picked up by UEFI.

kzinti wrote:Well the same would be true with any other firmware, UEFI or not.

Nope, because most firmware using code located in ROM, and they don't expect arbitrary code to be injected into kernel-space. That's what we call "failure by design".

kzinti wrote:Your computer could be comprised in many other ways (ACPI, SMP, ...).

Only if you don't know what you're doing. It's easy to interpret ACPI bytecode securely from user space without the slightest risk, that's what OpenBSD does. And I'm not sure what you mean by SMP in this context.

kzinti wrote:So I don't know that UEFI is more or less secure in that regard.

Less, by far. That's because it allows loading UEFI run-time code from disk as I've mentioned, not just from Option ROM. The whole Secure Boot thing worth absolutely nothing, because it's not just a loader that's loaded from disk, but any arbitrary code (independent to the secure signed boot loader). And even worse, because while the boot loader is usually cleared from the memory during kernel boot, that arbitrary unchecked code supposed to be run with full supervisor privileges in kernel-space...

kzinti wrote:What makes you feel more secure by not calling the UEFI runtime services?

Well, not letting arbitrary code injected into my kernel and then run with supervisor privileges IS much more secure.

kzinti wrote:Are you not concerned with the fact that your OS was loaded by UEFI in the first place?

I would be a terrible security engineer if I weren't. And I try to avoid UEFI whenever I can, but not all machines support coreboot, so UEFI is a threat that we must dealt with.

kzinti wrote:If UEFI is compromised

That's the thing, a malware doesn't have to compromise the UEFI firmware at all. UEFI is exploitable by design...

kzinti wrote:It could have installed a rootkit or done something else before your OS was even loaded.

True, but my kernel can make it impossible for the rootkit to work once the kernel gains control. I do everything I can to stop UEFI malware from infecting my OS (there's no guarantee I can block all the attack vectors, but sure as hell I can make a malware's job pretty damn hard). I don't even care if my OS crashes when the UEFI is infected, that's much much better than letting the malware to run.

kzinti wrote:Imagine that the UEFI services code and data are located at 0xD0000000 (physical). But you OS decided that the kernel memory space is anything above 0xC0000000 (virtual). You have a conflict

No, you don't, because we have already concluded that you must temporarily change the mappings for making an UEFI run-time call.

kzinti wrote:Using SetVirtualAddressMap(), you can remap the runtime services to work from any virtual address of your choosing.

The problem is, a typical kernel will use many many virtual address spaces (one for each task), while you can only call SetVirtualAddressMap() once. And still I see no benefit in having UEFI run-time, there's absolutely nothing I want to use that for (it would be a different issue if GOP and BlockIO were run-time services, but they aren't. All the meaningful services are boot-time services).

Cheers,
bzt

bzt wrote:The problem is, a typical kernel will use many many virtual address spaces (one for each task), while you can only call SetVirtualAddressMap() once.

How is that a problem? You're not telling the firmware to use a specific set of page tables. The only thing SetVirtualAddressMap() tells the firmware is "runtime code/data at physical address X will be accessible at virtual address Y". When you call runtime services, you map the runtime code/data at physical address X to virtual address Y. When the call returns, you map whatever you want to virtual address Y. You can do whatever you want with other virtual addresses at any time.

You can even switch tasks in the middle of a call to UEFI runtime services. (I don't know why you would want to, but it's possible.)

bzt wrote:As I've said, no sane kernel developer would ever do that, as it is an unbelievably huge security risk. And if that is really the intended usage, then as I've said, "they unarguably using UEFi as an excuse to create a backdoor in OSes." I'm no dog to any agency, and I don't want to support criminal groups either (because agencies are NEVER ABLE to protect their backdoors). Just the latest issue, but there are countless others: https://thehackernews.com/2021/02/chine ... to-us.html Chinese has stolen NSA hacking tools and were using those for YEARS. Did it worth forcing backdoors into software? U.S. digging its own grave! And in the meantime I'm happy with my backdoor-free operating system

I don't think it is UEFI you should be worried about in a typical PC, rather SMM and integrated PCIe hardware. These can pose huge security threats if a motherboard manufacturer have malicious intentions, which you actually don't know beforehand.

As an example, I had a PC where the motherboard ACPI didn't want a too old Windows version to run, and so it rebooted it automatically from the background. Actually, you will have no idea if there is code that takes over hardware or reboots in the background since you have no control of SMM.

PCIe is even worse. A malicious PCIe board could hijack a core, and spy on your OS without you having an idea it's going on. Of course, if it had malicious code, it could inject it by taking over the initialization vector & rebooting a core. A PCIe board can also read & write to any address in main memory, and in peripherials.

So, if you want a safe system, you cannot use standard PC hardware.

bzt wrote:And I'm not sure what you mean by SMP in this context.

I meant SMM, and that's a much bigger risk than UEFI. Someone else replied the same thing.

bzt wrote:Only if you don't know what you're doing. It's easy to interpret ACPI bytecode securely from user space without the slightest risk, that's what OpenBSD does. And I'm not sure what you mean by SMP in this context.

I am not talking about the quality / security of your ACPI bytecode interepreter. I am talking about the bytecode itself. How do you know it wasn't tampered with before you start using it? ACPI bytecode can read/write to any address and I/O port. When you run ACPI bytecode, you are effectively running unknown code. Running this in kernel space seems even more dangerous than UEFI to me.

bzt wrote:Well, not letting arbitrary code injected into my kernel and then run with supervisor privileges IS much more secure.

ACPI already does it if you run the read the tables and your interpreter in supervisor mode, SMM already does it, any rookit can do it. My entire point was that there are other ways than UEFI to inject code into your kernel. Many other ways in fact.

bzt wrote:but my kernel can make it impossible for the rootkit to work once the kernel gains control. I do everything I can to stop UEFI malware from infecting my OS (there's no guarantee I can block all the attack vectors, but sure as hell I can make a malware's job pretty damn hard). I don't even care if my OS crashes when the UEFI is infected, that's much much better than letting the malware to run.

This is interested... What kind of techniques do you use to block rootkits? What do you do about other attack vectors?

bzt wrote:No, you don't, because we have already concluded that you must temporarily change the mappings for making an UEFI run-time call.

You can and only need to call SetVirtualAddressMap() once. I certainly have not concluded what you say, because that would 1) not match what the docs say, 2) not work in practice (I tried) and 3) not be that useful. I can tell that you've never actually tried to use it because otherwise you would understand how it works.

bzt wrote:The problem is, a typical kernel will use many many virtual address spaces (one for each task), while you can only call SetVirtualAddressMap() once. And still I see no benefit in having UEFI run-time, there's absolutely nothing I want to use that for (it would be a different issue if GOP and BlockIO were run-time services, but they aren't. All the meaningful services are boot-time services).

I'll grant you that what is available as runtime services is not much and not very useful. But I think you still don't understand how SetVirtualAddressMap() works. Other people replied before me, so I won't repeat what they said.

rdos wrote:So, if you want a safe system, you cannot use standard PC hardware.

This would be the short version of what I was trying to say

Worrying about being attacked by UEFI runtime services and not everything else would be pointless.

kzinti wrote:Worrying about being attacked by UEFI runtime services and not everything else would be pointless.

It makes perfect sense to me. PCs are not the right type of machines if you don't trust the firmware.
See: https://en.wikipedia.org/wiki/Intel_Management_Engine. I mean, a whole MINIX 3 kernel runs on a SoC
and we have no control over it!

No offense guys, but you have some very serious misconception about security. I'll try to explain, but it's on you if you don't understand.
I'm only hoping that you're just ignorant and misguided in security matters and not trying to deliberately mislead people so that gov's backdoors could work on hobby OSes too. That would be a very bad thing, right?
(I understand that there's a pressure from CIA, FBI and NSA to put backdoors into software, but the fact is, those backdoors could be used by Russian and Chinese rootkits too! As it happend many many times already.)

rdos wrote:I don't think it is UEFI you should be worried about in a typical PC, rather SMM and integrated PCIe hardware. These can pose huge security threats if a motherboard manufacturer have malicious intentions, which you actually don't know beforehand.

You're mistaken, and you have even said it yourself why. To exploit SMM and PCIe, you'll need a malicious manufacturer. That's one well checked actor in the chain, who would have to infect ALL boards, kinda risky with extremely high chance of being caught, not to mention the scandal afterwards which they definitely want to avoid. On the other hand, UEFI can be exploited by anyone and anytime, you don't have to be the manufacturer of the board for that, you just need write access to the ESP.

kzinti wrote:I meant SMM, and that's a much bigger risk than UEFI.

No, because it's a lot harder to change the SMM code than to place some .efi files on a FAT formatted ESP to inject UEFI run-time code.

kzinti wrote:I am not talking about the quality / security of your ACPI bytecode interepreter. I am talking about the bytecode itself. How do you know it wasn't tampered with before you start using it?

But you should. The bytecode can't do anything that the interpreter doesn't allow, for example the interpreter can do bound checks and memory access verification. Therefore it doesn't matter if someone has tempered with the bytecode if it's interpreted in a sandbox environment.

kzinti wrote:ACPI bytecode can read/write to any address and I/O port.

Wrong. the bytecode can only access what the interpreter allows. And since you're writing the interpreter, you can do as many checks as you want.

kzinti wrote:Running this in kernel space seems even more dangerous than UEFI to me.

That's because you are not a security expert. If you were, then you would know that interpreting a bytecode (specially in user space, I must put emphasis on that part because you seem to keep forgetting that) with a sandboxing interpreter is far less dangerous than running unchecked native code in kernel-space with full supervisor privileges. If you don't understand this, then no offense, but go study the topic a bit more.

kzinti wrote:Worrying about being attacked by UEFI runtime services and not everything else would be pointless.

Who said I don't care about the others? Not worrying about UEFI which is by far the most exploitable part of the firmware is just stupid. Just because there are other attack vectors doesn't mean we should forget about the biggest threat.

Cheers,
bzt

bzt wrote:Less, by far. That's because it allows loading UEFI run-time code from disk as I've mentioned, not just from Option ROM. The whole Secure Boot thing worth absolutely nothing, because it's not just a loader that's loaded from disk, but any arbitrary code (independent to the secure signed boot loader). And even worse, because while the boot loader is usually cleared from the memory during kernel boot, that arbitrary unchecked code supposed to be run with full supervisor privileges in kernel-space...

bzt wrote:No, because it's a lot harder to change the SMM code than to place some .efi files on a FAT formatted ESP to inject UEFI run-time code.

Couldn't the (signed) bootloader check that everything it loads is signed?
firmware -> signed bootloader -> signed bootloader modules/drivers -> signed kernel -> signed kernel modules.

bzt wrote:You're mistaken, and you have even said it yourself why. To exploit SMM and PCIe, you'll need a malicious manufacturer. That's one well checked actor in the chain, who would have to infect ALL boards, kinda risky with extremely high chance of being caught, not to mention the scandal afterwards which they definitely want to avoid. On the other hand, UEFI can be exploited by anyone and anytime, you don't have to be the manufacturer of the board for that, you just need write access to the ESP.

You forget that many motherboards are manufactured in China, and so might contain backdoors that the Chinese government might wan't to exploit. That's why Huawei and other Chinese 5G companies have been banned in some countries when it comes to building 5G infrastructure.

bzt wrote: No, because it's a lot harder to change the SMM code than to place some .efi files on a FAT formatted ESP to inject UEFI run-time code.

There is already a lot of tampering in that area by Windows installations. Even if you erase or replace the Windows boot .efi file, the firmware might still want to boot Windows, some way or another, for instance by restoring it from some backup or booting from somewhere else.