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, yamt@NetBSD.org
Subject: Re: kern/35821: /dev/mem is not readable any more
Date: Sun, 25 Feb 2007 19:31:03 +0200

 Martin Husemann wrote:
 > On Sun, Feb 25, 2007 at 06:28:06PM +0200, Elad Efrat wrote:
 >> the problem is that the unmanaged memory access policy was different on
 >> several architectures. since nobody voiced in when the discussions took
 >> place, the decision was to go by the i386 policy on all archs and
 >> restrict access to unmanaged memory to securelevel <= 0. (this is
 >> documented in secmodel_bsd44(9) btw, under securelevel implications)
 > 
 > Yes, I remember that discussion and was not aware that this would
 > affect things like bios dumping.
 
 hence, the first item that should be done and you omitted: understand
 what access to unmanaged memory means.
 
 > I do not want to restart the whole discussion, but for the concrete case
 > at hand:
 > 
 >>   - default-defer in the unified kauth machdep listener at least for
 >>     KAUTH_MACHDEP_UNMANAGEDMEM
 >>   - write per-architecture exclusions, like the one you note above
 > 
 > The former is just a cleaner method to implement the latter?
 
 no. the former is so that unless there's an exception (the latter), the
 request will be denied.
 
 > If this all is considered the "right" and intended behaviour,
 > I'm also fine with adding proper error handling to acpidump (which should
 > be done anyway), and improving the relevant documentation ({p}read(2), maybe
 > secmodel_bsd44(9)).
 
 again, you first need to know what access to unmanaged memory means.
 then you can make smarter decisions about the policy.
 
 how exactly do you want to "improve" documentation? by noting that on
 i386 with bsd44 secmodel and securelevel > 0 you can't dump acpi tables?
 improving would be to document what unmanaged memory means for the
 various supported architectures in kauth(9), and perhaps note in
 intro(2) that various syscalls may be subject to secmodel decisions.
 
 -e.