3 ms·

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,

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.

DSMan195276 9y ago
> 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.
- Cyph0n 9y ago
  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.
  - DSMan195276 9y ago
    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.
cortesoft 9y ago
Right, but how often that happens is workload dependent. Basically, how often is your code making syscalls.
- vidoc 9y ago
  > how often is your code making syscalls. And how often the kernel services interrupts.
- Cyph0n 9y ago
  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?
  - cortesoft 9y ago
    No, you are correct. Really, every application will be affected, they all make some syscalls. How much will vary, though.
  - lmm 9y ago
    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.
moonbug22 9y ago
You don't understand the problem.

DSMan195276 9y ago

> 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.

Cyph0n 9y ago
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.
- DSMan195276 9y ago
  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.

cortesoft 9y ago

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

vidoc 9y ago
> how often is your code making syscalls. And how often the kernel services interrupts.
Cyph0n 9y ago
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?
- cortesoft 9y ago
  No, you are correct. Really, every application will be affected, they all make some syscalls. How much will vary, though.
- lmm 9y ago
  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.

moonbug22 9y ago

You don't understand the problem.