I believe I found the root cause and proper fix. I've updated the bug report (43601) with my findings and a patch that fixes the bug. Thanks.
On Nov 17, 2014 2:52 PM, "Robert Kliewer" <
address@hidden> wrote:
No problem. The patch should be uploaded now.
On Nov 17, 2014 1:24 PM, "Andrei Borzenkov" <
address@hidden> wrote:
В Mon, 17 Nov 2014 12:29:43 -0600
Robert Kliewer <address@hidden> пишет:
> 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.
Could you attach your patches with debug output (git diff would be
fine) to the bug report; it makes it easier to follow?
> 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
> >
> >