| Message ID | cover.1663951201.git.msuchanek@suse.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: kexec_file: use more system keyrings to verify kernel image signature + dependencies | expand |
On Fri, 2022-09-23 at 19:10 +0200, Michal Suchanek wrote: > Hello, > > this is backport of commit 0d519cadf751 > ("arm64: kexec_file: use more system keyrings to verify kernel image signature") > to table 5.15 tree including the preparatory patches. > > Some patches needed minor adjustment for context. In general when backporting this patch set, there should be a dependency on backporting these commits as well. In this instance for linux-5.15.y, they've already been backported. 543ce63b664e ("lockdown: Fix kexec lockdown bypass with ima policy") af16df54b89d ("ima: force signature verification when CONFIG_KEXEC_SIG is configured")
Hello, On Fri, Sep 23, 2022 at 03:03:36PM -0400, Mimi Zohar wrote: > On Fri, 2022-09-23 at 19:10 +0200, Michal Suchanek wrote: > > Hello, > > > > this is backport of commit 0d519cadf751 > > ("arm64: kexec_file: use more system keyrings to verify kernel image signature") > > to table 5.15 tree including the preparatory patches. > > > > Some patches needed minor adjustment for context. > > In general when backporting this patch set, there should be a > dependency on backporting these commits as well. In this instance for > linux-5.15.y, they've already been backported. > > 543ce63b664e ("lockdown: Fix kexec lockdown bypass with ima policy") > af16df54b89d ("ima: force signature verification when CONFIG_KEXEC_SIG is configured") Thanks for bringing these up. It might be in general useful to backport these fixes as well. However, this patchset does one very specific thing: it lifts the x86 kexec_file signature verification to arch-independent and uses it on arm64 to unify all features (and any existing warts) between EFI architectures. So unless I am missing something the fixes you pointed out are completely independent of this. Thanks Michal
On Fri, Sep 23, 2022 at 07:10:28PM +0200, Michal Suchanek wrote: > Hello, > > this is backport of commit 0d519cadf751 > ("arm64: kexec_file: use more system keyrings to verify kernel image signature") > to table 5.15 tree including the preparatory patches. This feels to me like a new feature for arm64, one that has never worked before and you are just making it feature-parity with x86, right? Or is this a regression fix somewhere? Why is this needed in 5.15.y and why can't people who need this new feature just use a newer kernel version (5.19?) thanks, greg k-h
On Sat, Sep 24, 2022 at 11:19:19AM +0200, Greg Kroah-Hartman wrote: > On Fri, Sep 23, 2022 at 07:10:28PM +0200, Michal Suchanek wrote: > > Hello, > > > > this is backport of commit 0d519cadf751 > > ("arm64: kexec_file: use more system keyrings to verify kernel image signature") > > to table 5.15 tree including the preparatory patches. > > This feels to me like a new feature for arm64, one that has never worked > before and you are just making it feature-parity with x86, right? > > Or is this a regression fix somewhere? Why is this needed in 5.15.y and > why can't people who need this new feature just use a newer kernel > version (5.19?) It's half-broken implementation of the kexec kernel verification. At the time it was implemented for arm64 we had the platform and secondary keyrings and x86 was using them but on arm64 the initial implementation ignores them. Thanks Michal
On Sat, Sep 24, 2022 at 11:45:21AM +0200, Michal Suchánek wrote: > On Sat, Sep 24, 2022 at 11:19:19AM +0200, Greg Kroah-Hartman wrote: > > On Fri, Sep 23, 2022 at 07:10:28PM +0200, Michal Suchanek wrote: > > > Hello, > > > > > > this is backport of commit 0d519cadf751 > > > ("arm64: kexec_file: use more system keyrings to verify kernel image signature") > > > to table 5.15 tree including the preparatory patches. > > > > This feels to me like a new feature for arm64, one that has never worked > > before and you are just making it feature-parity with x86, right? > > > > Or is this a regression fix somewhere? Why is this needed in 5.15.y and > > why can't people who need this new feature just use a newer kernel > > version (5.19?) > > It's half-broken implementation of the kexec kernel verification. At the time > it was implemented for arm64 we had the platform and secondary keyrings > and x86 was using them but on arm64 the initial implementation ignores > them. Ok, so it's something that never worked. Adding support to get it to work doesn't really fall into the stable kernel rules, right? Again, what's wrong with 5.19 for anyone who wants this? Who does want this? thanks, greg k-h
On Sat, Sep 24, 2022 at 12:13:34PM +0200, Greg Kroah-Hartman wrote: > On Sat, Sep 24, 2022 at 11:45:21AM +0200, Michal Suchánek wrote: > > On Sat, Sep 24, 2022 at 11:19:19AM +0200, Greg Kroah-Hartman wrote: > > > On Fri, Sep 23, 2022 at 07:10:28PM +0200, Michal Suchanek wrote: > > > > Hello, > > > > > > > > this is backport of commit 0d519cadf751 > > > > ("arm64: kexec_file: use more system keyrings to verify kernel image signature") > > > > to table 5.15 tree including the preparatory patches. > > > > > > This feels to me like a new feature for arm64, one that has never worked > > > before and you are just making it feature-parity with x86, right? > > > > > > Or is this a regression fix somewhere? Why is this needed in 5.15.y and > > > why can't people who need this new feature just use a newer kernel > > > version (5.19?) > > > > It's half-broken implementation of the kexec kernel verification. At the time > > it was implemented for arm64 we had the platform and secondary keyrings > > and x86 was using them but on arm64 the initial implementation ignores > > them. > > Ok, so it's something that never worked. Adding support to get it to > work doesn't really fall into the stable kernel rules, right? Not sure. It was defective, not using the facilities available at the time correctly. Which translates to kernels that can be kexec'd on x86 failing to kexec on arm64 without any explanation (signed with same key, built for the appropriate arch). > Again, what's wrong with 5.19 for anyone who wants this? Who does want > this? Not sure, really. The final patch was repeatedly backported to stable and failed to build because the prerequisites were missing. So this is a backport that includes the prerequisites for it to build. If nobody wanted this why is it repeatedly backported generating the failure messages? Thanks Michal
On Fri, Sep 23, 2022 at 09:16:50PM +0200, Michal Suchánek wrote: > Hello, > > On Fri, Sep 23, 2022 at 03:03:36PM -0400, Mimi Zohar wrote: > > On Fri, 2022-09-23 at 19:10 +0200, Michal Suchanek wrote: > > > Hello, > > > > > > this is backport of commit 0d519cadf751 > > > ("arm64: kexec_file: use more system keyrings to verify kernel image signature") > > > to table 5.15 tree including the preparatory patches. > > > > > > Some patches needed minor adjustment for context. > > > > In general when backporting this patch set, there should be a > > dependency on backporting these commits as well. In this instance for > > linux-5.15.y, they've already been backported. > > > > 543ce63b664e ("lockdown: Fix kexec lockdown bypass with ima policy") AFAICT this is everywhere relevant, likely because it's considered a CVE fix. > > af16df54b89d ("ima: force signature verification when CONFIG_KEXEC_SIG is configured") This is missing in 5.4, and 5.4 is missing this prerequisite: fd7af71be542 ("kexec: do not verify the signature without the lockdown or mandatory signature") > > Thanks for bringing these up. It might be in general useful to backport > these fixes as well. > > However, this patchset does one very specific thing: it lifts the x86 > kexec_file signature verification to arch-independent and uses it on > arm64 to unify all features (and any existing warts) between EFI > architectures. > > So unless I am missing something the fixes you pointed out are > completely independent of this. > > Thanks > > Michal
On Sat, Sep 24, 2022 at 01:55:23PM +0200, Michal Suchánek wrote: > On Sat, Sep 24, 2022 at 12:13:34PM +0200, Greg Kroah-Hartman wrote: > > On Sat, Sep 24, 2022 at 11:45:21AM +0200, Michal Suchánek wrote: > > > On Sat, Sep 24, 2022 at 11:19:19AM +0200, Greg Kroah-Hartman wrote: > > > > On Fri, Sep 23, 2022 at 07:10:28PM +0200, Michal Suchanek wrote: > > > > > Hello, > > > > > > > > > > this is backport of commit 0d519cadf751 > > > > > ("arm64: kexec_file: use more system keyrings to verify kernel image signature") > > > > > to table 5.15 tree including the preparatory patches. > > > > > > > > This feels to me like a new feature for arm64, one that has never worked > > > > before and you are just making it feature-parity with x86, right? > > > > > > > > Or is this a regression fix somewhere? Why is this needed in 5.15.y and > > > > why can't people who need this new feature just use a newer kernel > > > > version (5.19?) > > > > > > It's half-broken implementation of the kexec kernel verification. At the time > > > it was implemented for arm64 we had the platform and secondary keyrings > > > and x86 was using them but on arm64 the initial implementation ignores > > > them. > > > > Ok, so it's something that never worked. Adding support to get it to > > work doesn't really fall into the stable kernel rules, right? > > Not sure. It was defective, not using the facilities available at the > time correctly. Which translates to kernels that can be kexec'd on x86 > failing to kexec on arm64 without any explanation (signed with same key, > built for the appropriate arch). Feature parity across architectures is not a "regression", but rather a "this feature is not implemented for this architecture yet" type of thing. > > Again, what's wrong with 5.19 for anyone who wants this? Who does want > > this? > > Not sure, really. > > The final patch was repeatedly backported to stable and failed to build > because the prerequisites were missing. That's because it was tagged, but now that you show the full set of requirements, it's pretty obvious to me that this is not relevant for going this far back. thanks, greg k-h
On Mon, Sep 26, 2022 at 08:47:32AM +0200, Greg Kroah-Hartman wrote: > On Sat, Sep 24, 2022 at 01:55:23PM +0200, Michal Suchánek wrote: > > On Sat, Sep 24, 2022 at 12:13:34PM +0200, Greg Kroah-Hartman wrote: > > > On Sat, Sep 24, 2022 at 11:45:21AM +0200, Michal Suchánek wrote: > > > > On Sat, Sep 24, 2022 at 11:19:19AM +0200, Greg Kroah-Hartman wrote: > > > > > On Fri, Sep 23, 2022 at 07:10:28PM +0200, Michal Suchanek wrote: > > > > > > Hello, > > > > > > > > > > > > this is backport of commit 0d519cadf751 > > > > > > ("arm64: kexec_file: use more system keyrings to verify kernel image signature") > > > > > > to table 5.15 tree including the preparatory patches. > > > > > > > > > > This feels to me like a new feature for arm64, one that has never worked > > > > > before and you are just making it feature-parity with x86, right? > > > > > > > > > > Or is this a regression fix somewhere? Why is this needed in 5.15.y and > > > > > why can't people who need this new feature just use a newer kernel > > > > > version (5.19?) > > > > > > > > It's half-broken implementation of the kexec kernel verification. At the time > > > > it was implemented for arm64 we had the platform and secondary keyrings > > > > and x86 was using them but on arm64 the initial implementation ignores > > > > them. > > > > > > Ok, so it's something that never worked. Adding support to get it to > > > work doesn't really fall into the stable kernel rules, right? > > > > Not sure. It was defective, not using the facilities available at the > > time correctly. Which translates to kernels that can be kexec'd on x86 > > failing to kexec on arm64 without any explanation (signed with same key, > > built for the appropriate arch). > > Feature parity across architectures is not a "regression", but rather a > "this feature is not implemented for this architecture yet" type of > thing. That depends on the view - before kexec verification you could boot any kernel, now you can boot some kernels signed with a valid key, but not others - the initial implementation is buggy, probably because it is based on an old version of the x86 code. > > > > Again, what's wrong with 5.19 for anyone who wants this? Who does want > > > this? > > > > Not sure, really. > > > > The final patch was repeatedly backported to stable and failed to build > > because the prerequisites were missing. > > That's because it was tagged, but now that you show the full set of > requirements, it's pretty obvious to me that this is not relevant for > going this far back. That also works. Thanks Michal
On Mon, Sep 26, 2022 at 09:40:25AM +0200, Michal Such??nek wrote: > On Mon, Sep 26, 2022 at 08:47:32AM +0200, Greg Kroah-Hartman wrote: > > On Sat, Sep 24, 2022 at 01:55:23PM +0200, Michal Suchánek wrote: > > > On Sat, Sep 24, 2022 at 12:13:34PM +0200, Greg Kroah-Hartman wrote: > > > > On Sat, Sep 24, 2022 at 11:45:21AM +0200, Michal Suchánek wrote: > > > > > On Sat, Sep 24, 2022 at 11:19:19AM +0200, Greg Kroah-Hartman wrote: > > > > > > On Fri, Sep 23, 2022 at 07:10:28PM +0200, Michal Suchanek wrote: > > > > > > > Hello, > > > > > > > > > > > > > > this is backport of commit 0d519cadf751 > > > > > > > ("arm64: kexec_file: use more system keyrings to verify kernel image signature") > > > > > > > to table 5.15 tree including the preparatory patches. > > > > > > > > > > > > This feels to me like a new feature for arm64, one that has never worked > > > > > > before and you are just making it feature-parity with x86, right? > > > > > > > > > > > > Or is this a regression fix somewhere? Why is this needed in 5.15.y and > > > > > > why can't people who need this new feature just use a newer kernel > > > > > > version (5.19?) > > > > > > > > > > It's half-broken implementation of the kexec kernel verification. At the time > > > > > it was implemented for arm64 we had the platform and secondary keyrings > > > > > and x86 was using them but on arm64 the initial implementation ignores > > > > > them. > > > > > > > > Ok, so it's something that never worked. Adding support to get it to > > > > work doesn't really fall into the stable kernel rules, right? > > > > > > Not sure. It was defective, not using the facilities available at the > > > time correctly. Which translates to kernels that can be kexec'd on x86 > > > failing to kexec on arm64 without any explanation (signed with same key, > > > built for the appropriate arch). > > > > Feature parity across architectures is not a "regression", but rather a > > "this feature is not implemented for this architecture yet" type of > > thing. > > That depends on the view - before kexec verification you could boot any > kernel, now you can boot some kernels signed with a valid key, but not > others - the initial implementation is buggy, probably because it > is based on an old version of the x86 code. Buggy? The feature of supporting platform ring had been slipped in just before I submitted the latest patch series which was eventually merged. (I should have noticed it though.) Looking at changes in the commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify"), it seems to be obvious that it is a new feature because it introduced a new Kconfig option, CONFIG_INTEGRITY_PLATFORM_KEYRING, which allows for enabling/disabling platform ring support. -Takahiro Akashi > > > > > > Again, what's wrong with 5.19 for anyone who wants this? Who does want > > > > this? > > > > > > Not sure, really. > > > > > > The final patch was repeatedly backported to stable and failed to build > > > because the prerequisites were missing. > > > > That's because it was tagged, but now that you show the full set of > > requirements, it's pretty obvious to me that this is not relevant for > > going this far back. > > That also works. > > Thanks > > Michal
On Tue, Sep 27, 2022 at 11:39:52AM +0900, AKASHI Takahiro wrote: > On Mon, Sep 26, 2022 at 09:40:25AM +0200, Michal Such??nek wrote: > > On Mon, Sep 26, 2022 at 08:47:32AM +0200, Greg Kroah-Hartman wrote: > > > On Sat, Sep 24, 2022 at 01:55:23PM +0200, Michal Suchánek wrote: > > > > On Sat, Sep 24, 2022 at 12:13:34PM +0200, Greg Kroah-Hartman wrote: > > > > > On Sat, Sep 24, 2022 at 11:45:21AM +0200, Michal Suchánek wrote: > > > > > > On Sat, Sep 24, 2022 at 11:19:19AM +0200, Greg Kroah-Hartman wrote: > > > > > > > On Fri, Sep 23, 2022 at 07:10:28PM +0200, Michal Suchanek wrote: > > > > > > > > Hello, > > > > > > > > > > > > > > > > this is backport of commit 0d519cadf751 > > > > > > > > ("arm64: kexec_file: use more system keyrings to verify kernel image signature") > > > > > > > > to table 5.15 tree including the preparatory patches. > > > > > > > > > > > > > > This feels to me like a new feature for arm64, one that has never worked > > > > > > > before and you are just making it feature-parity with x86, right? > > > > > > > > > > > > > > Or is this a regression fix somewhere? Why is this needed in 5.15.y and > > > > > > > why can't people who need this new feature just use a newer kernel > > > > > > > version (5.19?) > > > > > > > > > > > > It's half-broken implementation of the kexec kernel verification. At the time > > > > > > it was implemented for arm64 we had the platform and secondary keyrings > > > > > > and x86 was using them but on arm64 the initial implementation ignores > > > > > > them. > > > > > > > > > > Ok, so it's something that never worked. Adding support to get it to > > > > > work doesn't really fall into the stable kernel rules, right? > > > > > > > > Not sure. It was defective, not using the facilities available at the > > > > time correctly. Which translates to kernels that can be kexec'd on x86 > > > > failing to kexec on arm64 without any explanation (signed with same key, > > > > built for the appropriate arch). > > > > > > Feature parity across architectures is not a "regression", but rather a > > > "this feature is not implemented for this architecture yet" type of > > > thing. > > > > That depends on the view - before kexec verification you could boot any > > kernel, now you can boot some kernels signed with a valid key, but not > > others - the initial implementation is buggy, probably because it > > is based on an old version of the x86 code. > > Buggy? > The feature of supporting platform ring had been slipped in just before > I submitted the latest patch series which was eventually merged. > (I should have noticed it though.) It's difficult to notice another in-flight patch that does not conflict with yours, and is for a different architecture. That's why we have followup patches and Fixes tags. However, the support for secondary keyring was added in 4.19 by commit ea93102f3224 ("Fix kexec forbidding kernels signed with keys in the secondary keyring to boot") which was not supported by the arm64 code either. > Looking at changes in the commit 278311e417be ("kexec, KEYS: Make use of platform > keyring for signature verify"), it seems to be obvious that it is a new feature > because it introduced a new Kconfig option, CONFIG_INTEGRITY_PLATFORM_KEYRING, > which allows for enabling/disabling platform ring support. Yes, and that feature exists since 5.1, and we are talking about 5.15 here. Not making use of the keyring that is supported by the kernel results in inability to kexec kernels that are signed by a valid key, arguably a bug. Thanks Michal
Hello, this is backport of commit 0d519cadf751 ("arm64: kexec_file: use more system keyrings to verify kernel image signature") to table 5.15 tree including the preparatory patches. Some patches needed minor adjustment for context. Thanks Michal Coiby Xu (3): kexec: clean up arch_kexec_kernel_verify_sig kexec, KEYS: make the code in bzImage64_verify_sig generic arm64: kexec_file: use more system keyrings to verify kernel image signature Naveen N. Rao (2): kexec_file: drop weak attribute from functions kexec: drop weak attribute from functions Sven Schnelle (1): s390/kexec_file: move kernel image size check arch/arm64/include/asm/kexec.h | 20 ++++++- arch/arm64/kernel/kexec_image.c | 11 +--- arch/powerpc/include/asm/kexec.h | 14 +++++ arch/s390/boot/head.S | 2 - arch/s390/include/asm/kexec.h | 14 +++++ arch/s390/include/asm/setup.h | 1 - arch/s390/kernel/machine_kexec_file.c | 17 +----- arch/x86/include/asm/kexec.h | 12 ++++ arch/x86/kernel/kexec-bzimage64.c | 20 +------ include/linux/kexec.h | 82 ++++++++++++++++++++++---- kernel/kexec_core.c | 27 --------- kernel/kexec_file.c | 83 ++++++++++----------------- 12 files changed, 163 insertions(+), 140 deletions(-)