[Bug 1877089] Comment bridged from LTC Bugzilla

[bugproxy]

------- Comment From PRudo at de.ibm.com 2020-05-20 07:39 EDT-------
(In reply to comment #14)
> Thank you for those details.
>
> For example, if and when we bump ubuntu minimum abi to z15 we might be able
> to kill the zfcpdump kernel.

That's at least my hope. There's an other problem I keep forgetting.
Currently only LPAR has the bigger HSA size. z/VM has to emulate the HSA
and cannot cope with the bigger size yet. Not sure if/how KVM handles
this. So simply bumping the ALS won't be enough. You still need to keep
an eye on the hypervisors...

> If there are no modules i guess any initrd will not be able to do
much.

Actually my hope is we find a way to get it work with the standad kernel
+ kdump initrd. So basically getting a firmware assisted kdump.

------- Comment From PRudo at de.ibm.com 2020-05-20 07:41 EDT-------
I also played around a little bit more with zfcpdump + secure boot and I'm no longer sure that simply signing the zfcpdump kernel is enough. There might also be a bug in zipl. But that needs further investigation.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to s390-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1877089

Title:
  zfcpdump kernel can not be IPLed when secure boot is requested

Status in Ubuntu on IBM z Systems:
  Triaged
Status in s390-tools package in Ubuntu:
  Invalid
Status in zfcpdump-kernel package in Ubuntu:
  Confirmed
Status in zfcpdump-kernel source package in Focal:
  Confirmed
Status in zfcpdump-kernel source package in Groovy:
  Confirmed

Bug description:
  I installed Ubuntu 20.04 on IBM z15 with secure=1 in zipl conf.
  System can be secure booted, /sys/firmware/ipl/secure shows "1".
  I prepared zfcp dump disk as described in LTC bug 185713.
  Stopped the system and performed a SCSI dump with "Enable Secure Boot for Linux" enabled.

  Operating System Messages on HMC:
  Preparing system.
  Starting system.
  System version 8.
  Watchdog enabled.
  Running 'ZBootLoader' version '1.0.0' level 'D41C.D41C_0014'.
  ZBootLoader 2.1.0.
  MLOLOA6269064E Secure IPL: There are no signed components available on device HB
  A=0.0.1800, WWPN=500507630309D327, LUN=4046400900000000.
  IPL failed.

  Without "Enable Secure Boot for Linux" the dump kernel was IPLed and a
  dump created.

  Then I tried to rewrite the zfcp dump kernel with explicite setting of --secure=1:
  root at t35lp25:~# zipl --secure=1 -d /dev/disk/by-id/scsi-36005076303ffd3270000000000004609-part1
  Building bootmap directly on partition '/dev/disk/by-id/scsi-36005076303ffd3270000000000004609-part1'
  Adding dump section
    initial ramdisk...: /lib/s390-tools/zfcpdump/zfcpdump-initrd
    kernel image......: /lib/s390-tools/zfcpdump/zfcpdump-image
    kernel parmline...: 'root=/dev/ram0 dump_mem=1 possible_cpus=1 cgroup_disable=memory '
    component address:
      heap area.......: 0x00002000-0x00005fff
      stack area......: 0x0000f000-0x0000ffff
      internal loader.: 0x0000a000-0x0000dfff
      parameters......: 0x00009000-0x000091ff
      kernel image....: 0x00010000-0x001b9fff
      parmline........: 0x001ba000-0x001ba1ff
      initial ramdisk.: 0x001c0000-0x0020edff
  Preparing boot device: sde.
  Done.

  ...and tried to SCSI dump this device again. But the same  failure occured.
  Again, without "Enable Secure Boot for Linux" the dump kernel was IPLed and a dump created.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1877089/+subscriptions