Live data from Hacker News

Linux page table isolation is not needed on AMD processors

lkml.org

121–130 of 298 posts

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

#121
post #71

Earlier quoted context omitted.

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…

> But disabling JS because it can be used for intrusive ads is a lot like taking the wheels off your car...

You should try it sometime. Selectively enabling JS will be annoying at first, but as long as you save your preferences, the web will soon become a much less terrible place, and you'll rarely have to tweak your config. This approach won't work for non-techies, of course, but it's not much of a hardship for someone vaguely familiar with how the web works. Amazon, for example, works fine with a bit of JS not including amazon-adsystem.com.

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

#122

Earlier quoted context omitted.

>It's a feature, not a nefarious backdoor that the NSA made Intel include under the cover of darkness. Let's be clear: It's both.

Is it? Again, that a big claim to make in five words and drop the mic. Can you cite anything to back it up?

If Intel weren't under pressure to keep a negative-ring network enabled snoopstack open by an external entity, they would by now definitely have released an update that allowed people to disable the networking aspect of IME.

Major system vendors are now offering to apply bootleg removal situations at the factory on customer request[1]. That request is not free. People are willing to /pay extra/ for no-IME laptops.

Either Intels marketing and public relations department are asleep at the wheel, or they've gone to the top to request a friendly switch to disable this and been told by the legal department that they can't have one.

[1]https://liliputing.com/2017/12/dell-also-sells-laptops-intel...

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

#123
post #55

I thought it was clear that this patch only applies to AMD. However, reading the comments here confuses me. How's does the performance on Intel drops with this?

There's code going in to perform some extra work to workaround some CPU bugs. This disables that work on AMD, because the bugs are not present there. Intel will have to do the extra work still as the bugs are present in Intel CPUs.

The full details are as yet undisclosed, implying there are security issues arising from these bugs (also the name of the flag)

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

#124
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…

Okay so take this bug for example. It seems to have to do with the CPU speculatively performing a load before checking that it won't generate a page fault due to user code trying to access kernel memory. Say you get rid of process isolation, etc. How do you protect kernel code from user code? You can't do any sort of static analysis I'm aware of that'll still allow you to run C code (which let's you manufacture pointers from arbitrary integers). And if you insert dynamic checks instead, you're talking about turning each memory access into many (memory accesses that in a modern CPU are hidden by the TLB).

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

#125
post #21

Earlier quoted context omitted.

Linux gettimeofday these days is implemented in the 'vdso', which is code provided by the kernel that runs solely in userspace. So it's not a syscall in the 'privilege level switch by executing insn that takes an exception' sense and shouldn't be affected by the syscall-entry/exit path becoming more expensive.

Does this also apply to vsyscall's being emulated? Will this mean that older static binaries will no longer run? or just suffer a penalty as well?

This topic got me to look at the vDSO for my own machine so I wrote a short Perl program to dump your kernel's vDSO.

https://pastebin.com/UnQX5U1f

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

#126
post #52

Earlier quoted context omitted.

IIRC, this fall’s i9 chips and the motherboards supporting them have software-unlockable features. You can literally buy more PCI lanes. Which is another way of saying you had those lanes, and Intel wanted more money before letting you use what you’d already bought.

AMD's triple core processors were quads with disabled cores. Often times processors within a line are processors with manually set lower clock multipliers or disabled cache. Sounds like Intel has just made it unlockable instead of permanent. It just brings to the fore what was already being done, and makes us question again the ethics of pricing models.

Nvidia‘s GeForce cards could be converted to Quadro cards by opening a chip and adding some lines with a pencil. Don’t think that this still works, but a colleague of my father did it for his home PC.

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

#127
post #71

Earlier quoted context omitted.

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…

> Slack

Slacks has an IRC gateway, though.

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

#128

Earlier quoted context omitted.

I think it will because it shows the downside of a monoculture. Hence big purchasers of CPUs will want to diversify. Also good for ARM vendors I suppose. Disclosure : bought AMD this morning before headlines saying "Buy AMD, short INTC" appeared.

Has there ever been a precedent for this? When there were major bugs in Intel CPU's (or drives, or RAM, or motherboards) did the likes of Amazon and Google invest in diversification? And has it affected stock prices meaningfully? My guess is that they'll see this as just another one off issue that can be fixed with software, then move on. For a large enterprise, monoculture that works is actually better than diversif…

> For a large enterprise, monoculture that works is actually better than diversification.

But that's the problem. Nothing works 100% of the time, which is why monoculture is bad. When there is a bug that affects 20% of your systems, you can continue operating at 80% capacity, which at a reasonable level of reserve/redundancy means you're still entirely up. With a monoculture the bug affects everything and you're entirely down.

> But when you buy 100k motherboards and spend the time adjusting your tooling to those, from packaging to power, to cooling, to support, to OS code, etc. and then you on a whim decide to get another 100k motherboards of a different architecture, you spend a non-trivial amount of time and money to support those as well.

This is why hardware abstraction is a thing.

It's almost always less expensive to support diverse hardware from the beginning than to wait until after the market shifts.

Eventually the day comes to switch from 68K to PowerPC, or PowerPC to Intel, or Intel to ARM, or ARM to whatever else. Because eventually you save/gain a zillion dollars by switching and it "only" costs three quarters of a zillion to switch.

But it would have cost a tenth that much to have supported diverse hardware from the start, and then the transition is only a matter of using more of the now-superior hardware rather than being stuck on the now-inferior hardware for potentially years while everything is rearchitected from scratch.

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

#129

Earlier quoted context omitted.

Is it? Again, that a big claim to make in five words and drop the mic. Can you cite anything to back it up?

If Intel weren't under pressure to keep a negative-ring network enabled snoopstack open by an external entity, they would by now definitely have released an update that allowed people to disable the networking aspect of IME. Major system vendors are now offering to apply bootleg removal situations at the factory on customer request[1]. That request is not free. People are willing to /pay extra/ for no-IME laptops. Ei…

OK, but that's (a) 100% speculation and (b) fails Hanlon's razor.

I don't like the fact that you can't disable ME, that it's not open source, and that it's vulnerable any more than anyone else. But this does seem like hyperbole much more than fact.

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

#130
post #70

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…

It wasn't publicly acknowledged but people figured it out already. Take a look at https://news.ycombinator.com/item?id=16046636 (both the article and the comments) for example. This wasn't going to stay secret much longer.

That post is a couple days after the 28 Dec AMD commit, though. Curious if it was _already_ discussed since that would mean no way what AMD said is how people figured it out.

my123 does point out that the author of the speculative execution blog post is first in the KAISER paper's acknowledgments, and looks like the paper was presented at a July conference, so that's an earlier clue out in public, for what it's worth.

Post reply on HN