Re: [PATCH v3] Documentation cleanup in response to ML discussion.
Go ahead
On 22.10.2013 01:15, Jon McCune wrote:
> [v0] Accepted with modifications by phcoder@
> [v1] Introduce subsections within Security
> [v1] Correct errors regarding public key files not being automatically
> signature-checked in trust and verify_detached
> [v1] Replace check_signatures=enforce with check_signatures set to enforce
> [v1] Move detailed discussion of using signatures out of check_signatures
> environment variable description
> [v1] Use long form for option flags to security-relevant commands
> [v2] Explain the key fingerprint format for distrust and list_trusted.
> [v2] Eliminates references to grub-mkimage and UEFI Secure Boot.
> [v3] Updates in response to addition of --skip-sig to trust and
> verify_detached
>
> Signed-off-by: Jon McCune
> ---
> docs/grub.texi | 197
> -
> 1 file changed, 112 insertions(+), 85 deletions(-)
>
> diff --git a/docs/grub.texi b/docs/grub.texi
> index 40eb9ed..8b0b76b 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -98,8 +98,7 @@ This edition documents version @value{VERSION}.
> * Environment:: GRUB environment variables
> * Commands::The list of available builtin commands
> * Internationalisation::Topics relating to language support
> -* Security::Authentication and authorisation
> -* Security and signatures:: Verifying digital signatures in GRUB
> +* Security::Authentication, authorisation, and signatures
> * Platform limitations::The list of platform-specific limitations
> * Platform-specific operations:: Platform-specific operations
> * Supported kernels:: The list of supported kernels
> @@ -3006,20 +3005,7 @@ chain-loaded system, @pxref{drivemap}.
> @subsection check_signatures
>
> This variable controls whether GRUB enforces digital signature
> -validation (@pxref{Security and signatures}) on all loaded files. If
> -@code{check_signatures=enforce}, then every attempt by the GRUB
> -@file{core.img} to load another file @file{foo} (e.g., a loadable
> -module, a configuration file, or a Linux kernel) implicitly invokes
> -@code{verify_detached foo foo.sig} (@pxref{verify_detached}).
> -@code{foo.sig} must contain a valid digital signature over the
> -contents of @code{foo}, which can be verified with a public key
> -currently trusted by GRUB (@pxref{list_trusted}, @pxref{trust}, and
> -@pxref{distrust}). If validation fails, then file @file{foo} cannot
> -be opened. This failure may halt or otherwise impact the boot
> -process. An initial trusted public key can be embedded within the
> -GRUB @file{core.img} using the @code{--pubkey} option to
> -@command{grub-mkimage} (@pxref{Invoking grub-install}).
> -
> +validation on loaded files. @xref{Using digital signatures}.
>
> @node chosen
> @subsection chosen
> @@ -3998,10 +3984,15 @@ but rather replaces it completely.
>
> @deffn Command distrust pubkey_id
> Remove public key @var{pubkey_id} from GRUB's keyring of trusted keys.
> -These keys are used to validate signatures when
> -@code{check_signatures=enforce} (@pxref{check_signatures}), and by some
> -invocations of @command{verify_detached} (@pxref{verify_detached}).
> -@xref{Security and signatures} for more information.
> +@var{pubkey_id} is the last four bytes (eight hexadecimal digits) of
> +the GPG v4 key id, which is also the output of @command{list_trusted}
> +(@pxref{list_trusted}). Outside of GRUB, the key id can be obtained
> +using @code{gpg --fingerprint}).
> +These keys are used to validate signatures when environment variable
> +@code{check_signatures} is set to @code{enforce}
> +(@pxref{check_signatures}), and by some invocations of
> +@command{verify_detached} (@pxref{verify_detached}). @xref{Using
> +digital signatures}, for more information.
> @end deffn
>
> @node drivemap
> @@ -4264,56 +4255,58 @@ This command is only available on x86 systems.
> @node list_env
> @subsection list_env
>
> -@deffn Command list_env [@option{-f} file]
> +@deffn Command list_env [@option{--file} file]
> List all variables in the environment block file. @xref{Environment block}.
>
> -The @option{-f} option overrides the default location of the environment
> -block.
> +The @option{--file} option overrides the default location of the
> +environment block.
> @end deffn
>
> @node list_trusted
> @subsection list_trusted
>
> @deffn Command list_trusted
> -List all public keys trusted by GRUB for validating signatures. These
> -public keys are used implicitly when environment variable
> -@code{check_signatures=enforce} (@pxref{check_signatures}), and by some
> -invocations of @command{verify_detached}. @xref{Security and
> -signatures} for more information.
> +List all public keys trusted by GRUB for validating signatures.
> +The output is in GPG's v4 key fingerprint format (i.e., the output of
> +@code{gpg --fingerprint}). The least
Windows 7 won't boot properly IF keyboard input is made during grub boot timeout
I'm seeing a funny behavior which I think is caused by GRUB leaving the HW in some state that Windows is not expecting. Here is the scenario. In my new Haswell system, I installed an Ubuntu-based custom OS in a dual-boot configuration with the existing Win7 OEM. The grub menu has Ubuntu 1st and Windows 7 as second choice. If I power up the machine and use the arrow keys to move the highlighter "cursor" from the Ubuntu entry to the Win7 entry, Windows will choke during loading. The graphics will be all garbled. Eventually (many minutes > 10 mins), windows does boot. Now, here is the funny thing. If I boot and don't touch any keys and simply let the grub boot timer expire and boot the selected entry (which happens to be Windows 7 since it was the last one I booted), then Windows will boot fine. This is reproducible about 90% of the time. Any time a key is touched during the count down, Windows will chock up during its booting process. The other 10% of the time, Windows will boot normally. Is this a known problem with my grub version 1.99 (1.99-21ubuntu3.9)? Any suggestions on what I should look to try to fix in the source code? Thanks in advance. Roger R. Cruz ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub mishandles corrupt/missing primary GPT
On Oct 24, 2013, at 7:39 AM, "Lennart Sorensen" wrote: > On Wed, Oct 23, 2013 at 09:07:21PM -0600, Chris Murphy wrote: >> While technically a violation of the UEFI spec, I think this can be worked >> around by considering the disk GPT if the first entry in the MBR is type >> 0xEE. I don't know of a hybrid MBR implementation where an entry other than >> the first is 0xEE. > > Well everyone other than Microsoft seems to understand how useful support > for hybrid setups can be and hence support them. Support is a very strong word. They're basically a craptastic workaround for prior unfortunate choices. Apple uses them, it hardly supports them. Their tools routinely nuke hybrid MBRs in favor of PMBRs rendering the secondary OS unbootable; if the MBR and GPT aren't sync'd, they will bone the correct MBR with wrong GPT information, rendering the secondary OS unbootable and data inaccessible. And it does this silently. I think it's OK to tiptoe around hybrid MBRs, and do something sensible, if possible. Supporting them is out of scope because there's no standard or agreed upon way to interpret them. > >> But if there is no 0xEE entry at all, this is identical to a formerly GPT >> disk repartitioned as MBR by a utility that doesn't know anything about GPT, >> and thus doesn't erase the stale GPT data - and therefore must be treated as >> MBR. > > That is true. That does not mean there must ONLY be a 0xEE entry. Well, there must be only an 0xEE entry to treat the disk as a pure GPT disk. Once there's 0xEE and 1-3 additional entries, it's a hybrid logic, very few combinations of which are sane. When the MBR and GPT don't agree with each other, which on Macs is actually somewhat common once you've used Bootcamp Assistant, because users think it's OK to resize OS X volumes in OS X Disk Utility, and then use free space to either create an additional OS X partition, or grow an existing Windows partition from within Windows. Oops, now the MBR and GPT don't agree with each other, so which one is correct? Well, it's ambiguous. With a few exceptions, there's actually no way to know what's correct, which is why hybrid MBRs are ultimately shit. But again, I'm fine dodging piles of crap rather than cleaning up other people's messes. > > I do wonder how Windows handles booting with a corrupt primary GPT. > Would you happen to know? (A quick google search didn't find an answer > to the question unfortunately). I haven't tested it because I don't have a UEFI machine here, only Apple EFI. So I'm stuck with CSM-BIOS mode booting of Windows, which means it will only use MBR. I haven't figured out UEFI within qemu/kvm, and if that can boot Windows in UEFI mode. > >> The UEFI spec says "Software should ask a user for confirmation before >> restoring the primary GPT" and yet it also requires the unspecified software >> fix the primary GPT if corrupt. The spec actually uses the word "must". So >> per usual, the spec has rather lofty demands. > > So it must fix it after asking the user for confirmation? Yes it's just being silly. But the take away is that (partitioning) tools are behaving wrongly if they understand GPT, yet ignore or can't fix problems with either GPT. The spec only says software, it doesn't specify what software, so I'm assuming partitioning tools. Obviously the kernel is software, but it's not in a position to ask the user anything. Chris Murphy ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to pick a kernel to boot ?
On 10/24/2013 12:44 PM, Lennart Sorensen wrote: > On Thu, Oct 24, 2013 at 04:46:19PM +0200, Lukáš Czerner wrote: >> Hi, >> >> I have a simple question about grub2 which I can not find satisfying >> answer to. >> >> What is a proper way to pick a kernel to boot from in case I have >> multiple kernels installed ? Note that picking the right kernel from >> the menu is not an option I do not always have access to the >> console. >> >> With grub legacy, this was easy. Simply edit >> >> /boot/grub/menu.lst >> >> and pick the right number. All the information I need are in that >> file. >> >> So what is a recommended way to do this with grub2 ? > > Same thing in /boot/grub/grub.cfg. There is default with a number. > Sorry ... some how left the list off my initial reply ... To set a default to boot, use grub2-set-default [kernel entry number] To boot a kernel once and keep the default the same (ie, boot a kernel one time) grub2-reboot [kernel entry number] I've noticed a lot of people messing with /boot/grub2/grub.conf ... you shouldn't have to do that to select a kernel to boot. P. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to pick a kernel to boot ?
On Thu, Oct 24, 2013 at 04:46:19PM +0200, Lukáš Czerner wrote: > Hi, > > I have a simple question about grub2 which I can not find satisfying > answer to. > > What is a proper way to pick a kernel to boot from in case I have > multiple kernels installed ? Note that picking the right kernel from > the menu is not an option I do not always have access to the > console. > > With grub legacy, this was easy. Simply edit > > /boot/grub/menu.lst > > and pick the right number. All the information I need are in that > file. > > So what is a recommended way to do this with grub2 ? Same thing in /boot/grub/grub.cfg. There is default with a number. -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
How to pick a kernel to boot ?
Hi, I have a simple question about grub2 which I can not find satisfying answer to. What is a proper way to pick a kernel to boot from in case I have multiple kernels installed ? Note that picking the right kernel from the menu is not an option I do not always have access to the console. With grub legacy, this was easy. Simply edit /boot/grub/menu.lst and pick the right number. All the information I need are in that file. So what is a recommended way to do this with grub2 ? Thanks! -Lukas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub mishandles corrupt/missing primary GPT
On Wed, Oct 23, 2013 at 09:07:21PM -0600, Chris Murphy wrote: > While technically a violation of the UEFI spec, I think this can be worked > around by considering the disk GPT if the first entry in the MBR is type > 0xEE. I don't know of a hybrid MBR implementation where an entry other than > the first is 0xEE. Well everyone other than Microsoft seems to understand how useful support for hybrid setups can be and hence support them. > But if there is no 0xEE entry at all, this is identical to a formerly GPT > disk repartitioned as MBR by a utility that doesn't know anything about GPT, > and thus doesn't erase the stale GPT data - and therefore must be treated as > MBR. That is true. That does not mean there must ONLY be a 0xEE entry. > So perhaps this test is difficult because it's GPT on BIOS, with a limited > space BIOS boot partition. However, I think on UEFI computers this should > still work with one valid GPT, rather than not boot at all. There's a lot > more space for this there. Certainly if using the BIOS boot partition, there really isn't much of a space excuse anymore, unless you run into limitations on how much ram you can use in early boot. > Both primary and backup GPTs are preserved in this case since the primary is > in LBA 1 and 2, and only LBA 0 is overwritten with the new MBR. > > UEFI spec says if the MBR signature of 0xaa55 is intact, and there isn't an > 0xEE entry, and the partition entries are rational (physically on disk and > don't overlap), then the two GPTs are considered stale and the disk is MBR. > > The primary header contains the location of the backup GPT. If the header is > sufficiently corrupt, and the backup GPT can't be located, then that's the > same as an invalid backup GPT, and in that case fail. > > My point is we shouldn't fail when there is a valid locatable backup GPT. The > whole point of having a second GPT is obviated with the current behavior. Sometimes backups are designed in and never used. I don't recall ever seeing any indication Microsoft ever used the second copy of the FAT for anything other than filesystem repair tools. > I don't think we can work around this kind of hardware vendor sabotage. If it > looks like a valid GPT, but is actually stale, if it's used and contains > incorrect information, then boot fails. Better to try than not try at all. > > It's certainly uncommon. A Google search: corrupt "primary gpt" only turns up > 1900 results. But it is possible. > > And this isn't the only mishandling I'm finding, so it's not like GRUB is > unique. In fact just now by changing only a single byte in the primary GPT > table (I changed the E to an F in the BIOS boot partition type UUID), the > kernel suddenly has no idea what disklabel the disk is, and fails to mount > rootfs. So I need to track that down too, but it seems like it knows the > primary GPT table is corrupt, but then fails to use the backup GPT for some > reason. > > An argument against GRUB doing all of this work: maybe the bootloader should > be able to blindly trust the primary GPT table with no validity checks? And > instead rely on (presently non-existent) checks by the underlying OS to fixi > this problem? Something like an fsck_gpt, seeing as nothing else is in a good > position to both check and fix such GPTs other than a partition tool. Perhaps. Certainly simpler. I do wonder how Windows handles booting with a corrupt primary GPT. Would you happen to know? (A quick google search didn't find an answer to the question unfortunately). > The UEFI spec says "Software should ask a user for confirmation before > restoring the primary GPT" and yet it also requires the unspecified software > fix the primary GPT if corrupt. The spec actually uses the word "must". So > per usual, the spec has rather lofty demands. So it must fix it after asking the user for confirmation? -- Len Sorensen ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to setup grub with /boot inside luks+vm ?
On 24.10.2013 11:28, J B wrote: > Hello list, > > I have the grub2 (1.99-27+deb7u2 ) working with luks+lvm but /boot not > included in lvm... > Can grub2 call /boot from luks+lvm ? If yes, can anyone please share the > configuration please ? > Not the version that you use. > Thanks > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
How to setup grub with /boot inside luks+vm ?
Hello list, I have the grub2 (1.99-27+deb7u2 ) working with luks+lvm but /boot not included in lvm... Can grub2 call /boot from luks+lvm ? If yes, can anyone please share the configuration please ? Thanks ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
