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

81–90 of 264 posts

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

#81

Post by JoshTriplett »

cm2187 wrote: post #56
qume wrote: post #44

The bare metal cloud providers will be rubbing their hands together

Though isn’t it only a problem when two VM share the same physical machine? If yes then all you need to do as a client is to never rent a fraction of a physical machines but specs that correspond to a full machine.

> If yes then all you need to do as a client is to never rent a fraction of a physical machines but specs that correspond to a full machine.

Cloud vendors don't guarantee colocation of your resources unless you specifically arrange that. And for that matter, often you specifically don't want co-location, because you want redundancy and migration.

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

#82

Post by twoodfin »

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 be absolutely brutal for many performance-critical applications.

[1] https://lwn.net/Articles/738975/

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

#83

Post by userbinator »

zymhan wrote: post #71
userbinator wrote: post #20

IMHO, with RowHammer, the hardware is broken and it will continue to be broken until users complain enough --- maybe to the point of absolutely refusing to buy --- that the manufacturers and designers stop thinking "works 99.9999999999% of the time" is good enough: https://news.ycombinator.com/item?id=12410274

There is no way the average technology user is going to understand the architectural distinctions of DRAM implementations enough to base their purchasing decisions on that.

I agree, there needs to be an easy but also reliable way to show the problem. The FDIV bug received much public attention because it could be easily reproduced on Windows' built-in calculator.

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

#84

Post by jtchang »

userbinator wrote: post #20

IMHO, with RowHammer, the hardware is broken and it will continue to be broken until users complain enough --- maybe to the point of absolutely refusing to buy --- that the manufacturers and designers stop thinking "works 99.9999999999% of the time" is good enough: https://news.ycombinator.com/item?id=12410274

Umm this is very shortsighted and absolutely trash.

There are many types of users and some don't care if it fails in a blue moon. Hell 99% might be good enough if the price was right.

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

#86

Post by monochromatic »

avian wrote: post #57
userbinator wrote: post #37

Earlier quoted context omitted.

Radioactive decays and cosmic particles flipping bits give an upper bound for reliability well below 99.9999999999% If it works 99.9999999999%, then it has a failure rate of 0.0000000001%, or 1E-12. Considering that a modern CPU executes approximately 1E9 operations per second, and that regular HDDs have a worse-case BER of 1 in 1E14 bits, 1E-12 is actually rather horrible and the actual error rate of computer hardwa…

I edited my reply to remove the actual number. The argument still stands that you cannot expect 100% reliability.

A small probability of random errors can be lived with. Errors that can be triggered and exploited are unacceptable.

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

#87

Post by saas_co_de »

empath75 wrote: post #78
avh02 wrote: post #39

Earlier quoted context omitted.

No, but they prevent everybody with ill-intent from exploiting the issue en-masse

If this guy can figure this out, anybody with the means and motivation to write such an exploit is already working on t.

Exactly. This is just some random nerd. There are people all over the world whose full time job it is to track open source projects to develop exploits.

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

#89

Post by bonzini »

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…

PCID support is unlikely to be backported, but perhaps a simpler scheme with only two PCIDs (user and kernel) could be applied...

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

#90

Post by lawnchair_larry »

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?

The author of that citation (Alex Ionescu) is known for reverse engineering the NT kernel, and in some cases, implementing features for ReactOS accordingly. He would have been referring to the NT kernel, which he seems to disssemble and comment on with every update.
Post reply on HN