Re: [PATCH] nested partitions

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4260 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]