From owner-freebsd-bugs@FreeBSD.ORG Tue Dec 30 20:57:09 2014 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51EE3F25 for ; Tue, 30 Dec 2014 20:57:09 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3958B24F0 for ; Tue, 30 Dec 2014 20:57:09 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sBUKv9HO003961 for ; Tue, 30 Dec 2014 20:57:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 196388] New: Gpart code violates EFI specification Date: Tue, 30 Dec 2014 20:57:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: petrek729@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 20:57:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196388 Bug ID: 196388 Summary: Gpart code violates EFI specification Product: Base System Version: 10.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: petrek729@gmail.com Hi, Lately I was bitten by this bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=115406 Due to too much time I read said specification (the old link doesn't work, here's the current one http://www.intel.com/content/dam/www/public/us/en/zip/efi-110.zip to save your time). To save even more time the most relevant quotes from it are placed here with my (hopefully valuable) comment. In Table 11-6 we find information, that Start Head, Sector and Track and End Head, Sector and Track are not used by EFI firmware, in the contrary to the "Starting LBA" and "Size in LBA". 1. Below the table we read: "Each MBR partition record must be checked to make sure that the partition that it defines physically resides on the disk" and little later: "If any of these checks fail, the MBR is not considered valid". When the address of the End Head of said partition is set to 0xff (as is in the current code), indicating the 0x100 Head (since Heads are counted from 0), the above condition is not met, since physically (most) CHS disks end at most at 0xff Head and such partition exceeds this value, so due to this such MBR can't be even considered valid. 2. "The Protective MBR has the same format as a legacy MBR" means the point number 1 applies to it also. 3. In the table 11-7 in the End Head, Sector and Track records we can read: "Set to match the Ending LBA of the EFI Partition structure. Must be set to 0xFFFFFF if it is not possible to represent the starting LBA". As was mentioned in the bug report, it is possible to represent the starting LBA, and the current gpart code does that for Start CHS address (which by the way has exactly the same description as the End CHS address, so either both should be set to 0xFFFFFF or none), so the condition for setting End CHS address as 0xFFFFFF is not even met here. 5. "(PMBR) reserves the entire space used on the disk by the GPT partitions, including all headers. [...] If the GPT partition is larger than a partition that can be represented by a legacy MBR, values of all Fs must be used". Legacy MBR can represent up to 2 TiB of space, so we should set "Size in LBA" to all Fs if the GPT partition exceeds this value, not any of the possible CHS values, these are irrelevant here. Indeed, as a confirmation of this in Table 11-7 we read in "Size in LBA" record: "Length of EFI Partition Head, 0xFFFFFFFF if this value overflows." So the EFI specification doesn't require setting address of the End Head as 0xff, and even forbids it if this will overflow the CHS capacity of the disk, so the current PMBR for all those reasons due to some previous misunderstandings in reality is invalid and violates EFI specification. -- You are receiving this mail because: You are the assignee for the bug.