I don't have a local disk setup to test, but a memdisk test works without issue (using code from git master on 11/11). I was able to add some debug logging to isolate the issue to grub_file_close. I attached a screenshot and some more info to the bug report (43601). It seems like the gpg close and tftp close may be stepping on each other, but not really knowing the code I'm just taking a guess. Removing the grub_device_close call from grub_file_close fixes my issue, but I know it's not the right answer. Hope this helps.
On Nov 15, 2014 10:40 AM, "Andrei Borzenkov" <
address@hidden> wrote:
В Tue, 11 Nov 2014 14:06:14 -0600
Robert Kliewer <address@hidden> пишет:
> I'm seeing an issue in rhel 7 grub 2.02 based on grub 2.02~beta2 (none of
> the rhel patches appear to touch gpg, so it's almost certainly in the main
> line as well). If I'm using a gpg public key with check_signatures
> enabled, all file operations over tftp break grub (efi x86_64 image running
> on vmware 10). For example if I cat a signed grubenv file, the file
> displays in its entirety but it is followed with:
>
> alloc magic is broken at <addr>: <value>
> Aborted. Press any key to exit.
>
This sounds like memory corruption. It does not need to have anything
to do with gpg, could as well be a tftp/network problem. Useful tests
were
- test same operation from local disk (to exclude network)
- test current upstream master whether problem still exists there
> Pressing a key takes me back to the EFI firmware. I can work around the
> issue by disabling check_signatures and manually running verify_detached on
> the file but that leaves me pulling my kernel and initrd twice, once to
> check the signature and once to load. Just wondering if I'm configured in
> a bad way that would cause this behaviour. Also, this does not appear to
> be an issue with signed files in the memdisk (probably not the hdd either,
> but I'm only booting over the network). Any help is appreciated. Thanks.
>
> Rob