Robert Millan wrote: > On Fri, Jan 22, 2010 at 07:03:21PM +0100, Vladimir 'φ-coder/phcoder' > Serbinenko wrote: > >>> This can be done by extending "has_partitions" to be set to "yes" in those >>> specific partition types. The implementation should be the least intrusive >>> possible, taking into account that this kind of situations are an oddity >>> rather than the norm. >>> >>> >>> >> Partition types are easily screwed. Why not just check for the presence >> of the label? >> > > I have a feeling I already explained this somewhere. Doesn't seem to be in > this thread, maybe on IRC? Anyway, it won't hurt to ellaborate on it... > > First of all, the whole label type proliferation problem is inherently > impossible to resolve by technical means. Labels overlap each other, > they can coexist without any garantee that the user expects them to be > there at all or include meaningful data. > > You *can't* reliably check for any partition label. Partitions include a > set of arbitrary data. Sometimes they will match one of the probes, > sometimes more than one. GRUB has no way of determining if any of those > matches is correct, because only the *user* knows that. > > This is a problem we already have, but it is bearable because worst case is > detecting a label where there isn't supposed to be one, or detecting a label > type different than the one user expected. With this proposal, two things > happen: > > - has_partitions stops being useful. When in top level, it's relatively > easy to make assumptions about the existance of partitions. If it is > a hard disk, chances are it'll be partitioned; If it's a CDROM, chances > are it isn't (this is an unreliable check, but its purpose is to paliate > the effect of using another unreliable check, so overall it's a gain). > I don't see any illness-effects caused by misdetection. > - False positives can be repeated ad nauseam. It can even be exploited to > force GRUB into reading several GiBs of data, effectively DoSing it. > > You don't need nested partitions for that. You can make multi-GiB with just a single-level GPT, acorn, apple or even msdos (by defining extended label in every sector). Same goes for filesystems: you can make a huge fat root directory and put volume pseudo-file at the end of directory in a way to make *_label inefficient.And if an attacker has access to local disks why not he just replaces grub with hacked version? > If you look around, all approaches at dealing with this imply appliing enough > limit to keep it sane. For example, they limit the number of label types, the > recursion depth, etc. > Often limits are result of static resource allocation. > If we're going to support *all* possible combinations, I'd rather revisit > and solve our detection problem first. Not by actually making detection > reliable (that's impossible), but by stop pretending GRUB can hide this mess > from the user. When GRUB performs guesswork, sooner or later it'll get it > wrong anyway, and the fact that it was guessing creates a false expectation > that it somehow knows the correct result. Users end up blaming GRUB for that. > > So instead of supporting things like: > > (hd0,1) > (hd0,2) > > (ambigous; what does this mean in an hybrid MSDOS/GPT ? What about other > hybrid schemes? GRUB can't tell!) > > ... we could support: > > (hd0,msdos1) > (hd0,gpt1) > (hd0,msdos2) > (hd0,gpt2) > > whose meaning is pretty clear. Then the user can nest as much as they like, > but they will also have to deal with the problem of identifiing the labels. > > I like this idea. It also improves some other cases like hybrid GPT. > Minix: (hd0,msdos1,msdos1) > > Solaris: (hd0,msdos2,sun1) > > *BSD: (hd0,msdos3,bsd1) > > With this approach, the burden is no longer in GRUB. Then I don't care > how weird disk layouts can become, because GRUB doesn't have to probe > them. We still have to for partition_iterate. > We can even support things like this if it makes users happy: > > (hd0,bsd2,msdos1,sun1,apple4,msdos1) > >
-- Regards Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
