Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The mysterious case of the Linux Page Table Isolation patches

pythonsweetness.tumblr.com

Post reply on HN
Print view View original

91–100 of 264 posts

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

#91

Post by HelloNurse »

fiddlerwoaroof wrote: post #54
userbinator wrote: post #47

Earlier quoted context omitted.

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.

Isn’t the problem related to the capacity of current memory modules? So you can have, say, a 32GB module that’s vulnerable or a 8GB module that isn’t? (Assuming the 8GB module uses lower density DRAM chips)

A new 8GB DIMM module has about 1/4 the silicon area of a new 32GB module and the same density (often 1/4 the number of identical chips); only an old 8GB module, made with an entirely different process, would have larger and less dense safer DRAM cells.

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

#92

Post by sciurus »

gjvc wrote: post #23
revelation wrote: post #7

No ones hiding anything, this patchset was developed in the open for many many months. The hysteria and intrigue in this random tumblr blog is completely superfluous. It's a hardware bug anyway. Here is a good hint to when something is not being embargoed: there is a paper and a public demonstration.

Where is the paper and public demonstration in this case?

https://gruss.cc/files/kaiser.pdf

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

#93

Post by aeleos »

Usually I go into these things with a fair amount of skepticism but given the linux kernels usual pace of development and the nature of undisclosed bugs we have seen in the past this seems like a large hypervisor bug could be the reality. It must be pretty bad if its the kind of bug that they can't really fix easily, and have to push through an entire new feature into something as old and important as the paging code.

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

#94

Post by IronBacon »

Asdfbla wrote: post #67

Just curious: Even after an attacker goes through all the effort of finding out the physical address of the memory location they want to manipulate, how would someone make sure to get an adjacent memory location to even attempt to execute the Rowhammer attack? And even then, the smallest memory units allocated are basically pages within page frames, right? So if your target memory row is within a physical page frame,…

On Android there was a rowhammer POC used to gain root. Never looked at the details but it's in my TODO list... ^__^;

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

#95

Post by jabl »

twoodfin wrote: post #82

I'm confused about the TLB impact. The pythonsweetness link claims these patches now require TLB flushes when crossing the kernel/user boundary, but the description of KAISER @ lwn[1] suggests that these flushes are unnecessary with "more recent" processors supporting PCIDs. How recent is "more recent", and is the PCID support likely to be ported back to earlier kernels along with KPTI? TLB flushes for syscalls would…

According to https://www.realworldtech.com/westmere/ , PCID's were introduced in the Westmere generation.

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

#96

Post by fulafel »

JoshTriplett wrote: post #80
fulafel wrote: post #77

Earlier quoted context omitted.

There are many examples of hardware using unreliable underlying layers, countered with whitening/scrambling, redudancy and other data encoding tricks. What would make RowHammer imprevious to these?

Those tricks cost latency. You can get away with hiding some of that latency in access time to persistent storage. It's much harder to do so with RAM. ECC helps, and can be done at full rate, but isn't a complete solution for all possible problems. And anything you do in hardware at full RAM speed is expensive.

This is far away from "hardware fix is impossible" though. In reputable hardware, hardware vendors are expected to maintain correctness in spite of performance advances.

Also, DDR3/4 DRAM is glacially slow in latency terms, it's far from clear that there would be appreciable slowdown. There are already big latency compromises in the standardized JEDEC protocols that are not inherent in DRAM - it would be very two-faced for DRAM vendors to say they'll only trade off latency over backward compatibility or tiny cost savings, but not over correctness.

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

#97

Post by seibelj »

Asdfbla wrote: post #67

Just curious: Even after an attacker goes through all the effort of finding out the physical address of the memory location they want to manipulate, how would someone make sure to get an adjacent memory location to even attempt to execute the Rowhammer attack? And even then, the smallest memory units allocated are basically pages within page frames, right? So if your target memory row is within a physical page frame,…

If it’s something that can be triggered from browser JavaScript, maybe it can be attempted N times per second, and there is a mathematical probability of gaining full privileges within a set amount of attempts.

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

#98

Post by fiddlerwoaroof »

HelloNurse wrote: post #91
fiddlerwoaroof wrote: post #54

Earlier quoted context omitted.

Isn’t the problem related to the capacity of current memory modules? So you can have, say, a 32GB module that’s vulnerable or a 8GB module that isn’t? (Assuming the 8GB module uses lower density DRAM chips)

A new 8GB DIMM module has about 1/4 the silicon area of a new 32GB module and the same density (often 1/4 the number of identical chips); only an old 8GB module, made with an entirely different process, would have larger and less dense safer DRAM cells.

Yeah, that's why I included the qualification

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

#99

Post by bhouston »

neerajsi wrote: post #66
john_moscow wrote: post #45

>public NT kernels from as early as November have begun to implement the same technique. Does the author refer to ReactOS, or has Microsoft really open-sourced parts of the NT kernel?

Reverse engineers pretty much know how everything in NT works. Msft publishes enough symbols that it's even possible to automatically decompile much of the code. Something like page table splitting would be obvious.

And the source of an older version of NT leaked a while back.

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

#100

Post by saas_co_de »

qume wrote: post #44

The bare metal cloud providers will be rubbing their hands together

I never understand why people don't go bare metal. It is just as easy to automate, just as cheap (or cheaper) if you plan well, and more secure.

A decade ago everyone knew that shared hosting was for hobby sites and stuff that didn't really matter.

Maybe some more people will learn that lesson.

Post reply on HN