Page MenuHomeFreeBSD

HardenedBSDUmbrella
ActivePublic

Recent Activity

Jun 13 2018

dab added a watcher for HardenedBSD: dab.
Jun 13 2018, 5:49 PM

Feb 7 2016

mmokhi added a watcher for HardenedBSD: mmokhi.
Feb 7 2016, 9:23 AM

Dec 19 2015

lattera-gmail.com abandoned D3565: Per-Process PS_STRINGS, USRSTACK, shared_object_base, and sigcode_base.

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

Dec 19 2015, 6:49 PM · HardenedBSD

Nov 5 2015

kib added inline comments to D3565: Per-Process PS_STRINGS, USRSTACK, shared_object_base, and sigcode_base.
Nov 5 2015, 1:53 PM · HardenedBSD
brooks added a comment to D3565: Per-Process PS_STRINGS, USRSTACK, shared_object_base, and sigcode_base.

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

Nov 5 2015, 12:42 PM · HardenedBSD

Oct 31 2015

lattera-gmail.com updated the diff for D3565: Per-Process PS_STRINGS, USRSTACK, shared_object_base, and sigcode_base.

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

Oct 31 2015, 5:37 PM · HardenedBSD

Sep 21 2015

op added a comment to D3565: Per-Process PS_STRINGS, USRSTACK, shared_object_base, and sigcode_base.
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.

Sep 21 2015, 12:15 PM · HardenedBSD
op added a reviewer for D3565: Per-Process PS_STRINGS, USRSTACK, shared_object_base, and sigcode_base: adrian.
Sep 21 2015, 11:26 AM · HardenedBSD

Sep 8 2015

lattera-gmail.com added a comment to D3565: Per-Process PS_STRINGS, USRSTACK, shared_object_base, and sigcode_base.
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.

Sep 8 2015, 10:02 PM · HardenedBSD
kib added a comment to D3565: Per-Process PS_STRINGS, USRSTACK, shared_object_base, and sigcode_base.

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.

Sep 8 2015, 10:36 AM · HardenedBSD

Sep 7 2015

lattera-gmail.com updated subscribers of D3565: Per-Process PS_STRINGS, USRSTACK, shared_object_base, and sigcode_base.
Sep 7 2015, 8:45 PM · HardenedBSD

Sep 4 2015

lattera-gmail.com retitled D3565: Per-Process PS_STRINGS, USRSTACK, shared_object_base, and sigcode_base from to Per-Process PS_STRINGS, USRSTACK, shared_object_base, and sigcode_base.
Sep 4 2015, 12:05 AM · HardenedBSD

Jun 25 2015

lattera-gmail.com added a member for HardenedBSD: lattera-gmail.com.
Jun 25 2015, 11:39 AM
op added a member for HardenedBSD: op.
Jun 25 2015, 2:00 AM

May 30 2015

eadler set the icon for HardenedBSD to fa-umbrella.
May 30 2015, 6:04 PM
eadler created HardenedBSD.
May 30 2015, 5:59 PM