5 ms·

Page size impacts page permissions; it's not a matter of wasting 12k, it's that with 4kb pages you're allowed to have a consecutive 8kb region with different pe

Page size impacts page permissions; it's not a matter of wasting 12k, it's that with 4kb pages you're allowed to have a consecutive 8kb region with different permissions. 16kb pages can't do that without segfaulting every time memory is used "wrong", and trying to fix that up transparently would be a nightmare.

yjftsjthsd-h 1y ago
> 16kb pages can't do that without segfaulting every time memory is used "wrong", and trying to fix that up transparently would be a nightmare. I would natively imagine the kernel could trap that and remap on the fly, at the tiny cost of murdering performance. Is that untrue, or is the perf so bad that it's not worth it?
- plorkyeran 1y ago
  Anything which involves the kernel tracking permissions at 4k granularity despite using larger pages is just going to be worse in every way than using 4k pages.
- dwattttt 1y ago
  It depends on how much of a program actually triggers the failure case, so you can't answer in the abstract. In the worst case, ~every memory access causes the kernel to need to fix it, causing every memory access to be several orders of magnitude worse (e.g. a hot cache hit vs trapping into kernel, wiping caches, at the very least hundreds more accesses). EDIT: I see you suggested remapping the page permissions. Maybe that helps! But maybe it adds the cost of the remapping onto the worst case, e.g. the first 4kb are instructions that write into the second 4kb.
bjourne 1y ago
That's a valid point, but isn't memory protection the only common user-visible effect of changed page sizes? It would seem most apps which do not use write-protected memory would be unaffected.
- dwattttt 1y ago
  I think the most immediate problem would be ELF segments that aren't 16kb aligned. Code will abut data, you can't add a gap without breaking offsets inside the ELF, and you'll induce the segfault during every write to a global at the start of the writable code, or executing code at the end of the code segment. A less safe option would be for permissions to be a union in that region, as code rarely depends on a permission being absent. That would be quite the security hole though.

yjftsjthsd-h 1y ago

> 16kb pages can't do that without segfaulting every time memory is used "wrong", and trying to fix that up transparently would be a nightmare. I would natively imagine the kernel could trap that and remap on the fly, at the tiny cost of murdering performance. Is that untrue, or is the perf so bad that it's not worth it?

plorkyeran 1y ago
Anything which involves the kernel tracking permissions at 4k granularity despite using larger pages is just going to be worse in every way than using 4k pages.
dwattttt 1y ago
It depends on how much of a program actually triggers the failure case, so you can't answer in the abstract. In the worst case, ~every memory access causes the kernel to need to fix it, causing every memory access to be several orders of magnitude worse (e.g. a hot cache hit vs trapping into kernel, wiping caches, at the very least hundreds more accesses). EDIT: I see you suggested remapping the page permissions. Maybe that helps! But maybe it adds the cost of the remapping onto the worst case, e.g. the first 4kb are instructions that write into the second 4kb.

bjourne 1y ago

That's a valid point, but isn't memory protection the only common user-visible effect of changed page sizes? It would seem most apps which do not use write-protected memory would be unaffected.

dwattttt 1y ago
I think the most immediate problem would be ELF segments that aren't 16kb aligned. Code will abut data, you can't add a gap without breaking offsets inside the ELF, and you'll induce the segfault during every write to a global at the start of the writable code, or executing code at the end of the code segment. A less safe option would be for permissions to be a union in that region, as code rarely depends on a permission being absent. That would be quite the security hole though.