From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1NZ9tY-0007Jl-RF for mharc-grub-devel@gnu.org; Sun, 24 Jan 2010 16:21:20 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZ9tW-0007JF-N3 for grub-devel@gnu.org; Sun, 24 Jan 2010 16:21:18 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZ9tR-0007I1-2Y for grub-devel@gnu.org; Sun, 24 Jan 2010 16:21:17 -0500 Received: from [199.232.76.173] (port=57257 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZ9tQ-0007Hx-UN for grub-devel@gnu.org; Sun, 24 Jan 2010 16:21:12 -0500 Received: from mail-bw0-f219.google.com ([209.85.218.219]:47220) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZ9tQ-0002xe-PX for grub-devel@gnu.org; Sun, 24 Jan 2010 16:21:13 -0500 Received: by bwz19 with SMTP id 19so2289327bwz.8 for ; Sun, 24 Jan 2010 13:21:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=kpEQjdPjlYz1eY7iXkHSUPx0IbcjcHGWLc4RO9itrGA=; b=KgTM60pxdJHHsoDKo46/qO1C9MJpBUGgAnDkzSpP5z66RKCfgEPIFu4Zf5qE0ENXoo hzbs7BtPKrnp7PpDkcAZTPhhF5d11TRneQvl2X2ZOE7EZlJVNbf/3z8R0ikuYer+wdZw 8+8IdKPP7S+Hrs1crSN9rDFBv8rdMD8B4tNOI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; b=A8jrg6R9Fg4/9UmKyKw3eFi/mDYANIr3Y70qExD1qcXdVVugmNmVgN/Qs+tu6VX4mr nQsxD4udDXqglguDRoeoZ+GyJxFce8E6xMvNmJivckWtppcDnzJOwkMtNJ0R/vhBqIAr AR4pbxYvupOUaXlsdkxo7qzKzPE6Nqp2iOukQ= Received: by 10.204.11.15 with SMTP id r15mr1725948bkr.40.1264368071547; Sun, 24 Jan 2010 13:21:11 -0800 (PST) Received: from debian.bg45.phnet (gprs17.swisscom-mobile.ch [193.247.250.17]) by mx.google.com with ESMTPS id 16sm1903048bwz.15.2010.01.24.13.21.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 13:21:10 -0800 (PST) Message-ID: <4B5CB9B1.5040206@gmail.com> Date: Sun, 24 Jan 2010 22:20:49 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: The development of GNU GRUB References: <20090804201512.GA15811@thorin> <20090817140657.GP32551@thorin> <20100122165300.GA14428@thorin> <4B59E869.700@gmail.com> <20100124204118.GA10054@thorin> In-Reply-To: <20100124204118.GA10054@thorin> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig8CDA04FE145A9B92B793D196" X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: [PATCH] nested partitions X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 21:21:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8CDA04FE145A9B92B793D196 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Robert Millan wrote: > On Fri, Jan 22, 2010 at 07:03:21PM +0100, Vladimir '=CF=86-coder/phcode= r' Serbinenko wrote: > =20 >>> This can be done by extending "has_partitions" to be set to "yes" in = those >>> specific partition types. The implementation should be the least int= rusive >>> possible, taking into account that this kind of situations are an odd= ity >>> rather than the norm. >>> >>> =20 >>> =20 >> Partition types are easily screwed. Why not just check for the presenc= e >> of the label? >> =20 > > I have a feeling I already explained this somewhere. Doesn't seem to b= e in > this thread, maybe on IRC? Anyway, it won't hurt to ellaborate on it..= =2E > > 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 thos= e > matches is correct, because only the *user* knows that. > > This is a problem we already have, but it is bearable because worst cas= e 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 thi= ngs > happen: > > - has_partitions stops being useful. When in top level, it's relativ= ely > 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, ch= ances > are it isn't (this is an unreliable check, but its purpose is to pa= liate > the effect of using another unreliable check, so overall it's a gai= n). > =20 I don't see any illness-effects caused by misdetection. > - False positives can be repeated ad nauseam. It can even be exploit= ed to > force GRUB into reading several GiBs of data, effectively DoSing it= =2E > > =20 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 typ= es, the > recursion depth, etc. > =20 Often limits are result of static resource allocation. > If we're going to support *all* possible combinations, I'd rather revis= it > and solve our detection problem first. Not by actually making detectio= n > 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 expecta= tion > that it somehow knows the correct result. Users end up blaming GRUB fo= r that. > > So instead of supporting things like: > > (hd0,1) > (hd0,2) > > (ambigous; what does this mean in an hybrid MSDOS/GPT ? What about o= ther > 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 lab= els. > > =20 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. =20 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) > > =20 --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig8CDA04FE145A9B92B793D196 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iF4EAREKAAYFAktcubgACgkQNak7dOguQgm/wgD/X0Zb5EWfvWvrgvOBEe6Ecs+Q iLaJRPcQNHCdS05iB5EA+QH2HdLkNt/EoraJSkQ8tuYncflnGHhjlq6oyfp8gQie =WyyL -----END PGP SIGNATURE----- --------------enig8CDA04FE145A9B92B793D196--