Researchers reveal "Sinkclose" vulnerability affecting nearly all AMD processors since 2006

Not every post, no. Only when a poster fails to read the article and prior posts, to reiterate already debunked statements.
Like when he opens his reply to another comment claiming that the article contains patently false information by saying that the article "is correct", only to go on and confirm that the article was indeed "flawed" and "misleading" at several points?
 
Appeal to authority noted. You're still wrong. Your link correctly notes that SMM and other negative rings aren't "true" rings. However, that in no way implies "if you're in Ring 0, you can basically do what you want." If this were true, the exploit in the article wouldn't exist -- as any "40 year experienced developer" could simply write a small program to alter UEFI firmware regardless.


Again: you cannot "basically" enable SMM mode. Even from Ring 0, SMM can **only** be entered through a SMI hardware interrupt from the chipset. Furthermore, even if you're running at Ring 0 at the time, and have installed your own SMI driver:

"Immediately after SMI is triggered, the entry routine demotes the system to execute under CPL3 (least privileged level) before executing any third party SMI handlers. From [this privilege level] , MSR, IO, and supervisor pages access, critical register changes such as CR3, as well as privileged instructions such as “hlt” and “cli” all end up as General Protection Fault enforced by CPU hardware...."


Now, if you wish to continue arguing a clearly false position, I invite you to simply post the code showing us all -- including Microsoft, AMD, and Intel, how you can simply enter SMM mode from kernel mode, and write to the UEFI firmware at will.


Not every post, no. Only when a poster fails to read the article and prior posts, to reiterate already debunked statements.
Man alive you're hard work - nobody else on this site sets my teeth on edge like you do! I started to type a long reply but life is too short to deal with people like you.

I'll repeat what I said - the negative rings (of which SMM is one) are not real, they are made up numbers with no real relation to the actual chips execution modes which start at zero - the article said they needed kernel access to install their driver to which I replied (correctly) "If you have Ring 0 you can basically do anything so I really don't call this a vulnerability at all."
All this flannel about SMM you've quickly Googled is impressing nobody. I'm sure you will spend another 3 hours Googling more stuff and trying more reductive arguments if I say anymore so I'm done.
 
the negative rings (of which SMM is one) are not real, they are made up numbers with no real relation to the actual chips execution modes...
No one is arguing otherwise. But as already established, those negative rings may be "virtual", but they still prevent certain operations. If Ring-1 was fully equivalent to Ring 0, virtualization couldn't operate. If Ring-2 was equivalent to Ring 0, System Management Mode wouldn't exist, nor UEFI Bios protection, and this vulnerability wouldn't need to be patched. So why keep arguing an obviously false point?

This article explains your error in very clear terms:

"...On Intel Architecture chipsets, there are three more levels of privilege [below zero], all with a higher-level privilege than the operating system’s kernel. We call those “Ring ‑1” through “Ring ‑3,” being the least privileged of the negative rings, and Ring ‑3 being the most privileged....

Now, allow me to emphasize a point: Negative rings are conceptual levels of privilege, not actual processor protection rings.

...We will briefly discuss how the processor knows it is running a process in a negative ring when we cover that ring.

Each of the negatively numbered rings is reserved for a specific use. That assignment is as follows:"


 
Back