OSDev.org

http://www.kb.cert.org/vuls/id/649219

An OS kernel running in a virtualized environment may execute sysret to a non-canonical sysret address - Intel CPU's will #GPF to ring 0, non-virtualized, but RSP (the stack pointer) is still pointing to the guest value. AMD CPU's are not affected.

Something to be aware of.

This has nothing to do with virtualised environments. It's simply an instruction that behaves differently on Intel and AMD, on real hardware, with no virtualisation involved at all. Still something to be aware of, of course.

Kevin wrote:This has nothing to do with virtualised environments. It's simply an instruction that behaves differently on Intel and AMD, on real hardware, with no virtualisation involved at all. Still something to be aware of, of course.

Well, no, it's an instruction that behaves differently on Intel and AMD when virtualization is enabled, and presents a significant security hole on Intel chips using virtualization because of it. It basically means you can exploit the host kernel if you take control of the guest kernel, which is pretty serious.

Of course, few of us are going to be running virtualized environments under our OSes, so it's not that relevant here.

NickJohnson wrote:

Kevin wrote:This has nothing to do with virtualised environments. It's simply an instruction that behaves differently on Intel and AMD, on real hardware, with no virtualisation involved at all. Still something to be aware of, of course.

Well, no, it's an instruction that behaves differently on Intel and AMD when virtualization is enabled, and presents a significant security hole on Intel chips using virtualization because of it. It basically means you can exploit the host kernel if you take control of the guest kernel, which is pretty serious.

Of course, few of us are going to be running virtualized environments under our OSes, so it's not that relevant here.

Virtualization is completely irrelevant here. If you read fully into the CERT reports, you'll find that its a quite simple case of Intel implementing SYSRET wrong.

NickJohnson wrote:Well, no, it's an instruction that behaves differently on Intel and AMD when virtualization is enabled, and presents a significant security hole on Intel chips using virtualization because of it. It basically means you can exploit the host kernel if you take control of the guest kernel, which is pretty serious.

Of course, few of us are going to be running virtualized environments under our OSes, so it's not that relevant here.

Thanks for your opinion. And now go and read up what the problem really is.

I mean, I'm not correcting a statement just because I felt like confusing readers...

It's pretty fascinating, but, OpenBSD isn't vulnerable to this. A few releases ago OpenBSD switched to using iretq in signal handlers instead of sysretq.

As others have said, this vulnerability has nothing to do with virtualization.. it's an Intel bug.

Depends on how you define "bug". The behaviour is documented in the Intel manuals, so that's the excuse they're using. Still makes it a misfeature at best, it being incompatible with AMD is a nasty surprise.

Brynet-Inc wrote:As others have said, this vulnerability has nothing to do with virtualization.. it's an Intel bug.

It has something to do with virtualization because it caused a vulnerability in existing virtualization software implementations that would allow escape from the guest environment. I'm not trying to say that the so-called 'bug' is a virtualization bug per se, but the reason people care (or cared, since it's been patched already) is because of that vulnerability.

Kevin wrote:Depends on how you define "bug". The behaviour is documented in the Intel manuals, so that's the excuse they're using. Still makes it a misfeature at best, it being incompatible with AMD is a nasty surprise.

Implementing a part of the ISA (AMD64, in this case) wrong is a bug IMHO, even if Intel have filed it as WONTFIX

NickJohnson wrote:I'm not trying to say that the so-called 'bug' is a virtualization bug per se, but the reason people care (or cared, since it's been patched already) is because of that vulnerability.

Xen PV was vulnerable, indeed, because it works more like a normal OS and doesn't use the virtualisation extensions. Apart from that FreeBSD and Windows are mentioned. Maybe people do care more about Xen than Windows, but stressing the virtualised environment (which exists in only one of the cases) lets the problem appear more harmless than it is.