The mysterious case of the Linux Page Table Isolation patches • Hacker News Board

Re: The mysterious case of the Linux Page Table Isolation patches

#221

Post by orbifold » Tue, Jan 02, 2018, 12:58 PM UTC

baybal2 wrote: post #217

wilun wrote: post #178

Earlier quoted context omitted.

Ok so it seems that Intel CPU do some speculative execution on priviledged data from unpriviledged code, including from (at least some and at least part of) separate following instructions. Given the microarchitectural complexity and the already well-known side channel attacks, I would not be surprised at all if someone just finished the work and demonstrated that you can actually read priviledged data with a correct…

>Intel CPU do some speculative execution on priviledged data from unpriviledged code, including from (at least some and at least part of) separate following instructions. That was known since pentium 3 times, I wonder why nobody thought of this as a wonderful exploit target before >I'm 90% convinced there is no way Intel managed to close all the side-channels on such a complex architecture This is why one should not…

What should one use instead? VHDL, Bluespec, Chisel? I don‘t know of any solution that makes verification significantly easier compared to SystemVerilog.

Re: The mysterious case of the Linux Page Table Isolation patches

#222

Post by cesarb » Tue, Jan 02, 2018, 1:02 PM UTC

acoye wrote: post #214

sd8dgf8ds8g8dsg wrote: post #186

Earlier quoted context omitted.

I'm confused, what makes you think the AMD and Intel cpu internals are the same?

It is not, but if like it was the case for rowhammer, it was linked to a specific instruction (clflush). This time it could be an AVX512 instruction (intel only) that leaks kernel address in a way or another. I was talking from an ISA perspective. For eg, clflush may be implemented differently between Intel and AMD, it has the same effect on system RAM hence a shared exploit.

> It is not, but if like it was the case for rowhammer, it was linked to a specific instruction (clflush).

No, rowhammer does not need clflush. All rowhammer needs is to be able to write to the same physical memory locations repeatedly. Normally the cache would get in the way, so the attacker needs to bypass it. Flushing the cache (clflush) is one way, but there are others; AFAIK, it has been demonstrated rowhammer from within a Javascript VM, which has no access to clflush.

Re: The mysterious case of the Linux Page Table Isolation patches

#223

Post by cesarb » Tue, Jan 02, 2018, 1:07 PM UTC

acoye wrote: post #156

Ok so all I hear is Intel and no trace of AMD? So X86_64 ISA wise the only diff between modern CPUs are AVX512. I bet you within the foundations of AVX512 lies a nasty one that can't be patched with microcode update.

There are other differences between Intel and AMD's implementation of the x86-64 ISA. For an exemple of a bug which affected only Intel processors: https://blog.xenproject.org/2012/06/13/the-intel-sysret-priv...

Re: The mysterious case of the Linux Page Table Isolation patches

#224

Post by baybal2 » Tue, Jan 02, 2018, 1:25 PM UTC

orbifold wrote: post #221

baybal2 wrote: post #217

Earlier quoted context omitted.

>Intel CPU do some speculative execution on priviledged data from unpriviledged code, including from (at least some and at least part of) separate following instructions. That was known since pentium 3 times, I wonder why nobody thought of this as a wonderful exploit target before >I'm 90% convinced there is no way Intel managed to close all the side-channels on such a complex architecture This is why one should not…

What should one use instead? VHDL, Bluespec, Chisel? I don‘t know of any solution that makes verification significantly easier compared to SystemVerilog.

It will be VHDL for the reason it removes a lot undefined behaviours by design.

Tooling support for VHDL is lacking thought, any big company with in house formal verification must have their own tooling...

Re: The mysterious case of the Linux Page Table Isolation patches

#225

Post by acoye » Tue, Jan 02, 2018, 2:30 PM UTC

cesarb wrote: post #222

acoye wrote: post #214

Earlier quoted context omitted.

It is not, but if like it was the case for rowhammer, it was linked to a specific instruction (clflush). This time it could be an AVX512 instruction (intel only) that leaks kernel address in a way or another. I was talking from an ISA perspective. For eg, clflush may be implemented differently between Intel and AMD, it has the same effect on system RAM hence a shared exploit.

> It is not, but if like it was the case for rowhammer, it was linked to a specific instruction (clflush). No, rowhammer does not need clflush. All rowhammer needs is to be able to write to the same physical memory locations repeatedly. Normally the cache would get in the way, so the attacker needs to bypass it. Flushing the cache (clflush) is one way, but there are others; AFAIK, it has been demonstrated rowhammer f…

Yes, I knew you could do rowhammer on arm too where clflush does not exit. So rowhammer is not the correct example. Yet at some point it was believed that it was necessary on x86 for the attack to work. https://en.wikipedia.org/wiki/Row_hammer#Exploits

I just made a bet that I could guess something out of ISA only. Going macro to describe what may be the issue. I'm just doing a guess work here.

I was not implying Intel has the same implementation as AMD, nor I was making a case for "this is like rowhammer"

Re: The mysterious case of the Linux Page Table Isolation patches

#226

Post by JdeBP » Tue, Jan 02, 2018, 2:53 PM UTC

baybal2 wrote: post #224

orbifold wrote: post #221

Earlier quoted context omitted.

What should one use instead? VHDL, Bluespec, Chisel? I don‘t know of any solution that makes verification significantly easier compared to SystemVerilog.

It will be VHDL for the reason it removes a lot undefined behaviours by design. Tooling support for VHDL is lacking thought, any big company with in house formal verification must have their own tooling...

What undefined behaviours are those?

Re: The mysterious case of the Linux Page Table Isolation patches

#227

Post by rst » Tue, Jan 02, 2018, 2:55 PM UTC

wilun wrote: post #161

justincormack wrote: post #151

Looks like it is speculative execution based, and does not affect AMD https://lkml.org/lkml/2017/12/27/2 AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would resu…

I guess Intel decided to speculate data access regardless of privilege level of the target address, with the theory that what has been successfully speculated can't be accessed anyway before the permission are really checked, and somebody found a bug (or given all Intel processors are taggued as unsecure, maybe a quasi-architectural hole) that let read the speculated data or a significant subset or trace of it. My wi…

One possible vector suggested by Matt Tait (pwnallthethings) on Twitter: if speculative operations can influence what the processor does with the cache, the results can be observed with cache timing attacks. If the branch predictor reads the results of speculative operations, it's real easy, as he suggests here:

https://twitter.com/pwnallthethings/status/94797892728438374...

but (as he notes elsewhere) there are plenty of other channels in an Intel processor for information to leak...

Re: The mysterious case of the Linux Page Table Isolation patches

#228

Post by wastewaste » Tue, Jan 02, 2018, 3:02 PM UTC

baybal2 wrote: post #217

wilun wrote: post #178

Earlier quoted context omitted.

Ok so it seems that Intel CPU do some speculative execution on priviledged data from unpriviledged code, including from (at least some and at least part of) separate following instructions. Given the microarchitectural complexity and the already well-known side channel attacks, I would not be surprised at all if someone just finished the work and demonstrated that you can actually read priviledged data with a correct…

>Intel CPU do some speculative execution on priviledged data from unpriviledged code, including from (at least some and at least part of) separate following instructions. That was known since pentium 3 times, I wonder why nobody thought of this as a wonderful exploit target before >I'm 90% convinced there is no way Intel managed to close all the side-channels on such a complex architecture This is why one should not…

tricky grammar. You mean formal, mathematical verification instead of simulation, I suppose, but I am not aware of any different method.

Re: The mysterious case of the Linux Page Table Isolation patches

#229

Post by contrarian_ » Tue, Jan 02, 2018, 3:52 PM UTC

wilun wrote: post #161

justincormack wrote: post #151

Looks like it is speculative execution based, and does not affect AMD https://lkml.org/lkml/2017/12/27/2 AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would resu…

I guess Intel decided to speculate data access regardless of privilege level of the target address, with the theory that what has been successfully speculated can't be accessed anyway before the permission are really checked, and somebody found a bug (or given all Intel processors are taggued as unsecure, maybe a quasi-architectural hole) that let read the speculated data or a significant subset or trace of it. My wi…

Perhaps an interaction with conditional branches and cache timing? You could then extract individual bits from privileged memory by having the CPU pull in specific cache lines as part of a speculatively executed branch on the value of the bit.

Re: The mysterious case of the Linux Page Table Isolation patches

#230

Post by mikeash » Tue, Jan 02, 2018, 4:21 PM UTC

blattimwind wrote: post #109

tzs wrote: post #64

Earlier quoted context omitted.

Almost everything I've seen on error rates from radioactive decay and cosmic particles has been on servers in data centers. I wonder if home systems are equally vulnerable, or if there is something about data center system design or facilities that make them more susceptible? I ask because I had a couple of home desktop Linux boxes once, without ECC RAM, that were running as lightly loaded servers. I ran a background…

> I wonder if home systems are equally vulnerable, or if there is something about data center system design or facilities that make them more susceptible? I was told once that today's concrete has a much higher background radiation than brick and mortar from before the 50s. There is also more steel in data centres. However, I'm not at all sure if background radiation of building materials is even in the right order o…

A bit of a tangent, but somewhat related to your bit about concrete: steel salvaged from ships built before 1945 is less radioactive than modern steel and is useful for devices that are extremely sensitive to radiation: https://en.wikipedia.org/wiki/Low-background_steel

The reason the modern stuff is more radioactive is the massive number of atmospheric nuclear weapons tests conducted starting in 1945. I imagine the concrete has the same issue.