Subject: Re: disklabel(8) and machdep on-disk structures issues
To: <>
From: David Laight <>
List: tech-kern
Date: 10/31/2003 09:22:37
On Fri, Oct 31, 2003 at 12:12:03PM +1100, Luke Mewburn wrote:
> On Thu, Oct 30, 2003 at 07:41:01PM -0500, Thor Lancelot Simon wrote:
>   | On Fri, Oct 31, 2003 at 12:25:07AM +0000, David Laight wrote:
>   | > 
>   | > I think that disklabel(8) ought to be able to write the label in all
>   | > formats on any format without requiring any kernel code.  It should
>   | > probably overwrite any old label by default as well.
>   | > Then the kernel can be changed to play 'hunt the disklabel' for reading
>   | > and have the code that writes labels removed entirely.
>   | > (The 'write label' code would need to be in (say) libutil, so other
>   | > programs can use it.)
>   | 
>   | I'm concerned that removing all knowledge of the disklabel structure from
>   | the kernel will ultimately result in a situation in which it's impossible
>   | to enforce the restrictions on partition access used to protect the TCB
>   | when running at securelevel > 0.  

What disklabel changes are actually allowed when securelevel > 0?
I would have thought you'd want the label (actually probably the boot sectors)
to be unwritable - with the possible exception of the'userdata' (ie blk/frag
size) field.

>   | In fact, I tend to think that _all_ disklabel access should be mediated by
>   | the kernel, using a suitably abstracted interface, and that access to the 
>   | label sectors should be explicitly forbidden to all userland programs.  I
>   | have seen various proposals for alternate schemes but I have never seen
>   | one (the present scheme included) which protects the integrity of the
>   | partitioning information even against a rogue process operating with root
>   | privileges -- and if you can't trust the partitioning information, the
>   | rest of the integrity guarantees are pretty much shot to hell as well.
> Part of the problem is that DIOCWDINFO (update in-core, then update raw)
> _fails_ if there isn't an existing raw label.  So disklabel(8) -r has to
> be used to create the raw label.  Which in itself is fraught with
> difficulties (due to obscure inconsistencies between how disklabel -r -I
> and disklabel -r -R operate).  Thus, if you're doing work with disks
> from C, the best thing to do at this time is to make the label writable
> with DIOCWLABEL, and pread()/pwrite() the labelsector yourself...

And then you fail to update all the copies of the label, or fail to use
the correct MD layout etc.

> That all said, if DIOCWDINFO was change to _not_ fail if there's
> no existing raw label and just write it anyway (my preferred,
> unless there's security/integrity ramifications I am not aware of),
> or we added a new ioctl to create the raw label, then things would
> be much better.  In either case, a chunk of disklabel(8) could
> be simplified and it would makes third party manipulation of disklabels
> from C programs more robust.

I'd certainly vote for separating the disklabel read/write code out
of disklabel and into (say) libutil where other programs (eg sysinst,
newfs) can use it.

The first part is to evict all the bootcode stuff from disklabel.
(I've a version that still seems to work without it)


David Laight: