Hacker News Reader

Comment by oliwarner | Hacker News Reader

As a billion other people have already said, that all depends on their workloads. This isn't a 30% clockspeed deduction.

View on HN

As i understand the problem, this isn't about clockspeed reduction, now it is the software's responsibility to check if the page is a kernel page/user page. So, the impact is significant. So, every time either pages are touched/accessed this check needs to be triggered, which causes it to be much slower.

> So, every time either pages are touched/accessed this check needs to be triggered, which causes it to be much slower.

Not to be mean, but that's not what is being changed.

You're right on the bug - userlevel code can now read any memory regardless of privilege level. However the fix isn't to manually check the privileges on each access - that would be extremely slow and wouldn't actually fix the problem.

The fix is to unmap the kernel entirely when userspace code is running. Because the kernel will no longer be in the page-table, the userspace code can no longer read it. The side-effect of this is that the page-table now needs to be switched every-time you enter the kernel, which also flushes the TLB and means that there will be a lot more TLB misses when executing code, which slows things down a lot.

So, to be clear, it is not accessing pages that is being slowed down, it is the switch from the kernelspace to the userspace.

But doesn't the CPU enter kernelspace every time a syscall takes place? So based on what you've described, every time a syscall returns control back to userspace, the TLB will be flushed, which means slower page access times in general.

The distinction I was trying to make was the above commenters thinking that the kernel is now checking page permissions instead of the CPU doing it - IE. Doing privileged checks in software. That's not what's happening, the kernel is just unmapping itself when usercode is run so the kernel can't be seen at all. Then the privileged checks (which are now broken) don't matter because there is no kernel memory to read.

All your points are right though. Page access times will in general be slower because of all the extra TLB flushes, leading to more TLB misses when accessing memory.

Right, but how often that happens is workload dependent. Basically, how often is your code making syscalls.

> how often is your code making syscalls.

And how often the kernel services interrupts.

But don't all FS accesses (e.g., write to socket, read from DB) require a syscall? In that case, basically all web applications would be affected.

Or am I completely off the mark?

No, you are correct. Really, every application will be affected, they all make some syscalls. How much will vary, though.

At least one syscall happens at some point, but performance-tuned systems already use "bulk" syscalls where a single syscall can send megabytes of data, check thousands of sockets, or map a whole file into your address space to access as if it were memory.

You don't understand the problem.

Reply on news.ycombinator.com