Subject: Re: new kpi proposal, sysdisk(9)
To: Elad Efrat <>
From: Bill Studenmund <>
List: tech-kern
Date: 12/29/2006 22:15:25
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 30, 2006 at 01:17:21AM +0200, Elad Efrat wrote:
> Bill Studenmund wrote:
> > We already have (or had, I haven't looked recently) code to ensure that=
> > you don't open overlapping partitions. Combined with the whole-disk=20
> > partition, that lets us effectively merge the two (there is something y=
> > open that is the whole disk).
> please take a look at where that code is located (per-arch) and ensure
> it works as advertised. if you manage doing that, for all netbsd ports,
> and then for wedges, you'll have to take care of issues such as
> sending an ioctl to an open "partition" that will apply to the whole
> disk.
> will you look into it and get back to the list with the results?

Wow, do you want me to keep talking with you and working to a solution, or=
to tell you you're an idiot and start yelling? The tone above seems to=20
indicate the latter.

> > The reason you wanted this change (that we would not otherwise know the=
> > are in use) applies equally here too; right now we would have no direct=
> > method to determine they were in use (note I said direct. Yes, you coul=
> > look at swap and RAIDFrame device usage, but that's not the point :-).
> I'm afraid you're wrong here too. the reason I wanted this change is so
> that we can tell that if someone accesses /dev/rwd0b, that while this
> may be the block device for the inactive swap partition, it's really the
> same physical disk as /dev/wd0a, our root fs, and where /etc is.
> I think I made it quite clear when I normalized all devices to be char,
> then compared their major device and DISKUNIT().

You did make that clear. However I don't understand why you want to limit=
access to the whole disk.

Either raw access to the partition is bounded to within the partition or I=
don't understand something. If it's bounded, and the partition doesn't=20
overlap anything, I don't see what the harm is.

I thus don't see why you want this particular protection method.=20
Everything I think you want to prevent _should_ be handled in other ways.

Also, if what I think you want ISN'T handled right now, I think we have=20
MORE problems than just this. Thus your fix will leave other issues open.=

> > Likewise, the fact that part of the above-mentioned disk is open for sw=
> > does not (or should not) preclude a different part of the disk being=20
> > opened for mounting or raid or whatever.
> let me just quote my original mail:
> 	original motivation is raw disk access policy enforcement in
> 	securelevel. currently, only disks that are mounted are denied
> 	raw disk access when the system is 'secure'. devices used for
> 	swap, for example, are not considered mounted even though they
> 	are just as important.
> I thought that was pretty clear, but I'll go further and explain. what
> I want to do is NOT prevent using /dev/wd0b for swap if /dev/wd0a is
> mounted -- that is, in fact, the layout I use, as I said in my example
> in the previous mail -- but rather prevent opening /dev/rwd0b for raw
> writing, that is:
> 	open("/dev/rwd0b", O_RDWR, 0);
> *because* /dev/wd0a is mounted. the reason? see above: we *can't*
> reliably distinguish between the two, and sometimes that is is not even
> something we can do anything about.

I didn't take away the exact meaning you had. My not understanding why you=
want the point you're making lead me to take your meaning to be slightly=20
different (and more sensible in my mind :-).

As above, either we enforce partition boundaries or we don't. If we
enforce boundaries, I don't see the problem with opening disjoint areas.
If we don't enforce boundaries, then we have other problems. For example,=
consider your example but when we booted off of wd1. Thus wd0a isn't=20
mounted. I personally still want something opening rwd0b to not be able to=
touch wd0a, regardless of wd0a's mount state. :-)

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.3 (NetBSD)