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 18:28:06 +0200

 Martin Husemann wrote:
 > On Sun, Feb 25, 2007 at 05:48:31PM +0200, Elad Efrat wrote:
 >> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/i386/i386/mem.c#rev1.62
 > 
 > Heh!
 > 
 > Should we make the 0xE0000 - 0xFFFFF area a "known address" for read-only
 > accesses?
 > 
 > Martin
 
 I don't think it is that simple.
 
 this was discussed twice with close to zero participation on tech-kern@;
 might even be three times if you include the time it was discussed in
 the context of unifying the kauth machdep scope.
 
 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)
 
 retroactively we find out that the i386 policy we went by may have been
 incorrect from the day it was introduced over a year ago. the reason for
 this, I'm guessing, is that -- if to judge by the aforementioned
 discussions -- there's no clear understanding of what exactly "unmanaged
 memory" means on all of the supported architectures.
 
 there is still an inconsistency in the unmanaged memory access today,
 only that it is not in the policy itself but rather on whether it exists
 or not: if it does, there's a KAUTH_MACHDEP_UNMANAGEDMEM request, if it
 doesn't, there isn't. the suggested steps would be to:
 
   - understand what unmanaged memory access *means* on all architectures
   - add KAUTH_MACHDEP_UNMANAGEDMEM requests where they're missing
   - default-defer in the unified kauth machdep listener at least for
     KAUTH_MACHDEP_UNMANAGEDMEM
   - write per-architecture exclusions, like the one you note above
 
 -e.