On Sat, Nov 13, 2021 at 03:37:24PM -0500, David Malcolm wrote: > This approach is much less expressive that the custom addres space > approach; it would only cover the trust boundary aspect; it wouldn't > cover any differences between generic pointers and __user, vs __iomem, > __percpu, and __rcu which I admit I only dimly understand.
__iomem would point at device memory, which can have curious side effects or is yet another trust boundary, depending on device and usage. __percpu is an address space that denotes a per-cpu variable's relative offset, it needs be combined with a per-cpu offset to get a 'real' pointer, on x86_64 %gs segment offset is used for this purpose, other architectures are less fortunate. The whole per_cpu()/this_cpu_*() family of APIs accepts such pointers. __rcu is the regular kernel address space, but denotes that the object pointed to has RCU lifetime management. The attribute is laundered through rcu_dereference() to remove the __rcu qualifier. > Possibly silly question: is it always a bug for the value of a kernel > pointer to leak into user space? i.e. should I be complaining about an > infoleak if the value of a trusted_ptr itself is written to > *untrusted_ptr? e.g. Yes, always. Leaking kernel pointers is unconditionally bad.
