[dwattttt]

Sure, but only by either changing the page permissions on the page that virtual address is on, or by remapping it elsewhere as writable; both of those are heavy handed operations, and neither would be in the "report the result of an IO operation" path.

x86 page table entries can't express "user read only, kernel read/write"

[jcalvinowens]

The user mapping may be read only, but the kernel will likely use other writable mappings to the same page.

Linux for example maintains a big writable linear mapping of all RAM at all times (on 64-bit), you can corrupt read-only user pages through it all day and never fault. Code running in the kernel generlly uses virtual addresses from that mapping.

[dwattttt]

By policy, asking the Windows kernel to write to an address happens within an SEH try/catch, and a failure will result in the kernel returning an error code.

The kernel has no reason to be trying to bypass page protections; what if you asked it to write to a shared read-only page?

[jcalvinowens]

Most kernel code will be dealing with a different set of virtual addresses, which map the entire address space read/write. Those addresses necessarily alias the physical pages backing any userspace mapping, and thus allow corrupting them e.g. via buffer overflows beyond page boundaries.

The try-catch dance you're describing is only necessary for accessing the userspace mapping (because it might fault). Kernel code which dereferences kernel pointers doesn't do that.

Pages don't get remapped into userspace: userspace gets an additional aliased mapping with restricted permissions. The kernel's writable mapping still exists. There's nothing to "bypass", what permissions userspace applies its user mapping of the same physical page has no effect on the kernel mapping.

[dwattttt]

I fear we may have gotten away from the Windows kernel writing an output value asynchronously to a user space address on IO completion.