Re: panic: UBSan: Undefined Behavior in /syzkaller/managers/netbsd-kubsan/kernel/sys/kern/kern_rndq.c:LINE, negation of -ADD

2019-09-25 Thread Kamil Rytarowski
Is this patch correct?

http://netbsd.org/~kamil/patch-00168-kern_rndq.c-avoid-overflow.txt

This code will map the corner case into defined semantics, treating
delta INT32_MIN as INT32_MIN+1.

This panic was already triggered 7 times on syzbot.

On 23.09.2019 10:56, Kamil Rytarowski wrote:
> Truncating and resending to tech-kern@ as this message was dropped, as
> too long.
> 
> On 23.09.2019 10:19, Kamil Rytarowski wrote:
>> kern_rndq.c has a special corner case triggered by the fuzzer (1 hit in
>> 2**32 attempts?).
>>
>> 393 /*
>> 394  * Delta estimator for 32 or bit values.  "Wrap" isn't.
>> 395  */
>> 396 static inline uint32_t
>> 397 rnd_dv_estimate(krndsource_t *rs, uint32_t v)
>> 398 {
>> 399  int32_t delta;
>> 400  uint32_t ret;
>> 401  rnd_delta_t *d = >value_delta;
>> 402
>> 403  delta = d->x - v;
>> 404
>>
>> delta can be here INT32_MIN.
>>
>>
>> 405  if (delta < 0) {
>> 406  delta = -delta;
>>
>> -INT32_MIN is UB and returns -INT32_MIN on currently supported CPUs.
>>
>> But this behavior is unspecified and should be avoided. This triggered
>> the kUBSan panic on the bot however:
>>
>> 407  }
>> 408  ret = rnd_delta_estimate(d, v, (uint32_t)delta);
>>
>> d->dx is assigned (uint32_t)delta to INT32_MAX+1
>>
>> 409
>> 410  KASSERT(d->x == v);
>> 411  KASSERT(d->dx == delta);
>>
>> d->dx is INT32_MAX (0x8000) and as far as I can see we would trigger
>> a panic for this corner-case anyway as this KASSERT(9) will fire for
>> comparing 0x8000 with 0x8000 (promotion rules).
>>
>> https://nxr.netbsd.org/xref/src/sys/kern/kern_rndq.c#397
>>
>> There is a similar code in rnd_dt_estimate() that probably should be
>> handled, at least for paranoid reasons.
>>
>> 359 /*
>> 360  * Delta estimator for 32-bit timeestamps.  Must handle wrap.
>> 361  */
>> 362 static inline uint32_t
>> 363 rnd_dt_estimate(krndsource_t *rs, uint32_t t)
>> 364 {
>> 365  int32_t delta;
>> 366  uint32_t ret;
>> 367  rnd_delta_t *d = >time_delta;
>> 368
>> 369  if (t < d->x) {
>> 370  delta = UINT32_MAX - d->x + t;
>> 371  } else {
>> 372  delta = d->x - t;
>> 373  }
>> 374
>> 375  if (delta < 0) {
>> 376  delta = -delta;
>> 377  }
>> 378
>> 379  ret = rnd_delta_estimate(d, t, delta);
>> 380
>> 381  KASSERT(d->x == t);
>> 382  KASSERT(d->dx == delta);
>>
>> https://nxr.netbsd.org/xref/src/sys/kern/kern_rndq.c#363
>>
>>
>> On 22.09.2019 07:14, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit:    147eb8ed improve description
>>> git tree:   netbsd
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=17c2b55560
>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=824b23e1f4b6c76b
>>> dashboard link:
>>> https://syzkaller.appspot.com/bug?extid=68c37d09c833f8ec1341
>>>
>>> Unfortunately, I don't have any reproducer for this crash yet.
>>>
>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>> Reported-by: syzbot+68c37d09c833f8ec1...@syzkaller.appspotmail.com
>>>
>>> [  64.2934242] panic: UBSan: Undefined Behavior in
>>> /syzkaller/managers/netbsd-kubsan/kernel/sys/kern/kern_rndq.c:406:9,
>>> negation of -2147483648 cannot be represented in type 'int'
>>>
>>> [  64.3096778] cpu0: Begin traceback...
>>> [  64.3234784] vpanic() at netbsd:vpanic+0x258 sys/kern/subr_prf.c:336
>>> [  64.3535415] isAlreadyReported() at netbsd:isAlreadyReported
>>> [  64.3836129] HandleNegateOverflow() at
>>> netbsd:HandleNegateOverflow+0xff sys/../common/lib/libc/misc/ubsan.c:372
>>> [  64.4136750] _rnd_add_uint32() at netbsd:_rnd_add_uint32+0x5a5
>>> rnd_dv_estimate sys/kern/kern_rndq.c:406 [inline]
>>> [  64.4136750] _rnd_add_uint32() at netbsd:_rnd_add_uint32+0x5a5
>>> rnd_estimate sys/kern/kern_rndq.c:836 [inline]
>>> [  64.4136750] _rnd_add_uint32() at netbsd:_rnd_add_uint32+0x5a5
>>> sys/kern/kern_rndq.c:873
>>> [  64.4437455] uvm_fault_internal() at netbsd:uvm_fault_internal+0x154f
>>> rnd_add_uint32 sys/sys/rndsource.h:103 [inline]
>>> [  64.4437455] uvm_fault_internal() at netbsd:uvm_fault_internal+0x154f
>>> sys/uvm/uvm_fault.c:848
>>> [  64.4637869] trap() at netbsd:trap+0xbf9 sys/arch/amd64/amd64/trap.c:538
>>> [  64.4738073] --- trap (number 6) ---
>>> [  64.4838301] 7c382e9914c1:
>>> [  64.4838301] cpu0: End traceback...
>>> [  64.4838301] fatal breakpoint trap in supervisor mode
>>> [  64.4952445] trap type 1 code 0 rip 0x8021ddad cs 0x8 rflags
>>> 0x282 cr2 0x7c382f73a018 ilevel 0 rsp 0x8180acb38690
>>> [  64.5082606] curlwp 0xd6820e6eb300 pid 1909.1 lowest kstack
>>> 0x8180acb352c0
>>> Stopped in pid 1909.1 (sh) at   netbsd:breakpoint+0x5:  leave
> 
> 
> 
> 




signature.asc
Description: OpenPGP digital signature


re: reducing the use of M_NOWAIT / KM_NOSLEEP memory allocations

2019-09-25 Thread matthew green
> Does anyone have any comments on this plan?

yes, please.


.mrg.


reducing the use of M_NOWAIT / KM_NOSLEEP memory allocations

2019-09-25 Thread Chuck Silvers
hi folks,

I'd like to convert more of the M_NOWAIT / KM_NOSLEEP memory allocations to
M_WAITOK / KM_SLEEP.  Use of the nowait variety should be avoided wherever
possible because it causes operations to fail randomly just because the
system happens to be low on memory at the time.

We currently use the nowait variety for most allocations done in device attach
methods, which I believe is due to the notion that we don't want to hang
if we run out of memory at boot time before the pagedaemon thread has been
created.  However, if this situation does arise, failing to attach the
rest of the devices is very likely to result in an unusable system anyway,
so this doesn't seem all that useful.  Furthermore, these days many devices
can be attached later after the system is fully up, so using nowait allocations
is undesirable in this context.

What I'm planning to do instead of using nowait allocations in device attach
is to have uvm_wait() just panic if it is called before the pagedaemon thread
has been created.  This will avoid any hang due to running out of memory
during system startup.

Then we can gradually change all of the memory allocations in device
attach methods to be wait/sleep instead and remove all the checks for
allocation failures from these calls.  Wait/sleep allocations will
wait forever and thus they never return failure.

Does anyone have any comments on this plan?

-Chuck


Re: x86 bootstrap features

2019-09-25 Thread Michael van Elst
On Wed, Sep 25, 2019 at 02:53:44PM +0300, Andreas Gustafsson wrote:
> Michael van Elst wrote:
> > This assumes that code and data segment is the same and assigns
> > the following 64k block to the stack. We switch to protected
> > mode soon after, but the memory layout seems to stay the same.
> > Maybe changing to
> > 
> > addw$0x2001, %ax
> > 
> > is all that is needed.
> 
> I guess we also need to bump these definitions in the Makefile?
> 
>   SAMISCCPPFLAGS+= -DHEAP_START=0x1 -DHEAP_LIMIT=0x3

That even looks wrong now. The start address aligns with the
stack area so that heap and stack grow into each other, but the
limit is beyond the stack top.


But

revision 1.6
date: 2011-03-18 18:46:26 +0100;  author: jakllsch;  state: Exp;  lines: +8 -6;
Automatically adjust pxeboot(8) stack based on the end of .bss, like is
already done in biosboot.S for boot(8).
(The heap location will need to be adjusted if pxeboot expands much more.)

confirms that the heap needs to be adjusted too. :)


Greetings,
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."


Re: x86 bootstrap features

2019-09-25 Thread Andreas Gustafsson
Michael van Elst wrote:
> This assumes that code and data segment is the same and assigns
> the following 64k block to the stack. We switch to protected
> mode soon after, but the memory layout seems to stay the same.
> Maybe changing to
> 
>   addw$0x2001, %ax
> 
> is all that is needed.

I guess we also need to bump these definitions in the Makefile?

  SAMISCCPPFLAGS+= -DHEAP_START=0x1 -DHEAP_LIMIT=0x3

-- 
Andreas Gustafsson, g...@gson.org