Will SMAP block drivers from reading a user-mode address?

brad_H

Supervisor Mode Access Prevention (SMAP) is a newer mitigation that has been introduced to complement SMEP and further restrict access from the kernel to user-mode pages – it disallows both reads and writes. Just as SMEP, its status is stored as a bit in the CR4 register

So, does this mean that we should never access a user-mode address directly? But I have already written many drivers that accessed user mode address (for example in the process creation callback to access the PEB of the process, and obviously properly checking if the addresses are correct and putting it in a try catch), and have never got a BSOD from a customer regarding this access?

My questions are:

1. How common is for new hardware to have this SMAP feature? Anyone has experienced any issues with it?

2. If this feature is on, what will happen when I for example try to read a user-mode address from my driver? Will there be a exception that can be catched, or...?

3. If this feature means that we can no longer read a user-mode address, then how can I for example read a user-mode address of a specific process, for example PEB of a target process?

4. Considering that the ntoksrnl itself reads/writes to user-mode addresses as well (duh), then how can It do that with SMAP?! I am even confused about SMEP as well, because I am pretty sure win32k.sys calls user-mode functions directly too, then how the hell can win32k call a user-mode function directly?!

Scott_Noone_(OSR)

AFAIK there's no SMAP on Windows because of the backwards compatibility. There's a brief but interesting paper here:

https://github.com/microsoft/MSRC-Security-Research/blob/master/papers/2020/Evaluating the feasibility of enabling SMAP for the Windows kernel.pdf

It would be nice if the OS started introducing user mode buffer accessor functions (e.g. like copy_to/from_user on Linux). That would pave the way for eventually turning SMAP on.