Re: CVS commit: src/sys/uvm

2017-05-19 Thread Kamil Rytarowski 
On 19.05.2017 17:30, Chuck Silvers wrote:
> Module Name:  src
> Committed By: chs
> Date: Fri May 19 15:30:19 UTC 2017
> 
> Modified Files:
>   src/sys/uvm: uvm_map.c uvm_mmap.c
> 
> Log Message:
> make MAP_FIXED mapping operations atomic. fixes PR 52239.
> previously, unmapping any entries being replaced was done separately
> from entering the new mapping, which allowed another thread doing
> a non-MAP_FIXED mapping to allocate the range out from under the
> MAP_FIXED thread.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.346 -r1.347 src/sys/uvm/uvm_map.c
> cvs rdiff -u -r1.164 -r1.165 src/sys/uvm/uvm_mmap.c
> 

UVM broke after this commit. I cannot build packages due to random
memory corruptions. Processes die / files (at least executables) contain
trash.

There are also users on IRC reporting the same behavior.



signature.asc
Description: OpenPGP digital signature

Re: CVS commit: src/sys/uvm

2017-05-19 Thread Christos Zoulas 
In article <20170519162231.ga3...@britannica.bec.de>,
Joerg Sonnenberger   wrote:
>On Fri, May 19, 2017 at 04:14:03PM +, co...@sdf.org wrote:
>> On Fri, May 19, 2017 at 03:30:19PM +, Chuck Silvers wrote:
>> > Module Name:   src
>> > Committed By:  chs
>> > Date:  Fri May 19 15:30:19 UTC 2017
>> > 
>> > Modified Files:
>> >src/sys/uvm: uvm_map.c uvm_mmap.c
>> > 
>> > Log Message:
>> > make MAP_FIXED mapping operations atomic. fixes PR 52239.
>> > previously, unmapping any entries being replaced was done separately
>> > from entering the new mapping, which allowed another thread doing
>> > a non-MAP_FIXED mapping to allocate the range out from under the
>> > MAP_FIXED thread.
>> 
>> Does that have security ramifications?
>
>It's a form of memory corruption under races. We should issue a SN for
>it, but I don't think MAP_FIXED is that popular in general. The case in
>jemalloc is now better served by using mprotect and PROT_MPROTECT, btw.

We should pull it up to -7 at least...

christos

Re: CVS commit: src/sys/uvm

2017-05-19 Thread Joerg Sonnenberger 
On Fri, May 19, 2017 at 04:14:03PM +, co...@sdf.org wrote:
> On Fri, May 19, 2017 at 03:30:19PM +, Chuck Silvers wrote:
> > Module Name:src
> > Committed By:   chs
> > Date:   Fri May 19 15:30:19 UTC 2017
> > 
> > Modified Files:
> > src/sys/uvm: uvm_map.c uvm_mmap.c
> > 
> > Log Message:
> > make MAP_FIXED mapping operations atomic. fixes PR 52239.
> > previously, unmapping any entries being replaced was done separately
> > from entering the new mapping, which allowed another thread doing
> > a non-MAP_FIXED mapping to allocate the range out from under the
> > MAP_FIXED thread.
> 
> Does that have security ramifications?

It's a form of memory corruption under races. We should issue a SN for
it, but I don't think MAP_FIXED is that popular in general. The case in
jemalloc is now better served by using mprotect and PROT_MPROTECT, btw.

Joerg

Re: CVS commit: src/sys/uvm

2017-05-19 Thread coypu 
On Fri, May 19, 2017 at 03:30:19PM +, Chuck Silvers wrote:
> Module Name:  src
> Committed By: chs
> Date: Fri May 19 15:30:19 UTC 2017
> 
> Modified Files:
>   src/sys/uvm: uvm_map.c uvm_mmap.c
> 
> Log Message:
> make MAP_FIXED mapping operations atomic. fixes PR 52239.
> previously, unmapping any entries being replaced was done separately
> from entering the new mapping, which allowed another thread doing
> a non-MAP_FIXED mapping to allocate the range out from under the
> MAP_FIXED thread.

Does that have security ramifications? it sounds like something that
won't be good if not atomic, but I don't know enough to tell if it can
be abused.

Thanks.