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.