linux-kernel - Re: [PATCH RFC] efi: add and expose efi_partition_by

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: <AANLkTim=fyBDjZORcBygeb6hXQ1bdruufrF7KLqfUfzK@mail.gmail.com>
Date:	Tue, 3 Aug 2010 19:17:15 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	Will Drewry <wad@...omium.org>, linux-kernel@...r.kernel.org,
	Jens Axboe <jens.axboe@...cle.com>,
	Karel Zak <kzak@...hat.com>,
	"David S. Miller" <davem@...emloft.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Joe Perches <joe@...ches.com>
Subject: Re: [PATCH RFC] efi: add and expose efi_partition_by_guid

On Tue, Aug 3, 2010 at 18:08, Tejun Heo <tj@...nel.org> wrote:
> On 08/02/2010 09:17 PM, Will Drewry wrote:
>> EFI's GPT partitioning scheme expects that all partitions have a unique
>> identifiers.  After initial partition scanning, this information is
>> completely lost to the rest of the kernel.
>>
>> efi_partition_by_guid exposes GPT parsing support in a limited fashion
>> to allow other portions of the kernel to map a partition from GUID to
>> map.

> Kay, you were talking about using GUID in GPT for finding out root
> device and so on.  Does this fit your use case too?  If not it would
> be nice to find out something which can be shared.

Yeah, we have something similar in mind since a while, to be able to
safely boot a box without an initramfs, and to be able to to specify
something like:
  root=PARTUUID=6547567-575-7567-567567-57
  root=PARTLABEL=foo
on the kernel commandline.

The current 'blkid' already reports stuff like, to have the same
information in userspace:
  $ blkid -p -oudev /dev/sde1
  ID_FS_LABEL=10GB
  ID_FS_LABEL_ENC=10GB
  ID_FS_UUID=5aafa1bb-70a7-4fe6-b93f-30658ec99fac
  ID_FS_UUID_ENC=5aafa1bb-70a7-4fe6-b93f-30658ec99fac
  ID_FS_VERSION=1.0
  ID_FS_TYPE=ext4
  ID_FS_USAGE=filesystem
  ID_PART_ENTRY_SCHEME=gpt
  ID_PART_ENTRY_UUID=1f765dcb-5214-bd47-b1c5-f2f18848335e
  ID_PART_ENTRY_TYPE=a2a0d0eb-e5b9-3344-87c0-68b6b72699c7
  ID_PART_ENTRY_NUMBER=1

I guess we want to store these identifiers directly into the partition
structure, independent of the partition format, so any code can
register a callback for a new block device, and can just check if
that's the device in question. Walking the block devices would just be
something usual provided by the driver core, instead of having some
specific EFI walk functions.

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/