OSDev.org

Hi all ! This is my first appearance, and I hope my below question befits the forum.

There is an undocumented way that certain popular X86-32 processors are able to access (read/write) *physical* addresses in main memory directly, bypassing protections, paging and segmentation altogether. Whatever the purpose (factory testing?) that feature, which of course violates the IA-32 architectural model, works only for code running at CPL zero.

I'm not going to disclose details; what I'm asking from your precious lots of experience is does the existence of such a feature - which can't be turned off - constitute a new security menace for a securely conceived OS ? Or do you consider it "no problem" as the feature is available from ring zero only ? ... How much would it change the theater scene ?


--
Czernobyl

Happy turn of the year

If this "feature" works only in PL0, in which sense does it bypass protections? Protections such as segment limit checking or page level protections can be bypassed by software running PL0, simply by changing segment limits in the GDT or page permissions in the page tables. So I don't see any security problems from such a "feature".

XenOS wrote:If this "feature" works only in PL0, in which sense does it bypass protections? Protections such as segment limit checking or page level protections can be bypassed by software running PL0, simply by changing segment limits in the GDT or page permissions in the page tables. So I don't see any security problems from such a "feature".

May I point it out, "simply" running in PL0 doesn't give your random piece of code access to *physical* memory nor the mappings thereof. Sure it can access CR3, but what then ? CR3 holds a physical address again, which needn't even be mapped in to virtual mem of the questionable software. A secure OS, in this view, won't handle information about the mappings outside of the inner kernel memory mapper.

Sure, running at priv level zero in itself holds the potential to take much destructive actions, alter the contents of (virtual) memory, format disk drives, shutdown or reboot a machine...
However I wonder and am asking whether having unconditional access to physical memory doesn't represent a higher threat level than it would without it.

If I'm running in ring 0, I have access to the hardware anyway. There is no possible defense against arbitrary ring 0 code doing whatever it wants. Not a security issue.

It rather involved being on the other side of this airtight hatchway...

Owen wrote:If I'm running in ring 0, I have access to the hardware anyway. There is no possible defense against arbitrary ring 0 code doing whatever it wants.

Well... no argument here, and hope any OS you are developping wouldn't allow drivers needlessly to be installed to run in ring zero, even by an "admin" or "root" type...

Not a security issue....

While respecting your opinion - otherwise I wouldn't be asking in the first place - ISTM
the abilty to recreate the memory mappings (and modify them at will, behind the kernel's back) - which free access to physical adresses may buy you, it makes subtler, non immediately destructive hence more dangerous attacks possible or easier than would be otherwise against a well designed OS, one that has no "backdoors" intentional or not in the first place ;=)

ICBW of course, but on that basis I chose not to divulge any practical details of the feature I found.

You've already made people wonder, and the first thing that came to my mind was the wasted entry at the start of every GDT, so if it has anything to do with that...

But whatever it is, it isn't going to let a malicious program do anything it couldn't do anyway. If it's running at level 0 it's already won.

What about faster IPC?

Hi,

Czernobyl wrote:There is an undocumented way that certain popular X86-32 processors are able to access (read/write) *physical* addresses in main memory directly, bypassing protections, paging and segmentation altogether.

One way??

Let's see...

• For almost all modern 32-bit OSs (which use a "flat" memory model) you can clear bit 0 in CR0 and end up in something like unreal mode.
• For 80486 class CPUs you can use the cache test registers to create new/fake dirty cache lines and cause them to be evicted from the cache (written back to RAM).
• For most later CPUs there's cache test MSRs that could be used to create new/fake dirty cache lines and cause them to be evicted from the cache (written back to RAM).
• Almost every PCI device that supports bus-mastering/DMA can be used to indirectly modify physical memory
• Almost every legacy/ISA device that supports DMA can be used to indirectly modify physical memory
• For some 80386s and all later CPUs it may be possible (depends on chipset and whether or not the firmware "locked" it) to misuse SMM
• There's probably more ways for specific CPUs if you care to exaime the MSRs and/or errata
• There's probably ways of messing with different memory controllers to replace something you could access easily with something you could access less easily
• For most modern CPUs there's VMX/SMV virtualisation that could be used (but is too painful to bother with for this purpose).

Of course all of these options only work in some cases (they depend on which CPU or which motherboard or which devices are present). The best and easiest way that always works is messing with the page tables, etc.

Czernobyl wrote:I'm not going to disclose details; what I'm asking from your precious lots of experience is does the existence of such a feature - which can't be turned off - constitute a new security menace for a securely conceived OS ? Or do you consider it "no problem" as the feature is available from ring zero only ?

CPL=0 was always meant to have complete access to everything with no protection/security at all. Regardless of how many different ways there are to bypass the imaginary protection that doesn't exist at CPL=0, it doesn't make any difference because that protection never existed anyway.

It's like saying "OMG I found a way to get access to the glove box" in a car that happens to have all doors unlocked and open (including bonnet and boot) and the alarm system turned off, with a large sign on its roof that says "Free stuff in glove box, please help yourself". Of course if this car happens to be inside a fortified underground bunker then the real achievement would be saying "OMG I found a way to get inside the fortified underground bunker (where anyone can easily access the stuff in the car's glove box)". In the same way, for a secure OS the real achievement would be finding a way to get to CPL=0 in the first place (where you can easily do whatever you like).


Cheers,

Brendan

DavidCooper wrote:You've already made people wonder, and the first thing that came to my mind was the wasted entry at the start of every GDT, so if it has anything to do with that...

But whatever it is, it isn't going to let a malicious program do anything it couldn't do anyway. If it's running at level 0 it's already won.

It's nothing to do with GDT, nor SMM (that some ppl have hypothesized).

Anyhow... my mind is made now, I won't disclose any details, keeping them for my private programming pleasure.

Thanks to everybody and happy celebrations !


--
Czerno

Perhaps the OP has discovered the loadall instruction.

gerryg400 wrote:Perhaps the OP has discovered the loadall instruction.

That has to be one of the stupidest things I've read, ever. LOL

N.B : Last time I used "the loadall instruction" must've been 1986. Yep, '86. Good times those were. But I can't see the connection with today's post. Oh, well, have phun too

Czernobyl, why is that stupid ?

gerryg400 wrote:Czernobyl, why is that stupid ?

Isn't it evident in context ? That poster probably meant to be funny but he's just making a fool of himself. Had he paused for thinking a minute he would've realised there is no way Loadall (X32, iAPX386! variant) could achieve what I claim.

The poster was me. I was just trying to guess what you discovered. My guess may have been incorrect, but stupid and foolish are harsh words. Be nice.

Czernobyl wrote:achieve what I claim.

Since you do not disclose what you claim, there's no way for us to verify whether what you claim is true, and therefore we must assume it isn't.


JAL