18 Apr, 2016

1 commit


08 Jan, 2015

1 commit


02 Jul, 2014

1 commit


22 Nov, 2013

1 commit

  • Use ARRAY_SIZE instead of sizeof to get proper max for label length.

    Since this is just a read out of bounds it's not that bad, but the
    problem becomes user-visible eg if one tries to use DEBUG_PAGEALLOC and
    DEBUG_RODATA, at least with some enhancements from Hiroshi. Of course
    the destination array can contain garbage when we read beyond the end of
    source array so that would be another user-visible problem.

    Signed-off-by: Antti P Miettinen
    Reviewed-by: Hiroshi Doyu
    Tested-by: Hiroshi Doyu
    Cc: Will Drewry
    Cc: Matt Fleming
    Acked-by: Davidlohr Bueso
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Antti P Miettinen
     

17 Oct, 2013

1 commit

  • In commit 27a7c642174e ("partitions/efi: account for pmbr size in lba")
    we started treating bad sizes in lba field of the partition that has the
    0xEE (GPT protective) as errors.

    However, we may run into these "bad sizes" in the real world if someone
    uses dd to copy an image from a smaller disk to a bigger disk. Since
    this case used to work (even without using force_gpt), keep it working
    and treat the size mismatch as a warning instead of an error.

    Reported-by: Josh Triplett
    Reported-by: Sean Paul
    Signed-off-by: Doug Anderson
    Reviewed-by: Josh Triplett
    Acked-by: Davidlohr Bueso
    Tested-by: Artem Bityutskiy
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Doug Anderson
     

15 Sep, 2013

1 commit

  • Matt found that commit 27a7c642174e ("partitions/efi: account for pmbr
    size in lba") caused his GPT formatted eMMC device not to boot. The
    reason is that this commit enforced Linux to always check the lesser of
    the whole disk or 2Tib for the pMBR size in LBA. While most disk
    partitioning tools out there create a pMBR with these characteristics,
    Microsoft does not, as it always sets the entry to the maximum 32-bit
    limitation - even though a drive may be smaller than that[1].

    Loosen this check and only verify that the size is either the whole disk
    or 0xFFFFFFFF. No tool in its right mind would set it to any value
    other than these.

    [1] http://thestarman.pcministry.com/asm/mbr/GPT.htm#GPTPT

    Reported-and-tested-by: Matt Porter
    Signed-off-by: Davidlohr Bueso
    Signed-off-by: Linus Torvalds

    Davidlohr Bueso
     

12 Sep, 2013

8 commits

  • Cc: Davidlohr Bueso
    Cc: Karel Zak
    Cc: Matt Fleming
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     
  • Trivial coding style cleanups - still plenty left.

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Davidlohr Bueso
    Reviewed-by: Karel Zak
    Acked-by: Matt Fleming
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Davidlohr Bueso
     
  • When verifying GPT header integrity, make sure that first usable LBA is
    smaller than last usable LBA.

    Signed-off-by: Davidlohr Bueso
    Reviewed-by: Karel Zak
    Acked-by: Matt Fleming
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Davidlohr Bueso
     
  • The partition that has the 0xEE (GPT protective), must have the size in
    lba field set to the lesser of the size of the disk minus one or
    0xFFFFFFFF for larger disks.

    Signed-off-by: Davidlohr Bueso
    Reviewed-by: Karel Zak
    Acked-by: Matt Fleming
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Davidlohr Bueso
     
  • One of the biggest problems with GPT is compatibility with older, non-GPT
    systems. The problem is addressed by creating hybrid mbrs, an extension,
    or variant, of the traditional protective mbr. This contains, apart from
    the 0xEE partition, up three additional primary partitions that point to
    the same space marked by up to three GPT partitions. The result is that
    legacy OSs can see the three required MBR partitions and at the same time
    ignore the GPT-aware partitions that protect the GPT structures.

    While hybrid MBRs are hacks, workarounds and simply not part of the GPT
    standard, they do exist and we have no way around them. For instance, by
    default, OSX creates a hybrid scheme when using multi-OS booting.

    In order for Linux to properly discover protective MBRs, it must be made
    aware of devices that have hybrid MBRs. No functionality is changed by
    this patch, just a debug message informing the user of the MBR scheme that
    is being used.

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Davidlohr Bueso
    Reviewed-by: Karel Zak
    Acked-by: Matt Fleming
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Davidlohr Bueso
     
  • When detecting a valid protective MBR, the Linux kernel isn't picky about
    the partition (1-4) the 0xEE is at, but, unlike other operating systems,
    it does require it to begin at the second sector (sector 1). This check,
    apart from it not being enforced by UEFI, and causing Linux to potentially
    fail to detect any *valid* partitions on the disk, can present problems
    when dealing with hybrid MBRs[1].

    For compatibility reasons, if the first partition is hybridized, the 0xEE
    partition must be small enough to ensure that it only protects the GPT
    data structures - as opposed to the the whole disk in a protective MBR.
    This problem is very well described by Rod Smith[1]: where MBR-only
    partitioning programs (such as older versions of fdisk) can see some of
    the disk space as unallocated, thus loosing the purpose of the 0xEE
    partition's protection of GPT data structures.

    By dropping this check, this patch enables Linux to be more flexible when
    probing for GPT disklabels.

    [1] http://www.rodsbooks.com/gdisk/hybrid.html#reactions

    Signed-off-by: Davidlohr Bueso
    Reviewed-by: Karel Zak
    Acked-by: Matt Fleming
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Davidlohr Bueso
     
  • Per the UEFI Specs 2.4, June 2013, the starting lba of the partition that
    has the EFI GPT (0xEE) must be set to 0x00000001 - this is obviously the
    LBA of the GPT Partition Header.

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Davidlohr Bueso
    Reviewed-by: Karel Zak
    Acked-by: Matt Fleming
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Davidlohr Bueso
     
  • The kernel's GPT implementation currently uses the generic 'struct
    partition' type for dealing with legacy MBR partition records. While this
    is is useful for disklabels that we designed for CHS addressing, such as
    msdos, it doesn't adapt well to newer standards that use LBA instead, such
    as GUID partition tables. Furthermore, these generic partition structures
    do not have all the required fields to properly follow the UEFI specs.

    While a CHS address can be translated to LBA, it's much simpler and
    cleaner to just replace the partition type. This patch adds a new
    'gpt_record' type that is fully compliant with EFI and will allow, in the
    next patches, to add more checks to properly verify a protective MBR,
    which is paramount to probing a device that makes use of GPT.

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Davidlohr Bueso
    Reviewed-by: Karel Zak
    Acked-by: Matt Fleming
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Davidlohr Bueso
     

30 Apr, 2013

1 commit


28 Feb, 2013

1 commit

  • UEFI 2.3.1D will include a change to the spec language mandating that a
    GPT header must be greater than *or equal to* the size of the defined
    structure. While verifying that this would work on Linux, I discovered
    that we're not actually checking the minimum bound at all.

    The result of this is that when we verify the checksum, it's possible that
    on a malformed header (with header_size of 0), we won't actually verify
    any data.

    [akpm@linux-foundation.org: fix printk warning]
    Signed-off-by: Peter Jones
    Acked-by: Matt Fleming
    Cc: Jens Axboe
    Cc: Stephen Warren
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Jones
     

23 Nov, 2012

1 commit

  • This will allow other types of UUID to be stored here, aside from true
    UUIDs. This also simplifies code that uses this field, since it's usually
    constructed from a, used as a, or compared to other, strings.

    Note: A simplistic approach here would be to set uuid_str[36]=0 whenever a
    /PARTNROFF option was found to be present. However, this modifies the
    input string, and causes subsequent calls to devt_from_partuuid() not to
    see the /PARTNROFF option, which causes different results. In order to
    avoid misleading future maintainers, this parameter is marked const.

    Signed-off-by: Stephen Warren
    Cc: Tejun Heo
    Cc: Will Drewry
    Cc: Kay Sievers
    Signed-off-by: Andrew Morton
    Signed-off-by: Jens Axboe

    Stephen Warren
     

04 Jan, 2012

1 commit