Historical context:
"The mysterious case of the Linux Page Table Isolation patches"
Initial Performance Benchmarks of Linux's x86 Security Changes
11–20 of 25 posts
Re: Initial Performance Benchmarks of Linux's x86 Security Changes
#12Re: Initial Performance Benchmarks of Linux's x86 Security Changes
#13It is interesting to see how posts and comments are written in a way that so far hides or downplays the severity and owner of this flaw.
Re: Initial Performance Benchmarks of Linux's x86 Security Changes
#14Is it possible to sue Intel if you need ~30% more web servers because Intel built faulty processors? The argument would be that you had bought AMD if you had known about the flaw.
Re: Initial Performance Benchmarks of Linux's x86 Security Changes
#15It is interesting to see how posts and comments are written in a way that so far hides or downplays the severity and owner of this flaw.
The RAM manufacturers, for building their circuits too small? Or Intel, for allowing a side-channel attack to exist? Or Linux, for assuming that randomizing some pointers would mitigate any side-channel? This bug is definitely a product of lots of different issues coming together.
Re: Initial Performance Benchmarks of Linux's x86 Security Changes
#16Is it possible to sue Intel if you need ~30% more web servers because Intel built faulty processors? The argument would be that you had bought AMD if you had known about the flaw.
[deleted]
Re: Initial Performance Benchmarks of Linux's x86 Security Changes
#17Earlier quoted context omitted.
That might improve single core performance. But you lock up two entire cores doing so. For multi-core workloads, performance obviously decreases, mostly because you are missing an entire CPU core. Also, you would introduce locking between cores as only one user core could call the kernel at any one time. Additionally, we have no idea how this bug (whatever it is) interacts with hyperthreading.
It's quite common on HPC systems to schedule jobs on every logical CPU except cpu0, and give the OS cpu0 for doing OS stuff. In many workloads it actually improves performance since your job is not stalled waiting for something on cpu0, which was preempted for executing OS tasks.
HPC systems also tend do an unusual amount of stuff in userspace, such as running custom TCP stacks in userspace or using RDMA to bypass the CPU entirely. You wouldn't want to run a 10GB+ multiqueue Ethernet NIC on a single core, it'll choke on the interrupt load.
Re: Initial Performance Benchmarks of Linux's x86 Security Changes
#18With what is known about this bug so far, wouldn't it be possible to mitigate it by locking the kernel to one CPU core, and run user processes on the other cores? Also, if this bug lets the kernel leak data to user processes, would it also not be the case that different processes would leak data to each other? If that is true, then it seems that just isolating the kernel wouldn't be enough.
So if my app is running on core 1 and makes a syscall, the entire state must be shifted to the kernel core? That seems slower than swapping the memory maps.
Re: Initial Performance Benchmarks of Linux's x86 Security Changes
#19These cache vulnerabilities can probably be mitigated with lower performance penalties on CPUs with Intel CAT. It's only available on Intel's Xeon SKUs though.
Re: Initial Performance Benchmarks of Linux's x86 Security Changes
#20With what is known about this bug so far, wouldn't it be possible to mitigate it by locking the kernel to one CPU core, and run user processes on the other cores? Also, if this bug lets the kernel leak data to user processes, would it also not be the case that different processes would leak data to each other? If that is true, then it seems that just isolating the kernel wouldn't be enough.
wouldn't it be possible to mitigate it by locking the kernel to one CPU core, and run user processes on the other cores?
That would be a much, much more invasive architectural change - and it would perform much worse than the page table isolation fixes.
Also, if this bug lets the kernel leak data to user processes, would it also not be the case that different processes would leak data to each other?
No. The problem is with pages that are mapped, but (supposed to be) inaccessible from your current privilege level. The user mappings of other processes aren't in your page tables at all.