OSDev.org

Your latest post is a clear sign that you're not here to do civilized discussions, you're just hopefully trying to provoke. Don't even bother, won't work on me. This is my last post to you.
You have already been warned by a moderator, so please behave. If you can't answer politely in a civilized manner, then please don't answer.

And just for the records, I've already answered that question to you, citing multiple CVE tickets all with working PoCs. So as you can see, unlike you, I did answer your question, despite what you say.

Have a nice day,
bzt

bzt wrote:Your latest post is a clear sign that you're not here to do civilized discussions, you're just hopefully trying to provoke. Don't even bother, won't work on me. This is my last post to you.
You have already been warned by a moderator, so please behave. If you can't answer politely in a civilized manner, then please don't answer.

You have been warned too, good sir. I have not committed any rule violations in this thread. I have maintained civility throughout this entire discussion. The only reason I was warned was because you reported me -- or someone did. If I've committed a rule violation, I'd like proof, because I don't see how calling someone a conspiracy theorist is violating civil discourse.

bzt wrote:And just for the records, I've already answered that question to you, citing multiple CVE tickets all with working PoCs. So as you can see, unlike you, I did answer your question, despite what you say.

Have a nice day,
bzt

For the records, those PoCs you provided did not, in fact, answer my question at all. You continue to sidestep the problem. I have asked you, innumerable times, to provide me a PoC that bypasses secure boot and tricks UEFI firmware into loading an image even if its signature is not within the list of KeKs or its signature is explicitly within the DBX database. You have not provided me a single shred of evidence to prove that is possible; all you have provided me is proof that it is possible to hijack firmware subroutines *after* an application has been verified, loaded and executed, which does not prove that secure boot is vulnerable. As I have said previously, try again. Unless, of course, you can't find any and can't come up with any PoCs on your own. And if you can't, you might as well indicate so.

Get a room, you two. You're both going on my ignore (foes) list.

iansjack wrote:Get a room, you two. You're both going on my ignore (foes) list.

Do you honestly believe that this post of yours is adequate, civilized and free of attempted personal insults?

Cheers,
bzt

bzt wrote:Do you honestly believe that this post of yours is adequate, civilized and free of attempted personal insults?

I believe this "debate" was already past that point, before iansjack threw his hat in the ring.

Getting back to the topic, while it is possible that a firmware implementation would use System Management mode or Intel Management Engine (or whatever the AMD equivalent of that thing is called) to lock away BIOS settings such that the OS cannot change them, TianoCore does not do that, and many old-school BIOS implementations did not do that, either. In fact, parts of the CMOS RAM were standardized in the Intel MP specification, because they were needed before Startup IPIs were a thing to make a starting CPU jump to a given address. And I have seen listings of what several bytes of the CMOS RAM mean on the internet. But obviously nothing important was ever standardized.

bzt has made his way onto my foes list. I'm tired of his useless vendetta against things he deliberately chooses not to understand.
@nullplan: Definitely true. But I think this topic answered that question a long time ago.

nullplan wrote:I believe this "debate" was already past that point, before iansjack threw his hat in the ring.

I agree. This is @ethin's fault, started with this post and @ethin totally lost it in his very next post here, however this does not make okay for @iansjack to try to make things worse. This just lowers @iansjack to @ethin's level, which is sad thing to see.

nullplan wrote:TianoCore does not do that

Watch out, @ethin freaked out after I said exactly that, now you'll be the next target.
Otherwise yes, this is the truth. With the modification, you could go one step further, you could use EFI_VARIABLE_WRITE_ARCH_PROTOCOL directly (same that SetVariable uses at the end of the day), circumventing the "protection" implemented in SetVariable. I'm pretty sure there's no "who-is-the-caller" check in that protocol's implementation if such a check even possible with the UEFI ABI.

Cheers,
bzt

On my foe list as well. I had enough of his immaturity, as demonstrated over and over in this thread and others.

I've locked this thread as it has degenerated into off-topic bickering.

I believe the OP's question has been answered (... well, a full gamut of answers have been provided) so hopefully this locking isn't preventing their question being addressed.

A reminder to ALL forum members: Please try to keep conversations civil, I (and the rest of the mods) don't want to have to be banning anyone but spambots.