Usefulness of UEFI

[kzinti]

@rdos: I think MS surface tablets do that (I know they used to at any rate).

It seems reasonable to me that MS tablets would force you to use Windows. That's no different than what Apple does with its computers. Yet somehow Microsoft is evil and Apple is cool. Go figure.

I suppose all the criticism that MS got for this has made things a bit better.

Like I said: bring it up with the manufacturer. Do criticize them publicly and vote with your $.

What usually happens with cheaper laptops and machines is that Microsoft does a deal with the OEM that is something along the line of "we will provide you with Windows licenses for cheaper if you prevent other OS from running on the machine". OEMs are on-board with that because they are trying to reduce the price of their machines as much as possible. I am not saying it doesn't happen with high-end desktops, but I have not seen it.

[Ethin]

Undoubtedly so. It was foolish of MS to do that to begin with. In that respect I understand how people may consider secure boot as a vendor lock-in tool, but it was never intended to be used that way.

[Gigasoft]

Halt right there. I wrote that in response to "inject code into kernel".

Which they can easily do, if they are an UEFI driver. At some point, your OS is going to call ExitBootServices, which is broadcast to every driver. Whether or not it subsequently calls some other runtime service is completely irrelevant. If for some reason you never call ExitBootServices, there is still ample opportunity to inject themselves into the kernel before it even starts running.

At some point, you must transition from a state where it is okay for arbitrary malware to be running to one where your code is in sole control of the computer. What, exactly, marks that transition, and how is the user supposed to tell?

a machine owner has no control over which keys can be or cannot be used to verify those code

If your OS is running on such a machine, then one of the following things is true:
a) Secure Boot is turned off, or
b) your OS relies on one of the aforementioned flawed bootloaders that allow loading arbitrary code, meaning you bundled the component you are complaining about with your OS.

Thus making the entire complaint pointless. If someone has such a computer, does it mean that "UEFI is flawed by design"? No, it means the user decided to buy a cheap, shitty product.

[bzt]

Yet somehow Microsoft is evil and Apple is cool. Go figure.

Apple never promised that their computers will run 3rd party OSes. On the other hand UEFI spec did promised that in theory any keys could be installed, but then in reality only MS keys are installed and manufacturers refuse to install any other keys (like Linux, BSD or for example Haiku keys). Go figure.

Oh, wait, the BIOS let you do that too!

BIOS never lets nor wants you to load code that later expected to be injected into kernel-space. Actually it's quite problematic to access BIOS services or any BIOS code from a protmode or longmode kernel.

At some point, your OS is going to call ExitBootServices

My OS never calls ExitBootServices (or any other UEFI service). The boot loader does, my kernel couldn't care about less if BIOS or UEFI loaded it. Since I got native drivers, I don't care about UEFI run-time.

If your OS is running on such a machine, then one of the following things is true

What about Setup Mode as described by the UEFI spec?

I don't know what to say, I've warned you that you won't understand. Surely you can choose to take the blue pill, wake up in your bed and believe in whatever you want to believe. You can believe that UEFI is Secure and you can believe that injecting unchecked UEFI run-time code into your kernel and running it with supervisor privilege is safe and perfectly fine. It's up to you if you accept the advice or not. For those who choose the red pill, buy a computer that's supported by the Open Source coreboot firmware. There's nothing more I could add.

Have a nice day,
bzt

[Ethin]

No, bzt, you really haven't warned us of anything. I'll listen to the security experts who actually know what they're talking about, not some person on a forum who has some weird sick and twisted vendetta against UEFI for supposed security risks they can't prove without being demeaning and insulting about it (and without destroying their own argument in the process), and who refuses to acknowledge that maybe, just maybe, they might be wrong.

[kzinti]

Apple never promised that their computers will run 3rd party OSes. On the other hand UEFI spec did promised that in theory any keys could be installed, but then in reality only MS keys are installed and manufacturers refuse to install any other keys (like Linux, BSD or for example Haiku keys)

It's pretty amazing (and not in a good way) how you keep ignoring the substance of what people say, nitpick on details that are irrelevant to the discussion and manage to write a completely non-sensical reply all at the same time. Microsoft, just like Apple (that uses UEFI, by the way), can do whatever it wants. This has nothing to do with what the UEFI specification says or even what its intent is. What you can do as a consumer is boycott manufacturers that force you to use Windows. This is what I posted. I am repeating it just to highlight how illogical your reply is (UEFI allows X, but Microsoft did Y so UEFI is flawed design). Do you have reading comprehension problems? Or are you just too insecure not to have the last word on every discussion point?

Go figure.

I said that to no one in particular, pointing out the irony in how Apple is not treated the same way as Microsoft is for doing the exact same thing. Yet you decided to repeat it as a demeaning and insulting reply that doesn't help you in any way. I wonder why you keep digging your own grave.

There's nothing more I could add.

I think we have all concluded this a while ago, yet you keep going and derail every thread where you don't have the last word or where you disagree with what other people say.

Have a nice day,

What? No cheers this time?

[Gigasoft]

My OS never calls ExitBootServices (or any other UEFI service). The boot loader does

Presumably, after it has loaded the kernel into memory. What prevents the malware from injecting itself into your kernel at this point?

What about Setup Mode as described by the UEFI spec?

Great, so you were able to control the key database after all, despite protesting that it was impossible a few moments ago. Then why did you not remove the Microsoft, Linux and FBI keys?

[bzt]

No, bzt, you really haven't warned us of anything.

Yes, I did.

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've tried to explain, and you didn't understand as excepted. This isn't your fault, people are miseducated in security in general, and therefore software are full of security holes.

supposed security risks they can't prove

Not paying attention to Microsoft's own warning and to the CVE tickets is a huge mistake, but you're free to make mistakes. With CVE tickets, you can be sure they are proven, and there's always a PoC that you can try out to see if your system is vulnerable to that particular exploit.

What prevents the malware from injecting itself into your kernel at this point?

That it doesn't know where the kernel is loaded (where to modify), what format it's using (what to modify, I'm not using PE for example) and what VMA it will be actually running from (how to access data in the modified code). It's not impossible to figure these out, but by several magnitudes harder to do than executing something that the kernel proactively maps and relocates into its address-space.
Take a look at this example. It copies out segments, and then frees ELF structures. Imagine it calls ExitBootServices before it calls the ELF entry point. Since there are absolutely no magic bytes left in the memory, it's pretty hard to tell from ExitBootServices where the kernel code actually is in memory.

Cheers,
bzt

[kzinti]

Take a look at this example. It copies out segments, and then frees ELF structures.

This code seems to have a bug: you are copying the ELF segments in memory (to phdr->p_vaddr) without first allocating that memory. It appears you haven't exited boot services before doing that, and so your program doesn't own the memory (it might also not even exist).

This sample certainly has this bug: the code is exiting boot services after you've copied the ELF to a memory location you don't own (and that might not even exist).

[bzt]

This code seems to have a bug: you are copying the ELF segments in memory (to phdr->p_vaddr) without first allocating that memory and/or making sure it is available and not in use.

That's not a bug, it's deliberate. From the Makefile

Code: Select all

# UEFI wastes lots and lots of memory. Link our "kernel" at an address (32M) which isn't used by UEFI

It's not allocated because there's absolutely no guarantee that UEFI allocation would return the address where the executable is linked at (should I say yet another design failure...? Why AllocPool not reading the pointer passed to it?) And I didn't wanted to overcomplicate this simple tutorial by mapping the load address to the link address, so it was easier to use an address that's surely above the wasted UEFI memory.

and that might not even exist

You can't boot up UEFI with less than 64M of RAM, so it exists. Yet another reason why to choose Open Source firmware over UEFI. coreboot only needs 256K of ROM, and runs with 2M of RAM.

Cheers,
bzt

[Ethin]

And can you prove that that memory address isn't used by *any* UEFI implementation? Its much better to just let UEFI allocate an address, rather than to just say "Oh, UEFI wastes lots of memory so I'm just going to pick this static address and pray that its not already used". I'm not even going to bother replying to your other post -- you clearly are unwilling or unable to acknowledge that you might be wrong (which is just sad, really it is).

[bzt]

And can you prove that that memory address isn't used by *any* UEFI implementation? Its much better to just let UEFI allocate an address

And can you prove that UEFI will allocate the memory area where the ELF is linked at? Nope, of course you can't. UEFI or not, you must use that address because that's where the segment is linked at.

you clearly are unwilling or unable to acknowledge that you might be wrong

This is a personal insult. You also insulted ALL Microsoft engineers working on the security update and ALL the security engineers working on those CVEs.

Cheers,
bzt

[kzinti]

This code seems to have a bug: you are copying the ELF segments in memory (to phdr->p_vaddr) without first allocating that memory and/or making sure it is available and not in use.

That's not a bug, it's deliberate. From the Makefile

Code: Select all

# UEFI wastes lots and lots of memory. Link our "kernel" at an address (32M) which isn't used by UEFI

That makes it a design flaw of your code, not UEFI. Using memory you don't own is illegal.

You are willfully providing buggy code as samples and claiming you are right to do so because it's UEFI that is wrong.

I'll just leave it at that for people to decide what they want to think about it.

[bzt]

That makes it a design flaw of your code, not UEFI. Using memory you don't own is illegal.

Yeah, forcing people to boot Windows only is illegal too according to my country's law. It is something called "kényszerített árukapcsolás", or "forced tying" and its considered an illegal practice. Microsoft actually lost a trial on court because of this and were made to pay a fine.

You are willfully providing buggy code as samples to help people and claiming you are right to do so because it's UEFI that is wrong.

Since AllocPool does not care about the pointer it was given, there's not really much of a choice, is it? And yes, you can only blame UEFI for that. Why doesn't AllocPool use the pointer it was given?

Cheers,
bzt

[Ethin]

And can you prove that that memory address isn't used by *any* UEFI implementation? Its much better to just let UEFI allocate an address

And can you prove that UEFI will allocate the memory area where the ELF is linked at? Nope, of course you can't. UEFI or not, you must use that address because that's where the segment is linked at.

This in no way invalidates my point. UEFI uses PIC, so it is allowed to relocate code irrespective of what your ELF header contains for memory addresses. I think you'd know this.

you clearly are unwilling or unable to acknowledge that you might be wrong

This is a personal insult. You also insulted ALL Microsoft engineers working on the security update and ALL the security engineers working on those CVEs.

Cheers,
bzt

How is it a personal insult if its true? You have aptly demonstrated on this topic alone that you are unable or unwilling to acknowledge that you are wrong. Furthermore, I am not insulting the engineers who made those CVEs and security bulletins, because they aren't on this forum acting all superior and being demeaning to other forum users and throwing out vulnerabilities in loaded signed binaries as "evidence" that implementations of secure boot are vulnerable. The only one who's doing that on this topic is you. You lost this argument a long, long time ago, if you ever had any point to begin with. I'm not the only one pointing out illogical conclusions that you have drawn, but every time one of these is pointed out to you you dismiss it and just keep on trying to push your tripe. Kindly stop doing so and actually put forth valid points or concede the debate, because right now yoru not looking too good, and your emphasizing the fact that you just can't give up an argument until people admit that your right and until you have the last word and can say "I told you so!".