[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] nested partitions
From: |
Vladimir 'φ-coder/phcoder' Serbinenko |
Subject: |
Re: [PATCH] nested partitions |
Date: |
Sun, 24 Jan 2010 22:20:49 +0100 |
User-agent: |
Mozilla-Thunderbird 2.0.0.22 (X11/20091109) |
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
- Re: [PATCH] nested partitions, Robert Millan, 2010/01/22
- Re: [PATCH] nested partitions, Vladimir 'φ-coder/phcoder' Serbinenko, 2010/01/22
- Re: [PATCH] nested partitions, Robert Millan, 2010/01/24
- Re: [PATCH] nested partitions, Bruce Dubbs, 2010/01/24
- Re: [PATCH] nested partitions, Michal Suchanek, 2010/01/24
- Re: [PATCH] nested partitions, Robert Millan, 2010/01/25
- Re: [PATCH] nested partitions, Robert Millan, 2010/01/25
- Re: [PATCH] nested partitions, Grégoire Sutre, 2010/01/25
Re: [PATCH] nested partitions, Seth Goldberg, 2010/01/22