Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR

[Dave Hansen]

On 01/05/2017 01:27 PM, Andy Lutomirski wrote:
> On Thu, Jan 5, 2017 at 12:49 PM, Dave Hansen <dave.hansen@xxxxxxxxx> wrote:
...
>> Remember, we already have (legacy MPX) binaries in the wild that have no
>> knowledge of this stuff.  So, we can implicitly have the kernel bump
>> this rlimit around, but we can't expect userspace to do it, ever.
> 
> If you s/rlimit/prctl, then I think this all makes sense with one
> exception.  It would be a bit sad if the personality-setting tool
> didn't work if compiled with MPX.

Ahh, because if you have MPX enabled you *can't* sanely switch between
the two modes because you suddenly go from having small bounds tables to
having big ones?

It's not the simplest thing in the world to do, but there's nothing
keeping the personality-setting tool from doing all the work.  It can do:

	new_bd = malloc(1TB);
	prctl(MPX_DISABLE_MANAGEMENT);
	memcpy(new_bd, old_bd, LEGACY_MPX_BD_SIZE);
	set_bounds_config(new_bd | ENABLE_BIT);
	prctl(WIDER_VADDR_WIDTH);
	prctl(MPX_ENABLE_MANAGEMENT);
	

> So what if we had a second prctl field that is the value that kicks in
> after execve()?

Yeah, that's a pretty sane way to do it too.  execve() is a nice chokepoint.