[19.10 FEAT] KVM: Secure Linux Boot Toleration - qemu

[bugproxy]

[Impact]

 * s390x is about to add secure boot features which are implemented by a
   new IPL section

 * Older qemu bootloaders for s390x will stumble over that IPL section and
   be unable to boot.

 * Backport the changes from upstream that make qemu tolerate those
   sections (not the new feature of secure boot, just the avoidance of the
   guest crash on boot)

[Test Case]

 * Take a signed kernel on s390x (either the one from xnox in comment #19
   or use signtool to create one)
 * Install that kernel in a guest of the qemu that is to be tested
 * Run zipl with --secure 1 to write a secure boot section for sure
 * With an unpatched qemu this would now fail to boot again
 * Install the update to qemu and boot the guest, by skipping the
   "tolerated, but not supported" new section it works again.

[Regression Potential]

 * If any of the checks goes wrong we might affect booting of guests in a
   negative way. For example it might no more start or load a wrong
   kernel. But since the IPL records written by `zipl` are clearly
   specified that should hopefully not be the case here. The code added
   clearly only skips an additional section that didn't exist before.

[Other Info]

 * n/a

---

Secure boot enablement KVM.
Will be made available with qemu 4.1

[Frank Heimes (fheimes)]

Strongly assuming that this should be targeted towards 19.10 (like in the tags) and not 19.04 (like in the headline) I adjusted the headline to 19.10, too.
Will set to Incomplete for now until code got released and will discuss internally ...

[Christian Ehrhardt  (paelzer)]

Qemu 4.1 is a stretch for Ubuntu 19.10.
While qemu 4.1 itself would release "just in time" the usual rule of thumb is that one should have a libvirt that is released later (to handle any new quirks). Now that is then already way into feature freeze - therefore while 4.1 is an option it is rather unlikely.

Is there any chance that the patch set can be isolated and applied on top of 4.0?
If so a list of commits that are needed would be great.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2019-05-24 06:21 EDT-------
This affects the boot firmware only, the commit ids for the firmware binary and sources are

commit f7a339a5ba48a8a5c5bf4f1fdb1463bf8ac5f5bb
Author: Thomas Huth <email address hidden>
Date: Wed May 8 11:26:01 2019 +0200

pc-bios/s390: Update firmware image with "Skip bootmap signature entries" fi

Firmware now skips the unsupported signature entries instead of
aborting the boot process.

Signed-off-by: Thomas Huth <email address hidden>

commit 2497b4a3c08426122d1a89b808c669a734469e5a
Author: Jason J. Herne <email address hidden>
Date: Mon Apr 29 09:09:41 2019 -0400

s390-bios: Skip bootmap signature entries

Newer versions of zipl have the ability to write signature entries to the bo
script for secure boot. We don't yet support secure boot, but we need to ski
over signature entries while reading the boot script in order to maintain ou
ability to boot guest operating systems that have a secure bootloader.

Signed-off-by: Jason J. Herne <email address hidden>
Reviewed-by: Farhan Ali <email address hidden>
Message-Id: <email address hidden>
Signed-off-by: Thomas Huth <email address hidden>

[Dimitri John Ledkov (xnox)]

We will need this in xenial and up, and cloud-archives too.

[Dimitri John Ledkov (xnox)]

On top of v4.0 we only need:
2497b4a3c0 s390-bios: Skip bootmap signature entries

but can take a relatively harmless as well:
796588ba1 pc-bios/s390-ccw: Clean up harmless misuse of isdigit()

On top of 3.1 we probably want all of these:
$ git log --oneline 63c93fac18.. pc-bios/s390-ccw
2497b4a3c0 s390-bios: Skip bootmap signature entries
d796588ba1 pc-bios/s390-ccw: Clean up harmless misuse of isdigit()
2880469c95 s390-bios: Use control unit type to find bootable devices
efa47d36da s390-bios: Support booting from real dasd device
69333c36dc s390-bios: Add channel command codes/structs needed for dasd-ipl
3668cb7ce8 s390-bios: Use control unit type to determine boot method
9de6cbb152 s390-bios: Refactor virtio to run channel programs via cio
7b361db37b s390-bios: Factor finding boot device out of virtio code path
930072d2bf s390-bios: Extend find_dev() for non-virtio devices
86c58705bb s390-bios: cio error handling
3083a1bbb8 s390-bios: Support for running format-0/1 channel programs
1fb3e5cde8 s390-bios: ptr2u32 and u32toptr
c95df3d108 s390-bios: Map low core memory
120d04103e s390-bios: Decouple channel i/o logic from virtio
d96c5db77f s390-bios: Clean up cio.h
a5f6e0975b s390-bios: decouple common boot logic from virtio
87f910c142 s390-bios: decouple cio setup from virtio
0d3a761398 pc-bios/s390-ccw: Use proper register names for Clang

[Christian Ehrhardt  (paelzer)]

Thanks for that list Dimitri.

FYI - Qemu 4.0 merge was postponed a few times for other interrupts, due to that it will still take a while to get this - especially back into much older releases depending on how much more changes we will need there.

[Christian Ehrhardt  (paelzer)]

FYI 796588ba1 is actually d796588ba13b9d9301433bdf4e461ad5e60d9796

[Christian Ehrhardt  (paelzer)]

In the PPA [1] is a preliminary build of a qemu 4.0 for Ubuntu 19.10.
This is still being tested, but a confirmation that this brings all the z14 related changes that you expect would be great - so I wanted to ask to test the PPA in regard to this bug here "KVM: Secure Linux Boot Toleration - qemu".

[1]: https://launchpad.net/~paelzer/+archive/ubuntu/qemu-4.0-eoan-v2

[Launchpad Janitor (janitor)]

This bug was fixed in the package qemu - 1:4.0+dfsg-0ubuntu1

---------------
qemu (1:4.0+dfsg-0ubuntu1) eoan; urgency=medium

  * Merge with Upstream release of qemu 4.0.
    Among many other things this fixes LP Bugs:
    LP: #1782206 - SnowRidge Accelerator Interfacing Architecture (AIA)
    LP: #1828038 - Update s390x CPU Model for more HW support
    LP: #1832622 - count cache flush Spectre v2 mitigation for ppc64el
    Remaining Changes:
    - qemu-kvm to systemd unit
      - d/qemu-kvm-init: script for QEMU KVM preparation modules, ksm,
        hugepages and architecture specifics
      - d/qemu-system-common.qemu-kvm.service: systemd unit to call
        qemu-kvm-init
      - d/qemu-system-common.install: install helper script
      - d/qemu-system-common.maintscript: clean old sysv and upstart scripts
      - d/qemu-system-common.qemu-kvm.default: defaults for
        /etc/default/qemu-kvm
      - d/rules: call dh_installinit and dh_installsystemd for qemu-kvm
    - Enable nesting by default
      - d/qemu-system-x86.modprobe: set nested=1 module option on intel.
        (is default on amd)
      - d/qemu-system-x86.postinst: re-load kvm_intel.ko if it was loaded
        without nested=1
      - d/p/ubuntu/expose-vmx_qemu64cpu.patch: expose nested kvm by default
        in qemu64 cpu type.
      - d/p/ubuntu/enable-svm-by-default.patch: Enable nested svm by default
        in qemu64 on amd
      - d/qemu-system-x86.README.Debian: document intention of nested being
        default is comfort, not full support
    - Distribution specific machine type (LP: 1304107 1621042)
      - d/p/ubuntu/define-ubuntu-machine-types.patch: define distro machine
        types
      - d/qemu-system-x86.NEWS Info on fixed machine type defintions
        for host-phys-bits=true (LP: 1776189)
      - add an info about -hpb machine type in debian/qemu-system-x86.NEWS
      - provide pseries-bionic-2.11-sxxm type as convenience with all
        meltdown/spectre workarounds enabled by default. (LP: 1761372).
    - improved dependencies
      - Make qemu-system-common depend on qemu-block-extra
      - Make qemu-utils depend on qemu-block-extra
      - let qemu-utils recommend sharutils
    - s390x support
      - Create qemu-system-s390x package
      - Enable numa support for s390x
    - arch aware kvm wrappers
    - d/control: update VCS links
    - qemu-guest-agent: freeze-hook fixes (LP: 1484990)
      - d/qemu-guest-agent.install: provide /etc/qemu/fsfreeze-hook
      - d/qemu-guest-agent.dirs: provide /etc/qemu/fsfreeze-hook.d
    - d/control-in: enable RDMA support in qemu (LP: 1692476)
        - enable RDMA config option
        - add libibumad-dev build-dep
    - tolerate ipxe size change on migrations to >=18.04 (LP: 1713490)
      - d/p/ubuntu/pre-bionic-256k-ipxe-efi-roms.patch: old machine types
        reference 256k path
      - d/control-in: depend on ipxe-qemu-256k-compat-efi-roms to be able to
        handle incoming migrations from former releases.
    - d/control-in: Disable capstone disassembler library support (universe)
    - Move s390x roms to a new qemu-system-data-s390x
      - d/qemu-system-data.install: install s390x roms as archi...

[Christian Ehrhardt  (paelzer)]

Ok, now that things are in Eoan how do we want to work on the SRUs.
Dimitri already identified quite a lot of changes on top of 3.1 in comment #5.
I can only assume that this will get worse and worse further back.

will IBM provide branches or patches for qemu 2.5, 2.11 and 3.1 or should I give things a try starting with the list in comment #5 and someone will check against a PPA, or ... ?

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2019-07-04 05:29 EDT-------
The commits identified by Dmitry are mostly for IPLing from a dasd attached via vfio-ccw.
I cannot say right now if we want that feature also for disco,cosmic and bionic.
If not we can simply focus on just the secure boot toleration, we can limit ourselves to

commit 2497b4a3c08426122d1a89b808c669a734469e5a
Author: Jason J. Herne <email address hidden>
AuthorDate: Mon Apr 29 09:09:41 2019 -0400
Commit: Thomas Huth <email address hidden>
CommitDate: Wed May 8 10:52:14 2019 +0200

s390-bios: Skip bootmap signature entries

and of course the rebuild of the s390-ccw.img binary.

It seems that this patch applies cleanly on top of 2,5, 2.11 and 3.1. This means we just need to double check if it builds and runs

[Dimitri John Ledkov (xnox)]

I also wonder if we need secureboot toleration patches in zipl for xenial+ (when it has no signed stage3.bin)

Specifically, it should strip secureboot signatures off kernels or otherwise things might not boot.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2019-07-04 08:02 EDT-------
While I'd expect that the combination of a newer guest under an older hypervisor will not be that common, it would probably not hurt to SRU this. If you do, don't forget the OpenStack QEMUs.

[Christian Ehrhardt  (paelzer)]

Yeah lets focus on 2497b4a3 "s390-bios: Skip bootmap signature entries" here then.
If ever "IPLing from a dasd attached via vfio-ccw" is wanted that would be an extra bug/discussion.
Thanks Christian B. for pointing to the core change of this bug!

That way it applies as-is to 3.1, with very slight noise to 2.11 and even 2.5.
Started test builds in [1] as a PPA to evaluate.

Who has s390x test kernels with secure boot enabled available to give this a try?
Marking the bug tasks incomplete until that has been verified.

For formal review MPs are up [2][3][4] as well.

P.S. Cosmic will be EOL until this reaches the SRU queues. Not preparing that.

[1]: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1830243-secure-boot-toleration
[2]: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/369709
[3]: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/369710
[4]: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/369711

[Dimitri John Ledkov (xnox)]

I have access to secureboot signed zipl & kernels. I will prepare a sample cloud-image to test boot with all the qemus.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2019-07-04 10:32 EDT-------
You can actually try to test that yourself by having a guest that has a very new zipl
(this commit or newer)
https://github.com/ibm-s390-tools/s390-tools/commit/6ea645b3453264a0f1a60955c4476dab54035f88
(s390-tools 2.9 will be good enough).

and the override the detection (--secure 1) and let zipl write such a boot record.

[Christian Ehrhardt  (paelzer)]

Thanks Christian, but when doing so I get:

$ cat /etc/zipl.conf
# This has been modified by the cloud image build process
[defaultboot]
default=ubuntu

[ubuntu]
target = /boot
secure = 1
image = /boot/vmlinuz
parameters = root=LABEL=cloudimg-rootfs
ramdisk = /boot/initrd.img

$ sudo zipl -V
Using config file '/etc/zipl.conf'
Target device information
  Device..........................: fc:00
  Partition.......................: fc:01
  Device name.....................: vda
  Device driver name..............: virtblk
  Type............................: disk partition
  Disk layout.....................: SCSI disk layout
  Geometry - start................: 2048
  File system block size..........: 4096
  Physical block size.............: 512
  Device size in physical blocks..: 16775135
Building bootmap in '/boot'
Adding IPL section 'ubuntu' (default)
  initial ramdisk...: /boot/initrd.img
  signature for.....: /lib/s390-tools/stage3.bin
  kernel image......: /boot/vmlinuz
Error: Could not install Secure Boot IPL records: Missing signature in image file /boot/vmlinuz

So do I really not need a kernel with a signature?
If so how to avoid the break on the missing signature?

@Dimitri - I found none in the archive yet, do you have signed s390x kernel around that could be used?

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2019-07-05 06:10 EDT-------
Yes, you do need a signed key. For the purpose of QEMU testing maybe you can use the sign_file tool from the kernel to have a signed kernel.

[Christian Ehrhardt  (paelzer)]

Got signed kernels from xnox in [1].
With those they zipl

Using config file '/etc/zipl.conf'
Target device information
  Device..........................: fc:00
  Partition.......................: fc:01
  Device name.....................: vda
  Device driver name..............: virtblk
  Type............................: disk partition
  Disk layout.....................: SCSI disk layout
  Geometry - start................: 2048
  File system block size..........: 4096
  Physical block size.............: 512
  Device size in physical blocks..: 16775135
Building bootmap in '/boot'
Adding IPL section 'ubuntu' (default)
  initial ramdisk...: /boot/initrd.img-5.2.0-1-generic
  signature for.....: /lib/s390-tools/stage3.bin
  kernel image......: /boot/vmlinuz-5.2.0-1-generic
  signature for.....: /boot/vmlinuz-5.2.0-1-generic
  kernel parmline...: 'root=LABEL=cloudimg-rootfs'
  component address:
    heap area.......: 0x00002000-0x00005fff
    stack area......: 0x0000f000-0x0000ffff
    internal loader.: 0x0000a000-0x0000efff
    parameters......: 0x00009000-0x000091ff
    kernel image....: 0x00010000-0x004b8fff
    parmline........: 0x004ba000-0x004ba1ff
    initial ramdisk.: 0x004c0000-0x01622bff
Preparing boot device: vda (0000).
Detected SCSI PCBIOS disk layout.
Writing SCSI master boot record.
Syncing disks...
Done.

With that starting the guest gave either
  2019-07-05 10:17:06.535+0000: shutting down, reason=crashed
or
  ! No EXEC entry !

With the qemu from PPA [2] things work again.
I can go forward with the SRU on this, thanks for your help everybody.

P.S. I have a few other changes I want to bundle, so I beg your pardon for a few days extra delay. But this isn't urgent until the signed kernels would land so that should be ok.

[1]: https://launchpad.net/~xnox/+archive/ubuntu/scratch
[2]: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1830243-secure-boot-toleration

[Christian Ehrhardt  (paelzer)]

Tags pushed and uploaded to X/B/D unapproved for the SRU Team to do a final review and accept.

[Brian Murray (brian-murray)]

Hello bugproxy, or anyone else affected,

Accepted qemu into disco-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:3.1+dfsg-2ubuntu3.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-disco to verification-done-disco. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-disco. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Brian Murray (brian-murray)]

Hello bugproxy, or anyone else affected,

Accepted qemu into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:2.11+dfsg-1ubuntu7.16 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Brian Murray (brian-murray)]

Hello bugproxy, or anyone else affected,

Accepted qemu into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:2.5+dfsg-5ubuntu10.41 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Łukasz Zemczak (sil2100)]

All autopkgtests for the newly accepted qemu (1:2.11+dfsg-1ubuntu7.16) for bionic have finished running.
There have been regressions in tests triggered by the package. Please visit the sru report page and investigate the failures.

https://people.canonical.com/~ubuntu-archive/pending-sru.html#bionic

[Rafael David Tinoco (rafaeldtinoco)]

All errors are timeout errors when trying to access armhf archive:

# libvirt armhf:

The following packages will be upgraded:
  apt apt-transport-https apt-utils bash binutils binutils-arm-linux-gnueabihf
  binutils-common bzip2 console-setup console-setup-linux dbus debconf
  debconf-i18n distro-info-data dmsetup gcc-8-base initramfs-tools
  initramfs-tools-bin initramfs-tools-core isc-dhcp-client isc-dhcp-common
  keyboard-configuration libapt-inst2.0 libapt-pkg5.0 libbinutils libbz2-1.0
  libdb5.3 libdbus-1-3 libdevmapper1.02.1 libdns-export1100 libelf1 libexpat1
  libgcc1 libglib2.0-0 libglib2.0-data libgnutls30 libisc-export169
  libldap-2.4-2 libldap-common libnss-systemd libpam-systemd
  libpython3.6-minimal libpython3.6-stdlib libseccomp2 libsqlite3-0 libssl1.1
  libstdc++6 libsystemd0 libudev1 linux-headers-generic login netplan.io nplan
  openssl passwd python3.6 python3.6-minimal systemd systemd-sysv tzdata
  ubuntu-minimal udev vim-common vim-tiny xxd
65 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 35.3 MB of archives.
After this operation, 85.9 MB of additional disk space will be used.
Err:1 http://ftpmaster.internal/ubuntu bionic-updates/main armhf bash armhf 4.4.18-2ubuntu1.2
  Could not connect to ftpmaster.internal:80 (91.189.89.99), connection timed out

----

## nova armhf:

The following packages will be upgraded:
  apt apt-transport-https apt-utils bash binutils binutils-arm-linux-gnueabihf
  binutils-common bzip2 console-setup console-setup-linux dbus debconf
  debconf-i18n distro-info-data dmsetup gcc-8-base initramfs-tools
  initramfs-tools-bin initramfs-tools-core isc-dhcp-client isc-dhcp-common
  keyboard-configuration libapt-inst2.0 libapt-pkg5.0 libbinutils libbz2-1.0
  libdb5.3 libdbus-1-3 libdevmapper1.02.1 libdns-export1100 libelf1 libexpat1
  libgcc1 libglib2.0-0 libglib2.0-data libgnutls30 libisc-export169
  libldap-2.4-2 libldap-common libnss-systemd libpam-systemd
  libpython3.6-minimal libpython3.6-stdlib libseccomp2 libsqlite3-0 libssl1.1
  libstdc++6 libsystemd0 libudev1 linux-headers-generic login netplan.io nplan
  openssl passwd python3.6 python3.6-minimal systemd systemd-sysv tzdata
  ubuntu-minimal udev vim-common vim-tiny xxd
65 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 35.3 MB of archives.
After this operation, 85.9 MB of additional disk space will be used.
Err:1 http://ftpmaster.internal/ubuntu bionic-updates/main armhf bash armhf 4.4.18-2ubuntu1.2
  Could not connect to ftpmaster.internal:80 (91.189.89.99), connection timed out

----

## systemd armhf:

The following packages will be upgraded:
  apt apt-transport-https apt-utils bash binutils binutils-arm-linux-gnueabihf
  binutils-common bzip2 console-setup console-setup-linux dbus debconf
  debconf-i18n distro-info-data dmsetup gcc-8-base initramfs-tools
  initramfs-tools-bin initramfs-tools-core isc-dhcp-client isc-dhcp-common
  keyboard-configuration libapt-inst2.0 libapt-pkg5.0 libbinutils libbz2-1.0
  libdb5.3 libdbus-1-3 libdevmapper1.02.1 libdns-export1100 libelf1 libexpat1
  libgcc1 libglib2.0-0 libglib2.0-data libgnutls30 libisc-export169
  libldap-2.4-2 libldap-common libnss-s...

[Rafael David Tinoco (rafaeldtinoco)]

I asked someone with permissions to restart those tests to check if timeout issue is gone.

[Łukasz Zemczak (sil2100)]

All autopkgtests for the newly accepted qemu (1:3.1+dfsg-2ubuntu3.3) for disco have finished running.
There have been regressions in tests triggered by the package. Please visit the sru report page and investigate the failures.

https://people.canonical.com/~ubuntu-archive/pending-sru.html#disco

[Christian Ehrhardt  (paelzer)]

1. Installed an Eoan guest on Xenial/Bionic/Disco hosts
In the Guest
2. set secure = 1 in /etc/zipl.conf

3. unfortunately xnox refreshed his PPA and it has no pre-signed kernel anymore :-/
   I tried to follow https://ubuntu.com/blog/how-to-sign-things-for-secure-boot in various ways,
   but I assume things are just different for s390x here.
   After a while I found this old build [1] of which I used [2]
   Install that and drop the ramdisk line
  change:
    image = /boot/vmlinuz-5.2.0-1-generic
  remove:
    ramdisk = /boot/initrd.img

4. run zipl verbosely, which should have:
  Adding IPL section 'ubuntu' (default)
  signature for.....: /lib/s390-tools/stage3.bin
  kernel image......: /boot/vmlinuz-5.2.0-1-generic
  signature for.....: /boot/vmlinuz-5.2.0-1-generic

5. shut down guest

6. back in the Host, start the guest (fails without the update).
   Check the console - the error messages differ per version:

Xenial:
$ virsh start --console test-secureboot-x
Domain test-secureboot-x started
Connected to domain test-secureboot-x
Escape character is ^]
..
  ! No EXEC entry !

Bionic:
Domain test-secureboot-b started
error: The domain is not running

Disco:
seems to work but complains about validations

7. Upgrade to proposed and check again.

qemu-system-s390x/disco-proposed 1:3.1+dfsg-2ubuntu3.3 s390x [upgradable from: 1:3.1+dfsg-2ubuntu3.2]
qemu-kvm/bionic-proposed 1:2.11+dfsg-1ubuntu7.16 s390x [upgradable from: 1:2.11+dfsg-1ubuntu7.15]
qemu-system-s390x/bionic-proposed 1:2.11+dfsg-1ubuntu7.16 s390x [upgradable from: 1:2.11+dfsg-1ubuntu7.15]
qemu-system-s390x/xenial-proposed 1:2.5+dfsg-5ubuntu10.41 s390x [upgradable from: 1:2.5+dfsg-5ubuntu10.40]

With the upgrade from proposed they all can start fine (well I stole the initrd, so they fail mounting the root disk, but we passed hat we wanted to check).

Setting verified

[1]: https://launchpad.net/~xnox/+archive/ubuntu/scratch/+build/16859505
[2]: https://launchpad.net/~xnox/+archive/ubuntu/scratch/+build/16859505/+files/linux-image-5.2.0-1-generic_5.2.0-1.2_s390x.deb

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for qemu has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package qemu - 1:2.5+dfsg-5ubuntu10.41

---------------
qemu (1:2.5+dfsg-5ubuntu10.41) xenial; urgency=medium

  * d/p/ubuntu/lp-1830243-s390-bios-Skip-bootmap-signature-entries.patch:
    tolerate guests with secure boot loaders (LP: #1830243)

 -- Christian Ehrhardt <email address hidden> Thu, 04 Jul 2019 14:47:56 +0200

[Robie Basak (racb)]

Hello bugproxy, or anyone else affected,

Accepted qemu into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:2.11+dfsg-1ubuntu7.17 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Christian Ehrhardt  (paelzer)]

Just checked on s1lp05 - this one still works as before (as expected as we didn't change it in this fixup upload).

[Launchpad Janitor (janitor)]

This bug was fixed in the package qemu - 1:3.1+dfsg-2ubuntu3.3

---------------
qemu (1:3.1+dfsg-2ubuntu3.3) disco; urgency=medium

  [ Christian Ehrhardt ]
  * d/p/ubuntu/lp-1830243-s390-bios-Skip-bootmap-signature-entries.patch:
    tolerate guests with secure boot loaders (LP: #1830243)

  [ Rafael David Tinoco ]
  * {Ice,Cascade}Lake CPUs IA32_ARCH_CAPABILITIES support (LP: #1828495)
    Needed patches are in d/p/u/lp1828495-:
    - 0011-disable-arch-cap-when-no-msr.patch (LP: #1828495):
      i386: kvm: Disable arch_capabilities if MSR can't be set
    - 0012-arch-capabilities-migratable.patch (LP: #1828495):
      i386: Make arch_capabilities migratable
    - 0014-remove-cpuid-pconfig.patch
      i386: remove the new CPUID 'PCONFIG' from Icelake-Server CPU model
    - 0015-remove-cpuid-intel_pt.patch
      i386: remove the 'INTEL_PT' CPUID bit from named CPU models
    - 0016-no-ospke-on-some.patch (LP: #1828495):
      i386: Disable OSPKE on CPU model definitions

 -- Christian Ehrhardt <email address hidden> Thu, 04 Jul 2019 14:47:56 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package qemu - 1:2.11+dfsg-1ubuntu7.17

---------------
qemu (1:2.11+dfsg-1ubuntu7.17) bionic; urgency=medium

  * {Ice,Cascade}Lake IA32_ARCH_CAPABILITIES support (LP: 1828495)
    Needed patch is in d/p/u/lp1828495-:
    - 0017-target-i386-add-MDS-NO-feature.patch:
      target/i386: add MDS-NO feature

qemu (1:2.11+dfsg-1ubuntu7.16) bionic; urgency=medium

  [ Christian Ehrhardt ]
  * d/p/ubuntu/lp-1830243-s390-bios-Skip-bootmap-signature-entries.patch:
    tolerate guests with secure boot loaders (LP: #1830243)

  [ Rafael David Tinoco ]
  * {Ice,Cascade}Lake CPUs + IA32_ARCH_CAPABILITIES support (LP: #1828495)
    Needed patches are in d/p/u/lp1828495-:
    - 0001-guidance-cpu-models.patch:
      docs: add guidance on configuring CPU models for x86
      + d/qemu-system-common.install: include man/man7/qemu-cpu-models.7
    - 0002-msr-new-msr-indices.patch:
      i386: Add new MSR indices for IA32_PRED_CMD and IA32_ARCH_CAPABILITIES
    - 0003-cpuid-feature-ia32-arch-capabilities.patch:
      i386: Add CPUID bit and feature words for IA32_ARCH_CAPABILITIES MSR
    - 0004-cpuid-bit-for-wbnoinvd.patch:
      i386: Add CPUID bit for WBNOINVD
    - 0005-new-cpu-model-for-icelake.patch:
      i386: Add new CPU model Icelake-{Server,Client}
    - 0006-update-headers-to-4.16-rc5.patch:
      update Linux headers to 4.16-rc5
    - 0007-kvm-get-msr-feature-index_list.patch:
      kvm: Add support to KVM_GET_MSR_FEATURE_INDEX_LIST and
    - 0008-x86-msr-related-data-structure-changes.patch:
      x86: Data structure changes to support MSR based features
    - 0009-feature-wordS-arch-capabilities.patch:
      x86: define a new MSR based feature word -- FEATURE_WORDS_ARCH
    - 0010-use-kvm-get-msr-index-list.patch:
      kvm: Use KVM_GET_MSR_INDEX_LIST for MSR_IA32_ARCH_CAPABILITIES support
    - 0011-disable-arch-cap-when-no-msr.patch:
      i386: kvm: Disable arch_capabilities if MSR can't be set
    - 0012-arch-capabilities-migratable.patch:
      i386: Make arch_capabilities migratable
    - 0013-cascadelake-server.patch:
      i386: Add new model of Cascadelake-Server
    - 0014-remove-cpuid-pconfig.patch:
      i386: remove the new CPUID 'PCONFIG' from Icelake-Server CPU model
    - 0015-remove-cpuid-intel_pt.patch:
      i386: remove the 'INTEL_PT' CPUID bit from named CPU models
    - 0016-no-ospke-on-some.patch:
      i386: Disable OSPKE on CPU model definitions

 -- Rafael David Tinoco <email address hidden> Mon, 05 Aug 2019 19:12:08 +0000

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2019-08-14 03:38 EDT-------
IBM Bugzilla status -> closed, Fix Released with Eoan