Subject: bounds checking RAW_PART [was: Re: CVS commit: src/sys/dev]
To: Jason R Thorpe <thorpej@wasabisystems.com>
From: Christoph Badura <bad@bsd.de>
List: tech-kern
Date: 01/27/2003 01:15:39
On Thu, Jan 23, 2003 at 03:33:40PM -0800, Jason R Thorpe wrote:
> On Fri, Jan 24, 2003 at 12:00:09AM +0100, Manuel Bouyer wrote:
>  > > bounds_check_with_label() RAW_PART too.
>  > 
>  > I'm not sure it's a really good idea. The idea of RAW_PART is that you can
>  > do what you want, including trying to read beyond the end of the raw partition.
>  > If we really want to do this, is should be checked against the size the disk
>  > reported, not what the disklabel says (which may not be accurate).
> 
> Totally correct -- the bounds_check_with_label() for RAW_PART is wrong.

It has annoyed me for years that RAW_PART isn't bounds checked by certain
drivers on NetBSD.  And I can't find the technical reason for not doing it.
4.4BSD didn't have this feature either.  It seems to me this is some leftover
from the Jolitz days.

No Unix that I've used in the last 20 years has done this and I've never
had a need to read beyond the end of the raw partition.  And if I suddenly
felt that urge, I'd simply change the disklabel to include more sectors.
There's nothing that prevents you from doing that.

Note also that a number of drivers has been bounds checking RAW_PART forever
and nobody seems to complain.

Maybe you can explain to me why it is more important to not be able to
dd image backups off RAW_PART and cause certain disk to lock up hard by
default then to not do so but still be able to do so if you explicitly tell
the driver that you want to?

And what's the idea behind being able to write past the end of a ccd or raid
by default anyway?  To be able to trash multiple file systems with a single
write?  I mean, you know exactly what the useful size of those is.  Why would
you ever want to write beyond the allocated size on those?

I guess I should send a heads-up to current-users, that you now need to run
"disklabel -W $disk" before trashing your disklabel with a write to RAW_PART,
though.

--chris