linux-kernel - Re: [PATCH v2 2/3] genhd, efi: add efi partition metadata to hd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTin8eVm=_pw_DgP2wJW9pE0LgugqfXJE8aVXiH6R@mail.gmail.com>
Date:	Wed, 4 Aug 2010 12:14:45 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Karel Zak <kzak@...hat.com>
Cc:	Will Drewry <wad@...omium.org>, linux-kernel@...r.kernel.org,
	Jens Axboe <axboe@...nel.dk>, Tejun Heo <tj@...nel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Joe Perches <joe@...ches.com>, Jan Blunck <jblunck@...e.de>,
	Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: [PATCH v2 2/3] genhd, efi: add efi partition metadata to 
	hd_structs

On Wed, Aug 4, 2010 at 11:00, Karel Zak <kzak@...hat.com> wrote:
> On Tue, Aug 03, 2010 at 09:04:42PM -0500, Will Drewry wrote:
>> This change extends the partition_meta_info structure to
>> support EFI GPT-specific metadata and ensures that data
>> is copied in on partition scanning.
>
> Why do want to store GPT-specific data (efi_guid_t) to
> partition_meta_info? I think it would be better to use label and uuid
> in a generic format (e.g. string or u8 uuid[16]) -- then you don't
> have to use things like union, disklabel specific code to compare
> uuids, etc.  IMHO your current code is too complicated.

I don't mind having the raw data and the type accessible. It might be
useful for something we don't know about and it basically comes for
free.

But the only thing we are really interested in is the UUID, which,
like Tejun already suggested, we should probably store
format-independent, and have it always accessible. That way, we would
not need any type-specific parser, we just handle the normal DCE
format.

I don't think we should support any of the labels anyway in root= and
similar, because they never really worked reliably with duplicates,
and just ask for trouble.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/