The mysterious case of the Linux Page Table Isolation patches

Post by joshtopher » Tue, Jan 02, 2018, 5:05 AM UTC

userbinator wrote: post #47

hujji wrote: post #40

Earlier quoted context omitted.

The current miniaturization of DRAM circuitry doesn't really allow for a hardware fix for the RowHammer attack. During DRAM manufacturing a test similar to the RowHammer attack exists. This test has certain bounds for passing. If the bounds were tightened up to the level of perfection to prevent the attack it would drop the yield a considerable amount.

If the bounds were tightened up to the level of perfection to prevent the attack it would drop the yield a considerable amount. The fact that DRAM older than a few years is effectively immune to RH suggests it is possible to manufacture such. Yes, it will cost more, but I think many would be willing to pay for it like they used to, for none other than the assurance of having more reliable memory.

Post by dboreham » Tue, Jan 02, 2018, 5:15 AM UTC

pkaye wrote: post #180

ajarmst wrote: post #143

Earlier quoted context omitted.

Alpha particle emissions are common causes of single-bit errors, especially from ceramic enclosure materials in integrated circuits. Mitigating soft errors from circuit packaging is an active area of research in materials science. Parity bits and CRC error checking are needed precisely to reduce the impact of these errors down to manageable levels.

"Alpha particles can be stopped by a sheet of paper, beta particles by aluminum, and gamma radiation by a block of lead." This is what I read online. A typical hardware components is enclosed in a aluminum case so really gamma radiation is of concern right?

Post by jsolson » Tue, Jan 02, 2018, 5:26 AM UTC

foobarbazetc wrote: post #188

saas_co_de wrote: post #166

Earlier quoted context omitted.

Totally agree. Cloud makes tons of sense if your workload is really dynamic. Lots of small players are running static workloads though because actually setting up dynamic workloads is pretty complex. I use GCE for DNS, Storage, CDN (for fronting storage backed files), dynamic workloads that can run on preemptible instances, and scalable instances to serve published static content, but I use dedicated servers for data…

Yeah we’re medium size but still bare metal at IBM/SoftLayer. We keep looking at GCP waiting for the pricing to make sense and still trying to figure out how people run low latency Postgres on there. :)

Post by numbsafari » Tue, Jan 02, 2018, 5:40 AM UTC

amluto wrote: post #134

rurban wrote: post #79

Earlier quoted context omitted.

No, not AWS. Xen was called safe. All the other KVM providers and normal linux servers in Intel are called out. arm, sparc, s390 were called out as safe, as they provide two seperate translation table registers, only intel provides only one.

I don't think ARM64 works the way you think it does. On s390, there's a register for user-initiated access and a register for kernel-initiated access. On ARM64 (AIUI), there's a register for low (user) addresses and a register for high (kernel) addresses. So kASLR timing leaks on s390 shouldn't happen in the first place unless the TLB tagging itself is rather silly, but ARM64 has no inherent protection. What ARM64's…

Post by JdeBP » Tue, Jan 02, 2018, 7:43 AM UTC

caf wrote: post #187

amluto wrote: post #62

Earlier quoted context omitted.

And, for reasons that are entirely unknown, the issue got worse due to one of the PTI patches (written by, and hence tentatively blamed on, yours truly). Presumably it caused some minor change in code generation causing GCC to go nuts. FWIW, the compile flag that Gentoo enabled activates a seriously busted GCC feature, and I'm a bit surprised that Gentoo gets away with it in user code.

Is there anywhere to read up on the bustedness of the stack probing feature? (apart from the obvious incompatibility with trying to do that for kernel code).