Re: 01/02: gnu: qemu: Update to 2.9.0 [security fixes].

[Mark H Weaver <mhw@netris.org>]

leo@famulari.name (Leo Famulari) writes:

> lfam pushed a commit to branch master
> in repository guix.
>
> commit dfa663c963a7c0745f18cbfab4b45eb335742602
> Author: Leo Famulari <leo@famulari.name>
> Date:   Fri Apr 7 09:03:28 2017 -0400
>
>     gnu: qemu: Update to 2.9.0 [security fixes].
>     
>     Fixes CVE-2017-{5857,5973,5987,6058,6505,7377,7471,7718}.

Thanks for this!  Obviously it's an important security update, but:

On my x86_64 system running GuixSD, 'grub' now fails to build from
source.  Three times in a row, the 'grub_cmd_set_date' has failed.
Here's the relevant excerpt from test-suite.log (lightly formatted):

  FAIL: grub_cmd_set_date
  =======================
  
  qemu-system-i386: Trying to execute code outside RAM or ROM at 0xefffff53
  This usually means one of the following happened:
  
  (1) You told QEMU to execute a kernel for the wrong machine type, and
  it crashed on startup (eg trying to run a raspberry pi kernel on a
  versatilepb QEMU machine)
  
  (2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU
  executed a ROM full of no-op instructions until it fell off the end
  
  (3) Your guest kernel has a bug and crashed by jumping off into nowhere
  
  This is almost always one of the first two, so check your command line
  and that you are using the right type of kernel for this machine.
  If you think option (3) is likely then you can try debugging your
  guest with the -d debug options; in particular -d guest_errors will
  cause the log to include a dump of the guest register state at this
  point.
  
  Execution cannot continue; stopping here.
  
  Test failed: 2017-04-21 00:08:44 Friday

The build appears to have succeeded on Hydra:

  https://hydra.gnu.org/eval/109616?filter=grub

Unfortunately the substitute is not yet available, so for the moment I'm
stuck.  I'll look into disabling this test for now.

Has anyone else seen this?

      Mark