old news. https://cyber.wtf/2017/07/28/negative-result-reading-kernel-...
This isn't about the original vulnerability. It's about the linux kernel disabling the fix patch (and the performance hit) for AMD processors.
Linux page table isolation is not needed on AMD processors
241–250 of 298 posts
Re: Linux page table isolation is not needed on AMD processors
#242Earlier quoted context omitted.
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 tha…
Just hire a DDoS attack anonymously so your attempt to sell fails, pretend you've got nothing to do with it
Re: Linux page table isolation is not needed on AMD processors
#243This is going to have dramatic effect on the cloud computing market. It might make sense to make sure any VMs you run are on AMD processors or it can really hurt your performance and basically cost you more to do the same workload. It also seems, from early benchmarks, this can slaughter performance with databases.
Why are people insisting this affects cloud computing market? I am not sure if this bug is absolutely limited to cloud instances.
Because for example most consumers don't care.
Re: Linux page table isolation is not needed on AMD processors
#244Earlier 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.
> AMD's triple core processors were quads with disabled cores.
That's binning & price discrimination, Intel did the same (with quads v dual IIRC): if you have a defective core, you gate it and sell a 2/3 core instead of a quad. Of course the issue is when the low bin becomes too popular and you have to start low-binning "perfect" parts to keep supplies acceptable (used to be very common for Intel starting ~mid-cycles, they'd literally run out of defects, which is why their low-end CPUs had such good performances & were ridiculously overclockable)
Re: Linux page table isolation is not needed on AMD processors
#245Wouldn't this kind of issue validate the ideas of microkernel-based OSs, where kernel and user spaces are already completely separated? BTW, removing the kernel from the non-privileged address space seems like such a great idea (which is not a new one at all) the whole thing should probably should have some hardware support to be made fast.
> Wouldn't this kind of issue validate the ideas of microkernel-based OSs, where kernel and user spaces are already completely separated?
I don't think so, but it depends what you mean.
Kernel space and user space being separated isn't specific to a microkernel. The only reason the kernel is mapped in to each process is to avoid the TLB flush during syscalls. The pages themselves aren't actually accessible unless you're running in kernel mode (well, unless you're using hardware affected by this bug). So, in a non-broken system, kernel and user spaces are separated, even with a monolithic kernel (Linux).
> BTW, removing the kernel from the non-privileged address space seems like such a great idea (which is not a new one at all) the whole thing should probably should have some hardware support to be made fast.
For the most part, I agree. However, it really shouldn't be necessary if the virtual memory protection did what it was supposed to do. Mapping the kernel in to the process address space and using the page protection flags is an optimization that is perfectly legal from an architectural standpoint.
If you can't rely on the page protection flags to work, then you really can't rely on any other hardware feature to work either.
Re: Linux page table isolation is not needed on AMD processors
#246Earlier quoted context omitted.
For years, Intel and AMD processors have supported patching using microcode updates. Until we know the embargo is lifted and we know the full extent of this vulnerability, we won't know if that would be possible.
Based on the fact that kernel patches are going in it's reasonable to assume this means it can't be fixed with a microcode update. Otherwise, Intel would issue a microcode update and the Linux kernel wouldn't be accepting this patch set as a mitigation for this issue (which is all this patch set is, it has no other benefit to the end user than fixing this bug).
It depends on how long it takes for Intel to go through all regression tests for all affected platforms. If it takes several months to complete, a countermeasure in the kernel update may still be the better stopgap.
Or maybe it could be that Intel privately disclosed already that no backport will be done to firmware of older CPUs, in which case the kernel update is the stopgap for newer generation and the solution for older generations.
Re: Linux page table isolation is not needed on AMD processors
#247Earlier quoted context omitted.
> 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 resolve…
He said "heavily contended", and then you dropped the "heavily" prefix and claimed that was literally what he said. That adverb is material to the discussion and your dropping it completely changes the meaning.
I concur with his opinion. Infrequent contention is not a bug; otherwise no mutex is needed. Frequent contention (or heavy contention in his words) is a performance bug.
Re: Linux page table isolation is not needed on AMD processors
#248At 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…
> We really need to stop shipping software as native blobs and start shipping it as pseudocode, allowing the OS to manage native execution. What we really need to do is to start shipping all software as source code. This is exactly what JavaScript does, and why it is the most successful method of software distribution ever. WebAssembly is a huge step backward.
Most deployed JavaScript isn't source code.
Re: Linux page table isolation is not needed on AMD processors
#249Earlier quoted context omitted.
Sounds like servers handling lots of small UDP packets would be hit pretty hard.
Applications like this where the syscall overhead (and latency) starts to be a significant factor in processing time and latency have moved to userland drivers anyway: DPDK for 10-100 Gbps networking: https://dpdk.org/ SPDK for NVMe storage: http://www.spdk.io/ The queuing and balancing stuff the kernel does makes sense for spinning rust harddisks and residential networking, but when the underlying hardware is so fas…
Taking control over network cards in user space seems doable nowdays. There was a talk about doing such drivers with IOMMU/DMA at CCC: https://media.ccc.de/v/34c3-9159-demystifying_network_cards
Re: Linux page table isolation is not needed on AMD processors
#250Earlier quoted context omitted.
>> 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 resolve…
He said "heavily contended", and then you dropped the "heavily" prefix and claimed that was literally what he said. That adverb is material to the discussion and your dropping it completely changes the meaning. I concur with his opinion. Infrequent contention is not a bug; otherwise no mutex is needed. Frequent contention (or heavy contention in his words) is a performance bug.
> He said "heavily contended", and then you dropped the "heavily" prefix and claimed that was literally what he said. That adverb is material to the discussion and your dropping it completely changes the meaning.
"Heavily" was not dropped intentionally at all. Add it back to my comments. It changes nothing whatsoever. The incredible opinion that every problem can be necessarily parallelized without eventually resulting in contention (and I license you to freely modify this term with 'light', 'heavy', 'medium-rare', 'salted', 'peppered', or 'grilled at 450F' to your taste) is so fantastically absurd that I cannot believe you are debating it. I definitely don't know how you can justify such an unfounded claim with no evidence and I certainly have no interest in wasting time debating it. As I said earlier: if you never encounter problems that exhibit eventual scalability limits, more power to you.