Live data from Hacker News

Linux page table isolation is not needed on AMD processors

lkml.org

81–90 of 298 posts

Re: Linux page table isolation is not needed on AMD processors

#81
post #71

Earlier quoted context omitted.

Sorry that train has left the station. JS is now a part of the web. The advice to keep JS off by default is a lot like saying "turn off your Wi-Fi by default" and "don't use a computer." People that do it occasionally experience an exaggerated sense of smugness when a particularly nasty bug is discovered, but then they go back to leading a much more difficult online life than the rest of the world.

there's a subset of the web that still remains a hypertext document database (the 'web 1.0' if you will) instead of becoming an application delivery platform (web 2.0, i hear it's almost out of beta). going JS-less on wikipedia is possible and not at all a bad experience.

Sure if you limit your life to Wikipedia that's fine. Hell, you don't even need an internet connection for it. Just download it all once in a while. But the rest of us like using places like Amazon, Slack, Google Maps, etc.

I fully support not making content delivery rely on JS. But I disabling JS because it can be used for intrusive ads is a lot like taking the wheels off your car because it can take you to the mall where you might see big for sale signs and annoying sales people. Effective, but stupid.

Re: Linux page table isolation is not needed on AMD processors

#82
I have to wonder:

Can intel release a drop in CPU that will avoid or mitigate this issue?

The infrastructure investment in intel cores is huge, if a drop in replacement lets me minimize downtime, re-gain performance and is "cost effective" compared to a cost prohibitive replacement does this result in intel having a sales INCREASE where it replaces bad silicon?

I don't know enough about this issue to speak to the issue either way, but I would love to hear if this fix is possible/viable.

Re: Linux page table isolation is not needed on AMD processors

#83
post #69

Earlier quoted context omitted.

I care about security and I do have a problem with it. http://www.logicalfallacies.info/presumption/no-true-scotsma... Yes I advocate for JS to be a part of the web. There are good reasons for it. But regardless, it has nothing to with advocates. We are in this situation because browser vendors included JS and developers and users found it useful. Again, you are free to deny the idea that this is irreversible, but I…

> and spend a whole lot of their lives fiddling with drop down menus to enable/disable JS Even without special extensions and keyboard shortcuts you spend very little time on fiddling with menus. It seems like a lot only at the beginning and quickly gets to near no fiddling at all. But it also saves time on various things, like when your adblocker doesn't catch something and you have to close those clickunder born po…

I honestly don't know what sites you are visiting where ad blocking is such a problem. I guess I'd seen an odd clone of KAT and other torrenting sites that do this shit. It's annoying, I agree. But in my daily life I rarely encounter an ad that slips by my ad blocker that makes me drop everything I am doing to go digging into how to kill it. On the contrary, I find my ad blocker more annoying sometimes in the other direction where my bank's site doesn't work and I have to disable it to get the site to e.g. show me my balance or make a credit card payment. I don't see how the savings in time will add up over a lifetime.

Re: Linux page table isolation is not needed on AMD processors

#84
post #36

At the meta level this is just a special case of "complexity is evil" in security. CPUs have been getting more and more complex, and the relationship between complexity and bugs (of all types) is exponential. Each new CPU feature exponentially increases the likelihood of errata. A major underlying cause is that we're doing things in hardware that ought to be done in software. We really need to stop shipping software…

> What we need is a binary format with a thin (not overly abstracted) pseudocode that closely models the processor. OSes could lazily compile these binaries and cache them, eliminating JIT program launch overhead except on first launch or code change. If the pseudocode contained rich vectorization instructions, etc., then there would not be much if any performance cost. In fact performance might be better since the lazy AOT compiler could apply CPU model specific optimizations and always use the latest CPU features for all programs.

This sounds halfway like ART[0].

[0]: https://en.wikipedia.org/wiki/Android_Runtime

Re: Linux page table isolation is not needed on AMD processors

#85

Was the connection with speculative execution already being discussed openly? I know about https://cyber.wtf/2017/07/28/negative-result-reading-kernel-... , but not about anything between that and 28 Dec suggesting someone made it work and that's the reason for KPTI. If it wasn't in the open, seems...not ideal embargo-wise for AMD to leak it there. Though no one's in that thread complaining about the disclosure, so m…

> Though no one's in that thread complaining about the disclosure, [...]

I imagine if someone had complaints they would make them in private so as to not make the situation even less ideal embargo-wise.

Re: Linux page table isolation is not needed on AMD processors

#86

Earlier quoted context omitted.

All the more reason to keep JS off by default... ...but the blog post above shows that you need to execute instructions that (try to) access kernel addresses, and have a handler in place to catch the inevitable exception. That doesn't seem like code a JS JIT could generate. You might be thinking of that JS RowHammer demonstration, but that was using regular memory accesses and not with the specific kernel addresses t…

Sorry that train has left the station. JS is now a part of the web. The advice to keep JS off by default is a lot like saying "turn off your Wi-Fi by default" and "don't use a computer." People that do it occasionally experience an exaggerated sense of smugness when a particularly nasty bug is discovered, but then they go back to leading a much more difficult online life than the rest of the world.

JS is only part of the browser.

Accusing people not running browsers that expose them to a nasty bug of feeling an exaggerated sense of "smugness"?

This seems disrepectful of users.

Doesnt that violate HN guidelines?

Re: Linux page table isolation is not needed on AMD processors

#87

I have to wonder: Can intel release a drop in CPU that will avoid or mitigate this issue? The infrastructure investment in intel cores is huge, if a drop in replacement lets me minimize downtime, re-gain performance and is "cost effective" compared to a cost prohibitive replacement does this result in intel having a sales INCREASE where it replaces bad silicon? I don't know enough about this issue to speak to the iss…

I wonder if this can be fixed at firmware level. (I frankly have no idea how deeply configurable Intel cores are.)

Re: Linux page table isolation is not needed on AMD processors

#88

I have to wonder: Can intel release a drop in CPU that will avoid or mitigate this issue? The infrastructure investment in intel cores is huge, if a drop in replacement lets me minimize downtime, re-gain performance and is "cost effective" compared to a cost prohibitive replacement does this result in intel having a sales INCREASE where it replaces bad silicon? I don't know enough about this issue to speak to the iss…

> … a sales INCREASE …

Don’t forget to correct for the subtle loss in credibility, and subsequent immeasurably subtle dip in sales, amortised over… forever.

Re: Linux page table isolation is not needed on AMD processors

#90

I have to wonder: Can intel release a drop in CPU that will avoid or mitigate this issue? The infrastructure investment in intel cores is huge, if a drop in replacement lets me minimize downtime, re-gain performance and is "cost effective" compared to a cost prohibitive replacement does this result in intel having a sales INCREASE where it replaces bad silicon? I don't know enough about this issue to speak to the iss…

Until more information is available, who knows. It might be fixable in microcode, it might be fixable in a new processor stepping, it might require a deeper rework that wont come out until the next generation of processors (or even the generation after that).
Post reply on HN