Subject: Re: kern/35821: /dev/mem is not readable any more
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Elad Efrat <elad@bsd.org.il>
List: netbsd-bugs
Date: 02/25/2007 19:05:06
The following reply was made to PR kern/35821; it has been noted by GNATS.

From: Elad Efrat <elad@bsd.org.il>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/35821: /dev/mem is not readable any more
Date: Sun, 25 Feb 2007 20:55:42 +0200

 Martin Husemann wrote:
 > On Sun, Feb 25, 2007 at 05:35:02PM +0000, Elad Efrat wrote:
 >>  again, you first need to know what access to unmanaged memory means.
 >>  then you can make smarter decisions about the policy.
 > 
 > I do not understand what you exactly mean here - we certainly do understand
 > what on i386 access to the BIOS address range means.
 
 access to unmanaged memory is a machdep scope action. if you understand
 what it means on i386, you understand 1/17 (or whatever) of the problem.
 
 >>  how exactly do you want to "improve" documentation?
 > 
 > Simple: in acpidump(8) note that it requires securelevel <= 0,
 > and in {p}read(2) note that EPERM might be returned and why.
 > 
 > Martin
 
 securelevel is a concept that exists, for now, only in the bsd44
 secmodel. also, this means that in the future, when someone notices
 something else that "broke" by this policy decision, possibly for
 a different architecture, you will again have to do such modifications.
 
 that's why I suggested to first consult the port-masters and
 understand what are the implications of unmanaged memory access for
 each of the supported architectures, and documenting them with the
 KAUTH_MACHDEP_UNMANAGEDMEM action in kauth(9)...
 
 -e.