Closing this revision. FreeBSD is free to pull from HardenedBSD.

Looking at the members of struct proc and struct vmspace I do think I agree that vmspace is a better place for these things.

This update brings the patch current with latest FreeBSD HEAD. No other changes.

In D3565#74326, @kib wrote:

Anything like this patch can only be considered if your 'aslr' implementation is ever found acceptable. Until it is not, the patch only adds bloat.

In D3565#74326, @kib wrote:

Anything like this patch can only be considered if your 'aslr' implementation is ever found acceptable. Until it is not, the patch only adds bloat.

That said, and being whatever trivial, the patch has technical issues. The first and most obvious one is the fact that struct proc is the wrong location for the data you put into it. I argue that the locations of objects in the user address space is the property of the vmspace and not the process.

Second issue is less trivial. Right now, the data which you moved is located in the static (as in, not changing) struct sysentvec. In other words, after you have dereferenced sv = p->p_sysent, you know that you have a pointer to the stable and _consistent_ set of values like address of psstrings, address of signal trampoline, base of the shared page etc. With your patch, this property is lost. Now, you must guarantee that the operations which modify the user address space layout, like execve(), do not happen in parallel. I did not inspected your patch closely for the issue, but neither did you.

And, of course, the patch changes the ABI by making e.g. psstrings/sigtrampoline process-private, instead of all ABI-sharing processes sharing the psstrings/sigtramp value. I am certain that this e.g. breaks core dump analysis due to signal trampoline address change.

Anything like this patch can only be considered if your 'aslr' implementation is ever found acceptable. Until it is not, the patch only adds bloat.