Re: + fully-honor-vdso_enabled.patch added to -mm tree

[John Reiser <jreiser@BitWagon.com>]

Chuck Ebbert wrote:
> John Reiser wrote:
> 
>>The value of ->sysenter_return is interpreted in user space by the
>>sysexit instruction; nobody else cares what the value is.  The kernel
>>is not required to provide a good value when vdso_enabled is zero,
>>because the kernel has not told the process that sysenter is valid
>>(by setting AT_SYSINFO.)
> 
> 
> Doesn't matter because a malicious user can still execute sysenter.
> We do have to deal with that somehow, so we have to put something
> safe in there.

All values are safe as far as the kernel is concerned.  The sysexit
instruction is the only consumer of the value.  The sysexit instruction
interprets the value as a _user_ virtual address, and jumps to it,
in _user_ mode.  If user code does not like jumping to a random address
when vdso_enabled is zero, then user code should not use sysenter
when vdso_enabled is zero.  But execution of kernel code is not
affected in any way regardless of the value.

I'd be happy to set ->sysenter_return to 0 (or any other suggested value)
when vdso_enabled is 0, but this would be a politeness only.  There is
no added security risk to the kernel by leaving it unset.

>>Correct.  Changing vdso_enabled from 0 to non-zero must be prepared
>>to lose this race if it is not prevented.  Ordinarily it won't matter
>>because the administrator will perform such changes at a "quiet" time.
>>
> 
> 
> We have to deal with all the possibilities here, too.

Documentation is one method of dealing with it.

-- 
John Reiser, jreiser@BitWagon.com