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

Linux page table isolation is not needed on AMD processors

lkml.org

Post reply on HN
Print view View original

181–190 of 298 posts

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

#181

Post by adrianratnapala »

aslkdjaslkdj wrote: post #172
cma wrote: post #163

Earlier quoted context omitted.

I've heard you can schedule big sales all the time and then regularly cancel them unless something goes wrong. Apparently there is no rule against insider canceling.

That's not true. Changing a stock sale plan in any way is considered insider trading. The window has nothing to do with whether it's legal or not. It's only used a risk mitigation and is up to company policy. https://corpgov.law.harvard.edu/2013/02/05/rule-10b5-1-plans...

I think the point the cma was making is that this trick doesn't involve making changes to (formal) stock-sale plans. The formal plan is to sell regularly, and that remains unchanged, you just cancel it by hand habitually, except when you don't.

I am no lawyer, so I don't know if this is really allowed. My gut instinct is (a) no, it is not allowed and (b) there will always be some more subtle version of the tactic that is allowed.

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

#182

Post by mehrdadn »

asveikau wrote: post #179
mehrdadn wrote: post #173

Earlier quoted context omitted.

> If you have a heavily-contended mutex you already have a major performance bug. I can't really devote time to countering the unfounded assertion that every contended mutex must be a bug. It certainly isn't consistent with my experience, but if every problem you've solved could have been parallelized infinitely without increasing lock contention, more power to you.

Let's put it this way. If every contended mutex were a bug, why not remove the mutex and let the code run as-is? No, you wouldn't, so no, not a bug.

> Let's put it this way. If every contended mutex were a bug, why not remove the mutex and let the code run as-is? No, you wouldn't, so no, not a bug.

I mean, the parent's argument is wrong, but isn't that naive. Presumably the argument is a bad (yet still correct) solution would result in lock contention while a better solution would e.g. use a different algorithm that is more parallelizable.

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

#183

Post by amluto »

tankenmate wrote: post #41
pm215 wrote: 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?

Emulated vsyscalls were already very slow and will be even slower on a patched kernel. They'll still work, though.

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

#184

Post by jopsen »

I sometimes wonder if verifying properties of the code we run wouldn't be smarter than relying on hardware isolation. Or at-least in addition to hardware isolation, so that there is two layers.

By verify I'm thinking NativeClient-like or JVM isolation.

Obviously, it would entail complete OS rewrite, or maybe partial...

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

#185

Post by kentonv »

kevin_thibedeau wrote: post #166
kentonv wrote: post #144

Earlier quoted context omitted.

I don't think this issue is related to rowhammer. I think people have been speculating about rowhammer because it's a famous hardware bug, but none of the details of page table isolation seem to align with a rowhammer-based attack.

This enables the first step in a rowhammer attack: identify the privileged address you want to target.

Oh, are you thinking the KASLR bypass is actually the main problem, because it allows targeted rowhammer? I'm not sure if that's really true, since a KASLR bypass would give you a virtual address, and rowhammer would care more about physical addresses.

But in any case, the KASLR bypass is not the main vulnerability here. KASLR is widely seen as too leaky to be really useful. Linux would not rush out a >5% performance hit just to fix one of the many leaks.

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

#186

Post by amluto »

SolarNet wrote: post #151
anonacct37 wrote: post #2

This feels like a big FU to Intel. I've heard this patch can slow down programs like du by 50%. Does that mean AMD is going to find itself running twice as fast as competitors?

Yes. AMD didn't take shortcuts, and implemented the spec correctly. Intel took shortcuts, introduced bugs, and now to compensate for that the OS has to work around it in software, it's going to be slow. For years Intel has reaped the benefits of shortcuts for performance, while AMD has been implementing things correctly; now there is a correction. That's how the market works.

AMD doesn't exactly do an amazing job of avoiding gotchas in their CPUs. They have a bizarre idea of what writing zero to a segment register should do (resulting in info leaks that were only recently fixed on Linux), their demented leaky IRET is even more demented than Intel's, and their SYSRET's handling of SS is downright nutty.

OTOH, Intel's SYSRET is actively dangerous and has resulted in severe security holes, and Intel doesn't appear to acknowledge that their design is a mistake or that it should be fixed.

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

#187

Post by kllrnohj »

mehrdadn wrote: post #173
kllrnohj wrote: post #165

Earlier quoted context omitted.

Thread-suspending contended mutexes are already extremely slow. If you have a heavily-contended mutex you already have a major performance bug. If this is the kick in the pants you need to go fix it that's arguably a good thing ;) Note that mutex contention does not itself mean immediately falling back to futex - commonly you'll spinloop first and hope that resolves your contention (fast), then fall back to futex (sl…

> If you have a heavily-contended mutex you already have a major performance bug. I can't really devote time to countering the unfounded assertion that every contended mutex must be a bug. It certainly isn't consistent with my experience, but if every problem you've solved could have been parallelized infinitely without increasing lock contention, more power to you.

> I can't really devote time to countering the unfounded assertion that every contended mutex must be a bug.

Good, because that's not what I said. If you're heavily hitting futex convention you do have a performance bug, though. You might be confused with general contention that's being resolved with a spinlock rather than futex wait, though.

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

#188

Post by fulafel »

IgorPartola wrote: post #80
fulafel wrote: post #77

Earlier quoted context omitted.

Security track record is taken seriously by many big vendors.

Is it? That seems like a big broad claim. Again, after things like RowHammer, did anyone actually do anything differently in a way that affected stock prices?

Like everyone else, I sure would want to know what kinds of conversations have been going on around RowHammer and customers most affected by it, and system/DRAM vendors.

I'm not a believer in stock price as good indicator of anything, sorry to skip that part.

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

#189

Post by mehrdadn »

kllrnohj wrote: post #187
mehrdadn wrote: post #173

Earlier quoted context omitted.

> If you have a heavily-contended mutex you already have a major performance bug. I can't really devote time to countering the unfounded assertion that every contended mutex must be a bug. It certainly isn't consistent with my experience, but if every problem you've solved could have been parallelized infinitely without increasing lock contention, more power to you.

> I can't really devote time to countering the unfounded assertion that every contended mutex must be a bug. Good, because that's not what I said. If you're heavily hitting futex convention you do have a performance bug, though. You might be confused with general contention that's being resolved with a spinlock rather than futex wait, though.

>> I can't really devote time to countering the unfounded assertion that every contended mutex must be a bug.

> Good, because that's not what I said.

It is literally what you said:

>>> If you have a heavily-contended mutex you already have a major performance bug. If this is the kick in the pants you need to go fix it that's arguably a good thing ;)

> You might be confused with general contention that's being resolved with a spinlock rather than futex wait, though.

I'm not confusing them at all; I'm literally reading exactly what you wrote. You literally said contended mutexes are necessarily bugs (right here^) and that you considered mutexes to include the initial spinlocks ("note that mutex contention does not itself mean immediately falling back to futex - commonly you'll spinloop first"). But maybe you meant to say something else?

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

#190

Post by kllrnohj »

Sir_Substance wrote: post #122
IgorPartola wrote: post #119

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…

Adding that option costs them money (engineering time, QA time, support issues resulting from it, etc...)

Until it's financially worth their while, why would they spend money on it?

Post reply on HN