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" <[email protected]> wrote:
> No problem. The patch should be uploaded now. > On Nov 17, 2014 1:24 PM, "Andrei Borzenkov" <[email protected]> wrote: > >> В Mon, 17 Nov 2014 12:29:43 -0600 >> Robert Kliewer <[email protected]> пишет: >> >> > 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" <[email protected]> >> wrote: >> > >> > > В Tue, 11 Nov 2014 14:06:14 -0600 >> > > Robert Kliewer <[email protected]> пишет: >> > > >> > > > 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 >> > > >> > > >> >>
_______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
