mbox series

[v11,0/4] integrity: support including firmware ".platform" keys at build time

Message ID 20220310214450.676505-1-nayna@linux.ibm.com (mailing list archive)
Headers show
Series integrity: support including firmware ".platform" keys at build time | expand

Message

Nayna Jain March 10, 2022, 9:44 p.m. UTC
Some firmware support secure boot by embedding static keys to verify the
Linux kernel during boot. However, these firmware do not expose an
interface for the kernel to load firmware keys onto the ".platform"
keyring, preventing the kernel from verifying the kexec kernel image
signature.

This patchset exports load_certificate_list() and defines a new function
load_builtin_platform_cert() to load compiled in certificates onto the
".platform" keyring.

Changelog:
v11:
* Added a new patch to conditionally build extract-cert if
PLATFORM_KEYRING is enabled.

v10:
* Fixed the externs warning for Patch 3.

v9:
* Rebased on Jarkko's repo - 
git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git

v8:
* Includes Jarkko's feedback on patch description and removed Reported-by
for Patch 1.

v7:
* Incldues Jarkko's feedback on patch description for Patch 1 and 3.

v6:
* Includes Jarkko's feedback:
 * Split Patch 2 into two.
 * Update Patch description.

v5:
* Renamed load_builtin_platform_cert() to load_platform_certificate_list()
and config INTEGRITY_PLATFORM_BUILTIN_KEYS to INTEGRITY_PLATFORM_KEYS, as
suggested by Mimi Zohar.

v4:
* Split into two patches as per Mimi Zohar and Dimitri John Ledkov
recommendation.

v3:
* Included Jarkko's feedback
 ** updated patch description to include approach.
 ** removed extern for function declaration in the .h file.
* Included load_certificate_list() within #ifdef CONFIG_KEYS condition.

v2:
* Fixed the error reported by kernel test robot
* Updated patch description based on Jarkko's feedback.

Nayna Jain (4):
  certs: export load_certificate_list() to be used outside certs/
  integrity: make integrity_keyring_from_id() non-static
  certs: conditionally build extract-cert if platform keyring is enabled
  integrity: support including firmware ".platform" keys at build time

 certs/Makefile                                |  9 ++++++--
 certs/blacklist.c                             |  1 -
 certs/common.c                                |  2 +-
 certs/common.h                                |  9 --------
 certs/system_keyring.c                        |  1 -
 include/keys/system_keyring.h                 |  6 +++++
 security/integrity/Kconfig                    | 10 ++++++++
 security/integrity/Makefile                   | 15 +++++++++++-
 security/integrity/digsig.c                   |  2 +-
 security/integrity/integrity.h                |  9 ++++++++
 .../integrity/platform_certs/platform_cert.S  | 23 +++++++++++++++++++
 .../platform_certs/platform_keyring.c         | 23 +++++++++++++++++++
 12 files changed, 94 insertions(+), 16 deletions(-)
 delete mode 100644 certs/common.h
 create mode 100644 security/integrity/platform_certs/platform_cert.S


base-commit: fb5abce6b2bb5cb3d628aaa63fa821da8c4600f9

Comments

Nageswara Sastry March 11, 2022, 4:41 a.m. UTC | #1
On 11/03/22 3:14 am, Nayna Jain wrote:
> Some firmware support secure boot by embedding static keys to verify the
> Linux kernel during boot. However, these firmware do not expose an
> interface for the kernel to load firmware keys onto the ".platform"
> keyring, preventing the kernel from verifying the kexec kernel image
> signature.
> 
> This patchset exports load_certificate_list() and defines a new function
> load_builtin_platform_cert() to load compiled in certificates onto the
> ".platform" keyring.
> 
> Changelog:
> v11:
> * Added a new patch to conditionally build extract-cert if
> PLATFORM_KEYRING is enabled.
> 

Tested the following four patches with and with out setting 
CONFIG_INTEGRITY_PLATFORM_KEYS

Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>


1. With set CONFIG_INTEGRITY_PLATFORM_KEYS

# grep pem .config
CONFIG_INTEGRITY_PLATFORM_KEYS="certs/kernel.pem"
CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
CONFIG_SYSTEM_TRUSTED_KEYS="certs/rhel.pem"

# grep 
"CONFIG_INTEGRITY_PLATFORM_KEYS\|INTEGRITY_PLATFORM_KEYRING\|SYSTEM_REVOCATION_LIST" 
.config
CONFIG_INTEGRITY_PLATFORM_KEYRING=y
CONFIG_INTEGRITY_PLATFORM_KEYS="certs/kernel.pem"
# CONFIG_SYSTEM_REVOCATION_LIST is not set

# cat /proc/keys | grep platform
0e60c88d I------     1 perm 1f0b0000     0     0 keyring   .platform: 1

# keyctl show %keyring:.platform
Keyring
  241223821 ---lswrv      0     0  keyring: .platform
  308815460 ---lswrv      0     0   \_ asymmetric: IBM Corporation: 
Guest Secure Boot Imprint Kernel Signing Key: 
a0cf9069c30875320cb10a77325d4fa7012f8d12


2. With out set CONFIG_INTEGRITY_PLATFORM_KEYS

# grep pem .config
CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
CONFIG_SYSTEM_TRUSTED_KEYS="certs/rhel.pem"

# grep 
"CONFIG_INTEGRITY_PLATFORM_KEYS\|INTEGRITY_PLATFORM_KEYRING\|SYSTEM_REVOCATION_LIST" 
.config
CONFIG_INTEGRITY_PLATFORM_KEYRING=y
CONFIG_INTEGRITY_PLATFORM_KEYS=""
# CONFIG_SYSTEM_REVOCATION_LIST is not set

# cat /proc/keys | grep platform
12a5f301 I------     1 perm 1f0b0000     0     0 keyring   .platform: empty

# keyctl show %keyring:.platform
Keyring
  312865537 ---lswrv      0     0  keyring: .platform


> 
> 
> base-commit: fb5abce6b2bb5cb3d628aaa63fa821da8c4600f9
Jarkko Sakkinen March 11, 2022, 4:39 p.m. UTC | #2
On Thu, 2022-03-10 at 16:44 -0500, Nayna Jain wrote:
> Some firmware support secure boot by embedding static keys to verify the
> Linux kernel during boot. However, these firmware do not expose an
> interface for the kernel to load firmware keys onto the ".platform"
> keyring, preventing the kernel from verifying the kexec kernel image
> signature.
> 
> This patchset exports load_certificate_list() and defines a new function
> load_builtin_platform_cert() to load compiled in certificates onto the
> ".platform" keyring.
> 
> Changelog:
> v11:
> * Added a new patch to conditionally build extract-cert if
> PLATFORM_KEYRING is enabled.
> 
> v10:
> * Fixed the externs warning for Patch 3.
> 
> v9:
> * Rebased on Jarkko's repo - 
> git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git
> 
> v8:
> * Includes Jarkko's feedback on patch description and removed Reported-by
> for Patch 1.
> 
> v7:
> * Incldues Jarkko's feedback on patch description for Patch 1 and 3.
> 
> v6:
> * Includes Jarkko's feedback:
>  * Split Patch 2 into two.
>  * Update Patch description.
> 
> v5:
> * Renamed load_builtin_platform_cert() to load_platform_certificate_list()
> and config INTEGRITY_PLATFORM_BUILTIN_KEYS to INTEGRITY_PLATFORM_KEYS, as
> suggested by Mimi Zohar.
> 
> v4:
> * Split into two patches as per Mimi Zohar and Dimitri John Ledkov
> recommendation.
> 
> v3:
> * Included Jarkko's feedback
>  ** updated patch description to include approach.
>  ** removed extern for function declaration in the .h file.
> * Included load_certificate_list() within #ifdef CONFIG_KEYS condition.
> 
> v2:
> * Fixed the error reported by kernel test robot
> * Updated patch description based on Jarkko's feedback.
> 
> Nayna Jain (4):
>   certs: export load_certificate_list() to be used outside certs/
>   integrity: make integrity_keyring_from_id() non-static
>   certs: conditionally build extract-cert if platform keyring is enabled
>   integrity: support including firmware ".platform" keys at build time
> 
>  certs/Makefile                                |  9 ++++++--
>  certs/blacklist.c                             |  1 -
>  certs/common.c                                |  2 +-
>  certs/common.h                                |  9 --------
>  certs/system_keyring.c                        |  1 -
>  include/keys/system_keyring.h                 |  6 +++++
>  security/integrity/Kconfig                    | 10 ++++++++
>  security/integrity/Makefile                   | 15 +++++++++++-
>  security/integrity/digsig.c                   |  2 +-
>  security/integrity/integrity.h                |  9 ++++++++
>  .../integrity/platform_certs/platform_cert.S  | 23 +++++++++++++++++++
>  .../platform_certs/platform_keyring.c         | 23 +++++++++++++++++++
>  12 files changed, 94 insertions(+), 16 deletions(-)
>  delete mode 100644 certs/common.h
>  create mode 100644 security/integrity/platform_certs/platform_cert.S
> 
> 
> base-commit: fb5abce6b2bb5cb3d628aaa63fa821da8c4600f9

I tuned tags. Nayna, Mimi is this how it should be:

commit f38ebfc7469c4924087dab2203479ee9bb6911ac (HEAD -> master, origin/next, origin/master, origin/HEAD, next)
Author: Nayna Jain <nayna@linux.ibm.com>
Date:   Thu Mar 10 16:44:50 2022 -0500

    integrity: support including firmware ".platform" keys at build time
    
    Allow firmware keys to be embedded in the Linux kernel and loaded onto
    the ".platform" keyring on boot.
    
    The firmware keys can be specified in a file as a list of PEM encoded
    certificates using new config INTEGRITY_PLATFORM_KEYS. The certificates
    are embedded in the image by converting the PEM-formatted certificates
    into DER(binary) and generating
    security/integrity/platform_certs/platform_certificate_list file at
    build time. On boot, the embedded certs from the image are loaded onto
    the ".platform" keyring at late_initcall(), ensuring the platform keyring
    exists before loading the keys.
    
    Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
    Tested-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

commit 233bb42918e71f143e6f31d99763348768eb1619
Author: Nayna Jain <nayna@linux.ibm.com>
Date:   Thu Mar 10 16:44:49 2022 -0500

    certs: conditionally build extract-cert if platform keyring is enabled
    
    extract-cert is used outside certs/ by INTEGRITY_PLATFORM_KEYRING.
    Also build extract-cert if INTEGRITY_PLATFORM_KEYRING is enabled.
    
    Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

commit 5e1a41f1c2ee838af6ac39d1cdd4ed0f509186a1
Author: Nayna Jain <nayna@linux.ibm.com>
Date:   Thu Mar 10 16:44:48 2022 -0500

    integrity: make integrity_keyring_from_id() non-static
    
    Make integrity_keyring_from_id() non-static so that it is accessible
    by other files in security/integrity.
    
    Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
    Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

commit 05489d362bde0f25c4e921d15cad4492d22147ae
Author: Nayna Jain <nayna@linux.ibm.com>
Date:   Thu Mar 10 16:44:47 2022 -0500

    certs: export load_certificate_list() to be used outside certs/
    
    load_certificate_list() parses certificates embedded in the kernel
    image to load them onto the keyring.
    
    Commit "2565ca7f5ec1 (certs: Move load_system_certificate_list to a common
    function)" made load_certificate_list() a common function in the certs/
    directory. Export load_certificate_list() outside certs/ to be used by
    load_platform_certificate_list() for loading compiled in platform keys
    onto the .platform keyring at boot time.
    
    Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
    Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

BR, Jarkko
Jarkko Sakkinen March 11, 2022, 4:42 p.m. UTC | #3
On Fri, 2022-03-11 at 10:11 +0530, Nageswara Sastry wrote:
> 
> 
> On 11/03/22 3:14 am, Nayna Jain wrote:
> > Some firmware support secure boot by embedding static keys to verify the
> > Linux kernel during boot. However, these firmware do not expose an
> > interface for the kernel to load firmware keys onto the ".platform"
> > keyring, preventing the kernel from verifying the kexec kernel image
> > signature.
> > 
> > This patchset exports load_certificate_list() and defines a new function
> > load_builtin_platform_cert() to load compiled in certificates onto the
> > ".platform" keyring.
> > 
> > Changelog:
> > v11:
> > * Added a new patch to conditionally build extract-cert if
> > PLATFORM_KEYRING is enabled.
> > 
> 
> Tested the following four patches with and with out setting 
> CONFIG_INTEGRITY_PLATFORM_KEYS
> 
> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>

OK, I added it:

git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git

BR, Jarkko
Nayna March 11, 2022, 9:03 p.m. UTC | #4
On 3/11/22 11:42, Jarkko Sakkinen wrote:
> On Fri, 2022-03-11 at 10:11 +0530, Nageswara Sastry wrote:
>>
>> On 11/03/22 3:14 am, Nayna Jain wrote:
>>> Some firmware support secure boot by embedding static keys to verify the
>>> Linux kernel during boot. However, these firmware do not expose an
>>> interface for the kernel to load firmware keys onto the ".platform"
>>> keyring, preventing the kernel from verifying the kexec kernel image
>>> signature.
>>>
>>> This patchset exports load_certificate_list() and defines a new function
>>> load_builtin_platform_cert() to load compiled in certificates onto the
>>> ".platform" keyring.
>>>
>>> Changelog:
>>> v11:
>>> * Added a new patch to conditionally build extract-cert if
>>> PLATFORM_KEYRING is enabled.
>>>
>> Tested the following four patches with and with out setting
>> CONFIG_INTEGRITY_PLATFORM_KEYS
>>
>> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
> OK, I added it:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git

Thanks Jarkko. Masahiro Yamada would prefer to revert the original 
commit 340a02535ee785c64c62a9c45706597a0139e972 i.e. move extract-cert 
back to the scripts/ directory.

I am just posting v12 which includes Masahiro feedback. Nageswara has 
already tested v12 version as well.

I am fine either way 1.) Adding v11 and then separately handling of 
reverting of the commit or 2.) Adding v12 version which includes the 
revert. I leave the decision on you as to which one to upstream.

Thanks & Regards,

     - Nayna
Mimi Zohar March 14, 2022, 12:53 p.m. UTC | #5
On Fri, 2022-03-11 at 18:39 +0200, Jarkko Sakkinen wrote:
> On Thu, 2022-03-10 at 16:44 -0500, Nayna Jain wrote:
> > Some firmware support secure boot by embedding static keys to verify the
> > Linux kernel during boot. However, these firmware do not expose an
> > interface for the kernel to load firmware keys onto the ".platform"
> > keyring, preventing the kernel from verifying the kexec kernel image
> > signature.
> > 
> > This patchset exports load_certificate_list() and defines a new function
> > load_builtin_platform_cert() to load compiled in certificates onto the
> > ".platform" keyring.
> > 
> > Changelog:
> > v11:
> > * Added a new patch to conditionally build extract-cert if
> > PLATFORM_KEYRING is enabled.
> > 
> > v10:
> > * Fixed the externs warning for Patch 3.
> > 
> > v9:
> > * Rebased on Jarkko's repo - 
> > git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git
> > 
> > v8:
> > * Includes Jarkko's feedback on patch description and removed Reported-by
> > for Patch 1.
> > 
> > v7:
> > * Incldues Jarkko's feedback on patch description for Patch 1 and 3.
> > 
> > v6:
> > * Includes Jarkko's feedback:
> >  * Split Patch 2 into two.
> >  * Update Patch description.
> > 
> > v5:
> > * Renamed load_builtin_platform_cert() to load_platform_certificate_list()
> > and config INTEGRITY_PLATFORM_BUILTIN_KEYS to INTEGRITY_PLATFORM_KEYS, as
> > suggested by Mimi Zohar.
> > 
> > v4:
> > * Split into two patches as per Mimi Zohar and Dimitri John Ledkov
> > recommendation.
> > 
> > v3:
> > * Included Jarkko's feedback
> >  ** updated patch description to include approach.
> >  ** removed extern for function declaration in the .h file.
> > * Included load_certificate_list() within #ifdef CONFIG_KEYS condition.
> > 
> > v2:
> > * Fixed the error reported by kernel test robot
> > * Updated patch description based on Jarkko's feedback.
> > 
> > Nayna Jain (4):
> >   certs: export load_certificate_list() to be used outside certs/
> >   integrity: make integrity_keyring_from_id() non-static
> >   certs: conditionally build extract-cert if platform keyring is enabled
> >   integrity: support including firmware ".platform" keys at build time
> > 
> >  certs/Makefile                                |  9 ++++++--
> >  certs/blacklist.c                             |  1 -
> >  certs/common.c                                |  2 +-
> >  certs/common.h                                |  9 --------
> >  certs/system_keyring.c                        |  1 -
> >  include/keys/system_keyring.h                 |  6 +++++
> >  security/integrity/Kconfig                    | 10 ++++++++
> >  security/integrity/Makefile                   | 15 +++++++++++-
> >  security/integrity/digsig.c                   |  2 +-
> >  security/integrity/integrity.h                |  9 ++++++++
> >  .../integrity/platform_certs/platform_cert.S  | 23 +++++++++++++++++++
> >  .../platform_certs/platform_keyring.c         | 23 +++++++++++++++++++
> >  12 files changed, 94 insertions(+), 16 deletions(-)
> >  delete mode 100644 certs/common.h
> >  create mode 100644 security/integrity/platform_certs/platform_cert.S
> > 
> > 
> > base-commit: fb5abce6b2bb5cb3d628aaa63fa821da8c4600f9
> 
> I tuned tags. Nayna, Mimi is this how it should be:

Either v11 or v12 is fine by me, except Masahiro Yamada requested to
move extract_certs back to the scripts/ directory.  v12 moves
extract_certs back, as requested.  Also Nageswara Sastry tested both
v11 and v12 versions.

thanks,

Mimi
Jarkko Sakkinen March 17, 2022, 7:38 a.m. UTC | #6
On Fri, Mar 11, 2022 at 04:03:12PM -0500, Nayna wrote:
> 
> On 3/11/22 11:42, Jarkko Sakkinen wrote:
> > On Fri, 2022-03-11 at 10:11 +0530, Nageswara Sastry wrote:
> > > 
> > > On 11/03/22 3:14 am, Nayna Jain wrote:
> > > > Some firmware support secure boot by embedding static keys to verify the
> > > > Linux kernel during boot. However, these firmware do not expose an
> > > > interface for the kernel to load firmware keys onto the ".platform"
> > > > keyring, preventing the kernel from verifying the kexec kernel image
> > > > signature.
> > > > 
> > > > This patchset exports load_certificate_list() and defines a new function
> > > > load_builtin_platform_cert() to load compiled in certificates onto the
> > > > ".platform" keyring.
> > > > 
> > > > Changelog:
> > > > v11:
> > > > * Added a new patch to conditionally build extract-cert if
> > > > PLATFORM_KEYRING is enabled.
> > > > 
> > > Tested the following four patches with and with out setting
> > > CONFIG_INTEGRITY_PLATFORM_KEYS
> > > 
> > > Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
> > OK, I added it:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git
> 
> Thanks Jarkko. Masahiro Yamada would prefer to revert the original commit
> 340a02535ee785c64c62a9c45706597a0139e972 i.e. move extract-cert back to the
> scripts/ directory.
> 
> I am just posting v12 which includes Masahiro feedback. Nageswara has
> already tested v12 version as well.
> 
> I am fine either way 1.) Adding v11 and then separately handling of
> reverting of the commit or 2.) Adding v12 version which includes the revert.
> I leave the decision on you as to which one to upstream.
> 
> Thanks & Regards,
> 
>     - Nayna
> 

I already sent PR for v5.18. Too many late changes to include this, which
means that v12 is the way to go.

BR, Jarkko
Nayna March 18, 2022, 9:25 p.m. UTC | #7
On 3/17/22 03:38, Jarkko Sakkinen wrote:
> On Fri, Mar 11, 2022 at 04:03:12PM -0500, Nayna wrote:
>> On 3/11/22 11:42, Jarkko Sakkinen wrote:
>>> ".platform" keyring.
>>>>> Changelog:
>>>>> v11:
>>>>> * Added a new patch to conditionally build extract-cert if
>>>>> PLATFORM_KEYRING is enabled.
>>>>>
>>>> Tested the following four patches with and with out setting
>>>> CONFIG_INTEGRITY_PLATFORM_KEYS
>>>>
>>>> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
>>> OK, I added it:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git
>> Thanks Jarkko. Masahiro Yamada would prefer to revert the original commit
>> 340a02535ee785c64c62a9c45706597a0139e972 i.e. move extract-cert back to the
>> scripts/ directory.
>>
>> I am just posting v12 which includes Masahiro feedback. Nageswara has
>> already tested v12 version as well.
>>
>> I am fine either way 1.) Adding v11 and then separately handling of
>> reverting of the commit or 2.) Adding v12 version which includes the revert.
>> I leave the decision on you as to which one to upstream.
>>
>> Thanks & Regards,
>>
>>      - Nayna
>>
> I already sent PR for v5.18. Too many late changes to include this, which
> means that v12 is the way to go.

Assuming v12 looks good, could you please queue it now ?

Thanks & Regards,

     - Nayna
Jarkko Sakkinen March 20, 2022, 9:31 p.m. UTC | #8
On Fri, Mar 18, 2022 at 05:25:07PM -0400, Nayna wrote:
> 
> On 3/17/22 03:38, Jarkko Sakkinen wrote:
> > On Fri, Mar 11, 2022 at 04:03:12PM -0500, Nayna wrote:
> > > On 3/11/22 11:42, Jarkko Sakkinen wrote:
> > > > ".platform" keyring.
> > > > > > Changelog:
> > > > > > v11:
> > > > > > * Added a new patch to conditionally build extract-cert if
> > > > > > PLATFORM_KEYRING is enabled.
> > > > > > 
> > > > > Tested the following four patches with and with out setting
> > > > > CONFIG_INTEGRITY_PLATFORM_KEYS
> > > > > 
> > > > > Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
> > > > OK, I added it:
> > > > 
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git
> > > Thanks Jarkko. Masahiro Yamada would prefer to revert the original commit
> > > 340a02535ee785c64c62a9c45706597a0139e972 i.e. move extract-cert back to the
> > > scripts/ directory.
> > > 
> > > I am just posting v12 which includes Masahiro feedback. Nageswara has
> > > already tested v12 version as well.
> > > 
> > > I am fine either way 1.) Adding v11 and then separately handling of
> > > reverting of the commit or 2.) Adding v12 version which includes the revert.
> > > I leave the decision on you as to which one to upstream.
> > > 
> > > Thanks & Regards,
> > > 
> > >      - Nayna
> > > 
> > I already sent PR for v5.18. Too many late changes to include this, which
> > means that v12 is the way to go.
> 
> Assuming v12 looks good, could you please queue it now ?
> 
> Thanks & Regards,
> 
>     - Nayna
> 

Unfortunately, I've already sent my v5.18 PR over a week ago. I can put it
to my queue but I think it is lacking some of the tested by tags, doesn't
it?

BR, Jarkko