Ubuntu Kernel Support for OpenPOWER NV Secure & Trusted Boot

[bugproxy]

== Comment: #0 - George C. Wilson <email address hidden> - 2020-02-25 18:40:44 ==
- sysfs enablement: TBD
- ima: arch specific policy support 6191706246de
- platform keyring changes for powerpc: TBD
- Appended signatures support for IMA appraisal 39b07096364a42c516415d5f841069e885234e61
- integrity: Define a trusted platform keyring: 9dc92c45177a
- ima: Support platform keyring for kernel appraisal: d7cecb676dd3
- TPM 2.0 Multibank extend support: c1f92b4b04ad
- TPM 2.0 Eventlog support: 4d23cc323cdb
- ima: carry the measurement list across kexec: d68a6fe9fccf
- kexec_file_load system call support: 500c7ab1a9db

[Frank Heimes (fheimes)]

I had a first glimpse at the patches/commits, and found out that:

The following commits are already in 'focal' aka 20.04 (even in master, hence they are in the current focal kernel):
8c655784e2cf "integrity: Define a trusted platform keyring"
f218a29c25ad "ima: Support platform keyring for kernel appraisal"
467d27824920 "ima: carry the measurement list across kexec"
So these can be considered as done.

The following commits are yet neither in the linux tree, nor in linux-next:
"ima: arch specific policy support"
"Appended signatures support for IMA appraisal"
"TPM 2.0 Multibank extend support"
"TPM 2.0 Eventlog support"
"kexec_file_load system call support"
I assume they are currently on a staging tree?!

And the two TBDs are not ready, yet, but probably in the works.

Please notice that the patches need to be upstream (accepted) for Canonical to be able to pick them up.
And they need to apply cleanly on top of the target kernel's master-next tree (in this case 'focal' master-next):
git clone https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal --branch master-next --single-branch focal-master-next

Due to the fact that there seems to be still some work needed,
and because the patches look pretty significant and touch common-code
and that we are already quite late in the 'focal' development cycle,
I'm not sure if it will be possible to get them into the initial release version of 20.04.
But at the end it depends on the (upstream) availability and the Canonical kernel team.

As soon as all commits/patches are available and apply cleanly,
I'll submit a request to the Canonical kernel team's mailing list and a decision will finally be made by the kernel team.
For now I'm setting the status to Incomplete.

[Frank Heimes (fheimes)]

When I earlier looked-up the commits listed here in the bug description via their 'commit name', I found some but not all of them. (I prefer looking up commits via it's name rather than via their hash, since depending on the git tree they come from [upstream, ubuntu, etc.] hashes can be different).
It turned out that some of the descriptions next to the hashes above are the xact descriptions, other are not.

Doing another lookup in the focal master tree - now with the exact names - I was able to find the additional 5 commits:
$ git log --oneline --grep "ima: add support for arch specific policies"
6191706246de ima: add support for arch specific policies
$ git log --oneline --grep "ima: Implement support for module-style appended signatures"
39b07096364a ima: Implement support for module-style appended signatures
$ git log --oneline --grep "tpm: enhance TPM 2.0 PCR extend to support multiple banks"
c1f92b4b04ad tpm: enhance TPM 2.0 PCR extend to support multiple banks
$ git log --oneline --grep "tpm: add securityfs support for TPM 2.0 firmware event log"
4d23cc323cdb tpm: add securityfs support for TPM 2.0 firmware event log
$ git log --oneline --grep "powerpc: Enable CONFIG_KEXEC_FILE in powerpc server defconfigs."
500c7ab1a9db powerpc: Enable CONFIG_KEXEC_FILE in powerpc server defconfigs.

May I ask about the status of the two commits marked at tbd?
Are they ready, ideally already upstream / in 'linux-next'?

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-03-23 19:45 EDT-------
Hi Frank,

That's what I see, too, and all of those are in focal already, along with the other three whose titles matched. The config options in 500c7ab1a9db are already on in focal, too.

The ones we're not sure of are these two TBD ones:
sysfs enablement: TBD
platform keyring changes for powerpc: TBD

I think Nanya can confirm and add TBD ids.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-03-27 10:00 EDT-------
Below is the list of commits for specified TBDs (sysfs enablement/platform keyring changes for powerpc):. These were upstreamed in kernel v5.5 version.

Platform Keyring changes for powerpc:
8220e22 - powerpc: Load firmware trusted keys/hashes into kernel keyring
ad72367 - x86/efi: move common keyring handler functions to new file
bd5d9c7 - powerpc: expose secure variables to userspace via sysfs
9155e23 - powerpc/powernv: Add OPAL API interface to access secure variable
39a963b - sysfs: Fixes __BIN_ATTR_WO() macro

sysfs enablement:
d72ea49 - powerpc/ima: Indicate kernel modules appended signatures are enforced
dc87f18 - powerpc/ima: Update ima arch policy to check for blacklist
273df86 - ima: Check against blacklisted hashes for files with modsig
2434f7d - certs: Add wrapper function to check blacklisted binary hash
e14555e - ima: Make process_buffer_measurement() generic
1917855 - powerpc/ima: Define trusted boot policy
2702809 - powerpc: Detect the trusted boot state of the system
4238fad - powerpc/ima: Add support to initialize ima policy rules
1a8916e - powerpc: Detect the secure boot mode of the system
82af5b6 - sysfs: Fixes __BIN_ATTR_WO() macro

May I ask the kernel version that Ubuntu will be using for 20.04 ?

Thanks & Regards,
- Nayna

[Frank Heimes (fheimes)]

That is a significant list for patches - are they all > 5.4? (I'll look them up ...)
Ubuntu Server 20.04 will be shipped with a kernel 5.4 - and beta is planned to be released on April 2nd (so next Thursday) - things are largely freezed already.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-03-27 11:57 EDT-------
Ok. Thanks for sharing the info.

These ones should be very straightforward to backport.

Thanks & Regards,
- Nayna

[Dimitri John Ledkov (xnox)]

"May I ask the kernel version that Ubuntu will be using for 20.04 ?"

I see this getting asked a lot on both Power and Z tickets, I thought Ubuntu communicated way back in November 2019 to everyone that we will ship linux-generic in 20.04 based on v5.4 kernel.

Is this not been clear? or are there any teams working on Power or Z that need this reiterated? Where should this be communicated, such that it no longer is a question?

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-03-30 11:56 EDT-------
I am sorry for the repetition on this question.

Thanks & Regards,
- Nayna

[Frank Heimes (fheimes)]

Hi Nayna, we talked about that with Michael Ranweiler in a call today.
And we will also discuss with the Canonical kernel team about the options that exist - stay tuned.

[Frank Heimes (fheimes)]

The kernel team was so kind to create a test kernel in this PPA:
https://launchpad.net/~sforshee/+archive/ubuntu/lp1866909
Please give it a thoroughly test on short notice!
Thank you

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-04-01 18:31 EDT-------
Thank you for spinning that so quickly. We neglected to request these config options get turned on:
CONFIG_PPC_SECURE_BOOT=y
CONFIG_PPC_SECVAR_SYSFS=y
CONFIG_LOAD_PPC_KEYS=y
CONFIG_IMA_READ_POLICY=y
CONFIG_IMA_ARCH_POLICY=y

We did enable those and rebuilt the kernel and that seems to allow the basics to work (ie, policies are there). We'll do some more testing on it.

The signing key - our systems don't have same chain of trust and the key needs to be added to the firmware. Can you direct us to that, please?

[Frank Heimes (fheimes)]

The test/dev key that was used to sign the kernel from this PPA is itself also part of the PPA.
Find the PPA archive URL (aka 'deb-line') by browsing the landing page of this PPA:
https://launchpad.net/~sforshee/+archive/ubuntu/lp1866909
The URL ('deb-line') is: http://ppa.launchpad.net/sforshee/lp1866909/ubuntu
and follow that via '/dists/focal/main/signed/linux-ppc64el/current/' and you will find the key here (incl. checksum):
http://ppa.launchpad.net/sforshee/lp1866909/ubuntu/dists/focal/main/signed/linux-ppc64el/current/
The key file itself is:
http://ppa.launchpad.net/sforshee/lp1866909/ubuntu/dists/focal/main/signed/linux-ppc64el/current/signed.tar.gz
(extract for example with 'tar xf')

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-04-02 10:34 EDT-------
Thank you, I grabbed that.

Is there any chance of a PPA respin with those options? We did test on our rebuild, but we can't completely test without those options on plus the signing.

[Frank Heimes (fheimes)]

Yes, Seth was so kind to already trigger a new build - it has the config ootions in (and I think also the patches from LP 1855668, comment #19 and #10).
If you refresh https://launchpad.net/~sforshee/+archive/ubuntu/lp1866909
you should now see the newer version: 5.4.0-21.25+lp1866909v202004020814 (time stamp April 2nd)

[Seth Forshee (sforshee)]

Note that it is still building, should be ready in a few hours. I'll post an update when it is done.

[Seth Forshee (sforshee)]

Build is done now, version 5.4.0-21.25+lp1866909v202004020814 in https://launchpad.net/~sforshee/+archive/ubuntu/lp1866909/+packages.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-04-02 17:37 EDT-------
Thank you! I saw it finished and grabbed it, I saw it had the latest from lp 1855668.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-04-02 21:53 EDT-------
The kernel seems to be having the secure boot functions after enabling those CONFIGs. Now, I was trying to boot to this kernel when secure boot is enabled.

I have taken the key from here -
ppa.launchpad.net/sforshee/lp1866909/ubuntu/dists/focal/main/signed/linux-ppc64el/current/signed.tar.gz

I have taken opal.x509 in the control directory as the key.

The secure boot is enabled "os-secure-enforcing" and .platform has loaded the key.

# cd /proc/device-tree/ibm,secureboot/
# ls
compatible ibm,cvc phandle
hw-key-hash name secure-enabled
hw-key-hash-size os-secureboot-enforcing trusted-enabled
# keyctl show %keyring:.platform
Keyring
337432176 ---lswrv 0 0 keyring: .platform
471022331 ---lswrv 0 0 \_ asymmetric: DB: e6b84e62dbbd988abbfda008355aa6a08001c58c

However, it seems the verification is failing as shown below:
# kexec -s /var/petitboot/mnt/dev/sdb6/boot/vmlinux-5.4.0-21-generic
file_load failed: Permission denied

I have two questions:
* I hope the key is right.
* I hope the signature is not stored as detached file because that is how I saw it in - ppa.launchpad.net/sforshee/lp1866909/ubuntu/dists/focal/main/signed/linux-ppc64el/current/signed.tar.gz.

Please confirm. I will continue to look at it more.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-04-03 00:35 EDT-------
With Michael's help, I could get the right key for the kernel.
I updated the new key and then tried booting to signed kernel in secure boot enabled state.

It seems kernel is being verified.
# kexec -l /var/petitboot/mnt/dev/sdb6/boot/vmlinux-5.4.0-21-generic
kexec syscall failed: Permission denied ----> Expected to fail as insecure load is disabled during secure boot

# kexec -s /var/petitboot/mnt/dev/sdb6/boot/vmlinux-5.4.0-21-generic
# dmesg | tail -f
[ 9.573882] IPv6: ADDRCONF(NETDEV_CHANGE): enP5p1s0f0: link becomes ready
[ 94.085611] ima: impossible to appraise a kernel image without a file descriptor; try using kexec_file_load syscall.
[ 94.085615] ima: impossible to appraise a kernel image without a file descriptor; try using kexec_file_load syscall.
[ 102.049306] ima dump: 01 00 00 00 00 00 00 00 fd 1c 00 00 00 00 00 00 ................
[ 102.049308] ima dump: 28 00 00 00 00 00 00 00 0a 00 00 00 bc b0 e5 18 (...............
[ 102.049309] ima dump: b7 9d e0 d7 f2 cd 20 b8 a2 9a 70 92 e6 5d b7 ef ...... ...p..]..
[ 102.049310] ima dump: 07 00 00 00 69 6d 61 2d 73 69 67 35 00 00 00 1a ....ima-sig5....
[ 102.049310] ima dump: 00 00 00 73 68 61 31 3a 00 00 00 00 00 00 00 00 ...sha1:........
[ 102.049311] ima dump: 00 00 00 00 00 00 00 00 00 00 00 00 00 0f 00 00 ................
[ 102.049312] ima dump: 00 62 6f 6f .boo

However, it failed on doing kexec -e.
It failed at:

[ 42.315484] kexec_core: Starting new kernel
Gave up waiting for root file system device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! UUID=49d000cb-dba2-4d70-809e-38f2b31d0f09 does not exist. Dropping to a shell!
BusyBox v1.30.1 (Ubuntu 1:1.30.1-4ubuntu5) built-in shell (ash)
Enter 'help' for a list of built-in commands.
(initramfs)

Michael investigated that it seems modules are not getting loaded. He looked for the modules and they seemed to be signed.

Next we checked the CONFIG. And it seems MODULE_SIG_FORCE is not enabled though MODULE_SIG and MODULE_SIG_ALL are enabled.

As per powerpc arch specific policies for secure boot which are:
static const char *const secure_and_trusted_rules[] = {
"measure func=KEXEC_KERNEL_CHECK template=ima-modsig",
"measure func=MODULE_CHECK template=ima-modsig",
"appraise func=KEXEC_KERNEL_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig",
#ifndef CONFIG_MODULE_SIG_FORCE
"appraise func=MODULE_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig",
#endif
NULL

As per these policies, if MODULE_SIG_FORCE is not enabled, IMA policy for MODULE_CHECK gets added. However, IMA looks for keys only in .ima keyring for module verification and therefore does not find Buildtime generated key and fails to verify.

I think that explains why booting failed.

We wanted to understand if there is a reason for not enabling MODULE_SIG_FORCE even though modules are signed at build time.

Michael please add any other info if I missed..

Thanks & Regards,
- Nayna

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-04-03 00:39 EDT-------
We did check the modules - at least the package 5.4.0-21.25+lp1866909v202004020814 and from modinfo:

signer: Build time autogenerated kernel key
sig_key: 3B:AB:B6:13:BE:1C:39:7C:C5:17:8E:6F:B4:C9:A1:7F:52:30:9B:8F

MODULE_SIG_FORCE looks like it's off for all archs, too.

[Frank Heimes (fheimes)]

Yes, I had a quick look at the sources MODULE_SIG_FORCE is currently unset for all architectures:
annotations:CONFIG_MODULE_SIG_FORCE policy<{'amd64': 'n', 'arm64': 'n', 'armhf': 'n', 'i386': 'n', 'ppc64el': 'n', 'riscv64': 'n', 's390x': 'n'}>
config.common.ubuntu:# CONFIG_MODULE_SIG_FORCE is not set

[Frank Heimes (fheimes)]

If we understood you correctly you want to have CONFIG_MODULE_SIG_FORCE set (for Power only) - so we are considering that ...

[Seth Forshee (sforshee)]

Our policy is to require module signatures only under lockdown. CONFIG_MODULE_SIG_FORCE requires modules to be signed unconditionally, which makes dkms impossible on systems which have no mechanism for importing keys from firmware.

[Seth Forshee (sforshee)]

I'm suddenly having a major sense of deja vu about this. I think we hit very similar issues on x86, and after discussions with Mimi we decided that CONFIG_IMA_ARCH_POLICY should be disabled for us. I think this may be the right solution here too.

[Seth Forshee (sforshee)]

Afaict the ppc ima arch policy is about ensuring that signature verification is done for module loading and kexec, which in our kernel will be enforced by automatically turning on lockdown integrity mode under secure boot. So my conclusion is that CONFIG_MODULE_SIG_FORCE should stay off and CONFIG_IMA_ARCH_POLICY should be disabled.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-04-03 10:30 EDT-------
Sorry, we don't know if we want CONFIG_MODULE_SIG_FORCE set. The modules aren't loading, and we weren't sure what needed to change. We're happy to try a kernel with IMA_ARCH_POLICY if that fixed it on x86.

[Seth Forshee (sforshee)]

I'll get a test kernel uploaded with IMA_ARCH_POLICY up, will let you know when it's ready for testing.

[Seth Forshee (sforshee)]

Um, off rather.

[Seth Forshee (sforshee)]

Oh but PPC_SECURE_BOOT depends on IMA_ARCH_POLICY. For now I'm going to make it depend on that or LOCK_DOWN_IN_SECURE_BOOT to get the test build going. I think this makes sense because lockdown enforces signatures for module loading and kexec (plus a number of other restrictions), which I think is all the IMA arch policy is enforcing.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-04-03 12:45 EDT-------
We've been working with Mimi and I think that what we need now aren't config option changes, but this patch:

diff --git a/arch/powerpc/kernel/ima_arch.c b/arch/powerpc/kernel/ima_arch.c
index e341162..c1ea55d 100644
--- a/arch/powerpc/kernel/ima_arch.c
+++ b/arch/powerpc/kernel/ima_arch.c
@@ -50,7 +50,7 @@ bool arch_ima_get_secureboot(void)
"measure func=KEXEC_KERNEL_CHECK template=ima-modsig",
"measure func=MODULE_CHECK template=ima-modsig",
"appraise func=KEXEC_KERNEL_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig",
-#ifndef CONFIG_MODULE_SIG_FORCE
+#ifndef CONFIG_MODULE_SIG
"appraise func=MODULE_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig",
#endif
NULL

We're going to test that, but it's similar to commit 8db5da0b8618 on the x86 side.

It looks like the MODULE_SIG_FORCE/IMA_ARCH_POLICY change is the wrong path right now. But testing that, too. ;)

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-04-03 16:36 EDT-------
We did some testing with that patch (previous comment) on top of the 5.4.0-21.25+lp1866909v202004020814 source/config file. We signed the kernel/modules and securely booted it. That fixed the module loading issue we were having when trying 5.4.0-21.25+lp1866909v202004020814 and seemed to be generally successful.

We'll try the PPA once that's done building. Thank you, again.

[Seth Forshee (sforshee)]

Test build is done now, in the same location. It has the above patch and also the updated patch from bug 1855668.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-04-06 11:23 EDT-------
Tested the updated ppa kernel.

Everything looks good and here are the test results:

secure boot is enabled as seen by device-tree entry "os-secure-enforcing"
ubuntu@ltc-wspoon13:~$ ls /proc/device-tree/ibm,secureboot/
compatible ibm,cvc phandle
hw-key-hash name secure-enabled
hw-key-hash-size os-secureboot-enforcing trusted-enabled

IMA policies are as below. It doesn't have MODULE_CHECK enabled now.
root@ltc-wspoon13:/home/ubuntu# cat /sys/kernel/security/ima/policy
measure func=KEXEC_KERNEL_CHECK template=ima-modsig
measure func=MODULE_CHECK template=ima-modsig
appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig|modsig appraise_flag=check_blacklist

Platform keyring is loaded with db keys:
root@ltc-wspoon13:/home/ubuntu# keyctl show %keyring:.platform
Keyring
1002253804 ---lswrv 0 0 keyring: .platform
900087744 ---lswrv 0 0 \_ asymmetric: PPA sforshee lp1866909 Opal: d9be99d351bd1a2bdef604427612399dc47cb452

Build time generated key used for signing modules is:
root@ltc-wspoon13:/home/ubuntu# keyctl show %keyring:.builtin_trusted_keys
Keyring
929665685 ---lswrv 0 0 keyring: .builtin_trusted_keys
110783576 ---lswrv 0 0 \_ asymmetric: Build time autogenerated kernel key: d80d11780f22b0a033c0a787e075d0f0eb784d2c

sysfs interface is enabled:
root@ltc-wspoon13:/home/ubuntu# ls /sys/firmware/secvar/vars/
db dbx KEK PK TS

kexec load is disabled:
root@ltc-wspoon13:/boot# kexec -l /boot/vmlinux-5.4.0-21-generic -i /boot/initrd.img-5.4.0-21-generic
Warning: append= option is not passed. Using the first kernel root partition
Modified cmdline:root=UUID=49d000cb-dba2-4d70-809e-38f2b31d0f09
[ 1150.964096] ima: impossible to appraise a kernel image without a file descriptor; try using kexec_file_load syscall.
kexec_load failed: Permission denied
entry = 0x39f0600 flags = 0x150000
nr_segments = 3
segment[0].buf = 0x76a989590010
segment[0].bufsz = 0x1aca0d8
segment[0].mem = 0x1d00000
segment[0].memsz = 0x1cf0000
segment[1].buf = 0xac9705e7260
segment[1].bufsz = 0x38c0
segment[1].mem = 0x39f0000
segment[1].memsz = 0x10000
segment[2].buf = 0x76a989430010
segment[2].bufsz = 0x648dc
segment[2].mem = 0x2ff90000
segment[2].memsz = 0x70000

kexec_file_load failed when trying for a kernel signed with a different key. The key for this kernel is not present in .platform keyring. It says "invalid-signature" in the audit log.
root@ltc-wspoon13:/boot# kexec -s -l /boot/vmlinux-5.4.27signpatch.signed
kexec_file_load failed: Permission denied-l /boot/vmlinux-5.4.27signpatch.signed

And here is the audit log message for it:
Apr 6 10:12:52 ltc-wspoon13 kernel: [ 233.996642] audit: type=1800 audit(158611
85972.332:16): pid=3385 uid=0 auid=1000 ses=1 op=appraise_data cause=invalid-sigg
nature comm="kexec" name="/boot/vmlinux-5.4.27signpatch.signed" dev="sdb6" ino=22
017357 res=0

Next tried to load the signed kernel whose key is present in .platform keyring.
root@ltc-wspoon13:/home/ubuntu# kexec -s -l /boot/vmlinux-5.4.0-21-generic
root@ltc-wspoon13:/home/ubuntu# dmesg | tail
[ 9.127873]...

[Seth Forshee (sforshee)]

Thanks for testing. I've applied the patches to focal/master-next.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-04-10 16:15 EDT-------
The upstream patch has an additional fix but it?s not critical for GA. It can get included as part of bug fixes. It also affects only power. The patch("powerpc/ima: fix secure boot rules in ima arch policy") is posted to linux-integrity and linuxppc-dev mailing list (https://lore.kernel<email address hidden>/T/#u)

If there are any issues identified during further testing, they will get opened as separate issue to be addressed later.

Thanks & Regards,
- Nayna

[Andrew Cloke (andrew-cloke)]

@naynjain thanks for the update.
Could you raise a new bug for the additional patch "powerpc/ima: fix secure boot rules in ima arch policy"?
This one will be closed once the original patchsets have progressed into the 20.04 5.4 kernel.
Thanks.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 5.4.0-24.28

---------------
linux (5.4.0-24.28) focal; urgency=medium

  * focal/linux: 5.4.0-24.28 -proposed tracker (LP: #1871939)

  * getitimer returns it_value=0 erroneously (LP: #1349028)
    - [Config] CONTEXT_TRACKING_FORCE policy should be unset

  * 12d1:1038 Dual-Role OTG device on non-HNP port - unable to enumerate USB
    device on port 1 (LP: #1047527)
    - [Config] USB_OTG_FSM policy not needed

  * Add DCPD backlight support for HP CML system (LP: #1871589)
    - SAUCE: drm/i915: Force DPCD backlight mode for HP CML 2020 system

  * Backlight brightness cannot be adjusted using keys (LP: #1860303)
    - SAUCE drm/i915: Force DPCD backlight mode for HP Spectre x360 Convertible
      13t-aw100

  * CVE-2020-11494
    - slcan: Don't transmit uninitialized stack data in padding

  * Ubuntu Kernel Support for OpenPOWER NV Secure & Trusted Boot (LP: #1866909)
    - powerpc: Detect the secure boot mode of the system
    - powerpc/ima: Add support to initialize ima policy rules
    - powerpc: Detect the trusted boot state of the system
    - powerpc/ima: Define trusted boot policy
    - ima: Make process_buffer_measurement() generic
    - certs: Add wrapper function to check blacklisted binary hash
    - ima: Check against blacklisted hashes for files with modsig
    - powerpc/ima: Update ima arch policy to check for blacklist
    - powerpc/ima: Indicate kernel modules appended signatures are enforced
    - powerpc/powernv: Add OPAL API interface to access secure variable
    - powerpc: expose secure variables to userspace via sysfs
    - x86/efi: move common keyring handler functions to new file
    - powerpc: Load firmware trusted keys/hashes into kernel keyring
    - x86/efi: remove unused variables

  * [roce-0227]sync mainline kernel 5.6rc3 roce patchset into ubuntu HWE kernel
    branch (LP: #1864950)
    - RDMA/hns: Cleanups of magic numbers
    - RDMA/hns: Optimize eqe buffer allocation flow
    - RDMA/hns: Add the workqueue framework for flush cqe handler
    - RDMA/hns: Delayed flush cqe process with workqueue
    - RDMA/hns: fix spelling mistake: "attatch" -> "attach"
    - RDMA/hns: Initialize all fields of doorbells to zero
    - RDMA/hns: Treat revision HIP08_A as a special case
    - RDMA/hns: Use flush framework for the case in aeq
    - RDMA/hns: Stop doorbell update while qp state error
    - RDMA/hns: Optimize qp destroy flow
    - RDMA/hns: Optimize qp context create and destroy flow
    - RDMA/hns: Optimize qp number assign flow
    - RDMA/hns: Optimize qp buffer allocation flow
    - RDMA/hns: Optimize qp param setup flow
    - RDMA/hns: Optimize kernel qp wrid allocation flow
    - RDMA/hns: Optimize qp doorbell allocation flow
    - RDMA/hns: Check if depth of qp is 0 before configure

  * [hns3-0316]sync mainline kernel 5.6rc4 hns3 patchset into ubuntu HWE kernel
    branch (LP: #1867586)
    - net: hns3: modify an unsuitable print when setting unknown duplex to fibre
    - net: hns3: add enabled TC numbers and DWRR weight info in debugfs
    - net: hns3: add support for dump MAC ID and loopback status in debugfs
    - net: hns3: add missing help info for QS shaper...