Re: try KMGUARD

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Thu, Mar 08, 2012 at 12:49:16PM +0100, Manuel Bouyer wrote:
> On Thu, Mar 08, 2012 at 12:34:08PM +0100, Manuel Bouyer wrote:
> > > Are you able to try to reproduce on a real hardware?  Resource usage by
> > > KMGUARD is very severe.  It might not even boot with 128 MB.
> > 
> > I tried on a amd64 host with 8GB RAM (looks like I expanded the i386 
> > tests.tgz
> > instead of amd64 but it shouldn't matter). I got a panic while running the
> > stress_long test, but not from kmemguard unforntunably:
> 
> And another one:
> login: uvm_fault(0xffffffff80e7c960, 0xffff800015787000, 1) -> e
> fatal page fault in supervisor mode
> trap type 6 code 0 rip ffffffff80113f8e cs 8 rflags 10206 cr2  
> ffff800015787000 cpl 0 rsp fffffe810c72fa28
> kernel: page fault trap, code=0
> Stopped in pid 1063.4 (h_reconcli) at   netbsd:copystr+0xe:     lodsb   (%rsi)
> db{6}> tr
> copystr() at netbsd:copystr+0xe
> unp_connect() at netbsd:unp_connect+0x90

copystr() is in fact probably called from pathbuf_create(), called from
unp_connect() at kern/uipc_usrreq.c:1004. It traps when reading the
source string; which comes from a malloc() a few lines above.
unp_connect() explicitely NUL-terminates the source string; if the
data source was corrupted at this point (e.g. nam->m_len is wrong and very
large), it would have faulted in m_copydata().

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--