The following reply was made to PR port-i386/34186; it has been noted by GNATS.

From: Wolfgang Stukenbrock <Wolfgang.Stukenbrock@nagler-company.com>
To: gnats-bugs@NetBSD.org
Cc: port-i386-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: port-i386/34186: mapping of msgbuf during startup may map invalid physical adresses
Date: Fri, 24 Nov 2006 17:25:02 +0100

 Hi Pavel,
 
 I've looked into the code and you are right!
 
 The line with initmsgbuf() need to be changed too:
 316c316
 <       initmsgbuf((caddr_t)msgbuf_vaddr, round_page(MSGBUFSIZE));
 ---
  >       initmsgbuf((caddr_t)msgbuf_vaddr, sz);
 
 The correct size is calculated in the variable sz during mapping the 
 buffer directly above the call of initmsgbuf(). So that one should be 
 used instead of the constant.
 
 Please add this to the patch. Thanks.
 
 Sorry for the poor quality of my patch. I try to get better next time.
 
 W. Stukenbrock
 
 Pavel Cahyna wrote:
 
 > The following reply was made to PR port-i386/34186; it has been noted by GNATS.
 > 
 > From: Pavel Cahyna <pavel@NetBSD.org>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: port-i386/34186: mapping of msgbuf during startup may map invalid physical adresses
 > Date: Tue, 21 Nov 2006 09:06:54 +0000
 > 
 >  On Fri, Aug 11, 2006 at 02:20:01PM +0000, Wolfgang Stukenbrock wrote:
 >  > 	The function cpu_startup() will determine the size of the message buffer from the
 >  > 	segment list and will map the allocated pages to the allocated virtual adressspace
 >  > 	with the size determined from the segment list.
 >  
 >  You say that cpu_startup will determine the size of the message buffer,
 >  but in your patch it continues to call initmsgbuf() with the hardwired
 >  size (MSGBUFSIZE):
 >  
 >  (...)
 >  > ! 			    msgbuf_p_seg[y].paddr + x * PAGE_SIZE, VM_PROT_READ|VM_PROT_WRITE);
 >  > ! 	}
 >  >   	pmap_update(pmap_kernel());
 >  >   
 >  >   	initmsgbuf((caddr_t)msgbuf_vaddr, round_page(MSGBUFSIZE));
 >  > ***************
 >  
 >  how do you prevent using incorrect size and accessing unmapped memory if
 >  two segments aren't enough?
 >  
 >  Pavel
 >  
 >