[RFC] CHROMIUM: Two patches for comments: EFI GUID boot for dm-verity

REPLACED WITH TWO CLS OUT FOR REVIEW.

[RFC] CHROMIUM: Two patches for comments: EFI GUID boot for dm-verity

I wanted to get these out for a first round of comments.  I'll break them
up into at least two patches.  The one that is most critical are the
changes to efi.c and efi.h.  Do you think they will fly?

At least the dm-verity bits can be a feature of dm-verity, though I modeled
the functions so that dm itself could offer them up.


CHROMIUM: dm-verity: add efi guid-based support

Adds GUID-based device specification _and_ backing device waiting to
dm-verity itself. (We could then pull out the dm= patch if we wanted to.)

CHROMIUM: dm-verity: add dev_wait to device loading

The dm_verity.dev_wait=1 code path allows a boot-time dm-verity target to delay start .  Since this is likely meant for boot path use, dm-verity must open the device with blkdev_get instead of just using bdget() and hoping that someone else has opened it (and therefore populated bd_disk, for example).

CHROMIUM: efi: define and export find_efi_partition

At present, there is no way to find a given EFI partition by its unique GUID.
The partition_type_guids are used for device setup during partition scanning
(e.g., md_autodetect) but the EFI/GPT partition table remains opaque.

The new function, find_efi_partition, will traverse a given disk
looking for a matching unique_partition_guid.  On match, the partition
index is returned.

An example of use is in dm-verity.  It allows the device mapper
target to pick a backing device using its unique GUID.


BUG=chromium-os:5081
TEST=manual use at boot-time and from the command line with dmsetup

Boot time use is on a x86 platform with a slow-to-register usb device.