This patch series adds a .platform_trusted_keys in system_keyring as the
reference to .platform keyring in integrity subsystem, when platform
keyring is being initialized it will be updated. So other component could
use this keyring as well.
This patch series also let kexec_file_load use platform keyring as fall
back if it failed to verify the image against secondary keyring, make it
possible to load kernel signed by third part key if third party key is
imported in the firmware.
After this patch kexec_file_load will be able to verify a signed PE
bzImage using keys in platform keyring.
Tested in a VM with locally signed kernel with pesign and imported the
cert to EFI's MokList variable.
Kairui Song (2):
integrity, KEYS: add a reference to platform keyring
kexec, KEYS: Make use of platform keyring for signature verify
Update from V2:
- Use IS_ENABLED in kexec_file_load to judge if platform_trusted_keys
should be used for verifying image as suggested by Mimi Zohar
Update from V1:
- Make platform_trusted_keys static, and update commit message as suggested
by Mimi Zohar
- Always check if platform keyring is initialized before use it
Kairui Song (2):
integrity, KEYS: add a reference to platform keyring
kexec, KEYS: Make use of platform keyring for signature verify
arch/x86/kernel/kexec-bzimage64.c | 13 ++++++++++---
certs/system_keyring.c | 22 +++++++++++++++++++++-
include/keys/system_keyring.h | 5 +++++
include/linux/verification.h | 1 +
security/integrity/digsig.c | 6 ++++++
5 files changed, 43 insertions(+), 4 deletions(-)
--
2.20.1
With KEXEC_BZIMAGE_VERIFY_SIG enabled, kexec_file_load will need to
verify the kernel image. The image might be signed with third part keys,
and the keys could be stored in firmware, then got loaded into the
.platform keyring. Now we have a symbol .platform_trusted_keyring as the
reference to .platform keyring, this patch makes use if it and allow
kexec_file_load to verify the image against keys in .platform keyring.
This commit adds a VERIFY_USE_PLATFORM_KEYRING similar to previous
VERIFY_USE_SECONDARY_KEYRING indicating that verify_pkcs7_signature
should verify the signature using platform keyring. Also, decrease
the error message log level when verification failed with -ENOKEY,
so that if called tried multiple time with different keyring it
won't generate extra noises.
Signed-off-by: Kairui Song <[email protected]>
---
arch/x86/kernel/kexec-bzimage64.c | 13 ++++++++++---
certs/system_keyring.c | 13 ++++++++++++-
include/linux/verification.h | 1 +
3 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
index 7d97e432cbbc..2c007abd3d40 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -534,9 +534,16 @@ static int bzImage64_cleanup(void *loader_data)
#ifdef CONFIG_KEXEC_BZIMAGE_VERIFY_SIG
static int bzImage64_verify_sig(const char *kernel, unsigned long kernel_len)
{
- return verify_pefile_signature(kernel, kernel_len,
- VERIFY_USE_SECONDARY_KEYRING,
- VERIFYING_KEXEC_PE_SIGNATURE);
+ int ret;
+ ret = verify_pefile_signature(kernel, kernel_len,
+ VERIFY_USE_SECONDARY_KEYRING,
+ VERIFYING_KEXEC_PE_SIGNATURE);
+ if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING)) {
+ ret = verify_pefile_signature(kernel, kernel_len,
+ VERIFY_USE_PLATFORM_KEYRING,
+ VERIFYING_KEXEC_PE_SIGNATURE);
+ }
+ return ret;
}
#endif
diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 4690ef9cda8a..7085c286f4bd 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -240,11 +240,22 @@ int verify_pkcs7_signature(const void *data, size_t len,
#else
trusted_keys = builtin_trusted_keys;
#endif
+ } else if (trusted_keys == VERIFY_USE_PLATFORM_KEYRING) {
+#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
+ trusted_keys = platform_trusted_keys;
+#else
+ trusted_keys = NULL;
+#endif
+ if (!trusted_keys) {
+ ret = -ENOKEY;
+ pr_devel("PKCS#7 platform keyring is not available\n");
+ goto error;
+ }
}
ret = pkcs7_validate_trust(pkcs7, trusted_keys);
if (ret < 0) {
if (ret == -ENOKEY)
- pr_err("PKCS#7 signature not signed with a trusted key\n");
+ pr_devel("PKCS#7 signature not signed with a trusted key\n");
goto error;
}
diff --git a/include/linux/verification.h b/include/linux/verification.h
index cfa4730d607a..018fb5f13d44 100644
--- a/include/linux/verification.h
+++ b/include/linux/verification.h
@@ -17,6 +17,7 @@
* should be used.
*/
#define VERIFY_USE_SECONDARY_KEYRING ((struct key *)1UL)
+#define VERIFY_USE_PLATFORM_KEYRING ((struct key *)2UL)
/*
* The use to which an asymmetric key is being put.
--
2.20.1
Currently when loading new kernel via kexec_file_load syscall, it is able
to verify the signed PE bzimage against .builtin_trusted_keys or
.secondary_trusted_keys. But the image could be signed with third part
keys which will be provided by platform or firmware as EFI variable (eg.
stored in MokListRT EFI variable), and the keys won't be available in
keyrings mentioned above.
After commit 9dc92c45177a ('integrity: Define a trusted platform keyring')
a .platform keyring is introduced to store the keys provided by platform
or firmware, this keyring is intended to be used for verifying kernel
images being loaded by kexec_file_load syscall. And with a few following
up commits, keys provided by firmware is being loaded into this keyring,
and IMA-appraisal is able to use the keyring to verify kernel images.
IMA is the currently the only user of that keyring.
This patch exposes the .platform, and makes it useable for other
components. For example, kexec_file_load could use this .platform
keyring to verify the kernel image's image.
Suggested-by: Mimi Zohar <[email protected]>
Signed-off-by: Kairui Song <[email protected]>
---
certs/system_keyring.c | 9 +++++++++
include/keys/system_keyring.h | 5 +++++
security/integrity/digsig.c | 6 ++++++
3 files changed, 20 insertions(+)
diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 81728717523d..4690ef9cda8a 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -24,6 +24,9 @@ static struct key *builtin_trusted_keys;
#ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
static struct key *secondary_trusted_keys;
#endif
+#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
+static struct key *platform_trusted_keys;
+#endif
extern __initconst const u8 system_certificate_list[];
extern __initconst const unsigned long system_certificate_list_size;
@@ -265,4 +268,10 @@ int verify_pkcs7_signature(const void *data, size_t len,
}
EXPORT_SYMBOL_GPL(verify_pkcs7_signature);
+#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
+void __init set_platform_trusted_keys(struct key *keyring) {
+ platform_trusted_keys = keyring;
+}
+#endif
+
#endif /* CONFIG_SYSTEM_DATA_VERIFICATION */
diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
index 359c2f936004..9e1b7849b6aa 100644
--- a/include/keys/system_keyring.h
+++ b/include/keys/system_keyring.h
@@ -61,5 +61,10 @@ static inline struct key *get_ima_blacklist_keyring(void)
}
#endif /* CONFIG_IMA_BLACKLIST_KEYRING */
+#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
+
+extern void __init set_platform_trusted_keys(struct key* keyring);
+
+#endif /* CONFIG_INTEGRITY_PLATFORM_KEYRING */
#endif /* _KEYS_SYSTEM_KEYRING_H */
diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index f45d6edecf99..bfabc2a8111d 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -89,6 +89,12 @@ static int __integrity_init_keyring(const unsigned int id, key_perm_t perm,
keyring[id] = NULL;
}
+#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
+ if (id == INTEGRITY_KEYRING_PLATFORM) {
+ set_platform_trusted_keys(keyring[id]);
+ }
+#endif
+
return err;
}
--
2.20.1
On Wed, 2019-01-16 at 18:16 +0800, Kairui Song wrote:
> Currently when loading new kernel via kexec_file_load syscall, it is able
> to verify the signed PE bzimage against .builtin_trusted_keys or
> .secondary_trusted_keys. But the image could be signed with third part
> keys which will be provided by platform or firmware as EFI variable (eg.
> stored in MokListRT EFI variable), and the keys won't be available in
> keyrings mentioned above.
>
> After commit 9dc92c45177a ('integrity: Define a trusted platform keyring')
> a .platform keyring is introduced to store the keys provided by platform
> or firmware, this keyring is intended to be used for verifying kernel
> images being loaded by kexec_file_load syscall. And with a few following
> up commits, keys provided by firmware is being loaded into this keyring,
> and IMA-appraisal is able to use the keyring to verify kernel images.
> IMA is the currently the only user of that keyring.
How about simply saying, Commit "...." introduced a platform keyring
for storing preboot keys, used for verifying the kexec kernel image's
signature.
> This patch exposes the .platform, and makes it useable for other
> components. For example, kexec_file_load could use this .platform
> keyring to verify the kernel image's image.
The above statement is too generic. Please replace "and makes it
useable for other components" with " keyring, making it accessible for
verifying a PE signed kernel image".
>
> Suggested-by: Mimi Zohar <[email protected]>
> Signed-off-by: Kairui Song <[email protected]>
Reviewed/Tested-by: Mimi Zohar <[email protected]>
> ---
> certs/system_keyring.c | 9 +++++++++
> include/keys/system_keyring.h | 5 +++++
> security/integrity/digsig.c | 6 ++++++
> 3 files changed, 20 insertions(+)
>
> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
> index 81728717523d..4690ef9cda8a 100644
> --- a/certs/system_keyring.c
> +++ b/certs/system_keyring.c
> @@ -24,6 +24,9 @@ static struct key *builtin_trusted_keys;
> #ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
> static struct key *secondary_trusted_keys;
> #endif
> +#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
> +static struct key *platform_trusted_keys;
> +#endif
>
> extern __initconst const u8 system_certificate_list[];
> extern __initconst const unsigned long system_certificate_list_size;
> @@ -265,4 +268,10 @@ int verify_pkcs7_signature(const void *data, size_t len,
> }
> EXPORT_SYMBOL_GPL(verify_pkcs7_signature);
>
> +#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
> +void __init set_platform_trusted_keys(struct key *keyring) {
> + platform_trusted_keys = keyring;
> +}
> +#endif
> +
> #endif /* CONFIG_SYSTEM_DATA_VERIFICATION */
> diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
> index 359c2f936004..9e1b7849b6aa 100644
> --- a/include/keys/system_keyring.h
> +++ b/include/keys/system_keyring.h
> @@ -61,5 +61,10 @@ static inline struct key *get_ima_blacklist_keyring(void)
> }
> #endif /* CONFIG_IMA_BLACKLIST_KEYRING */
>
> +#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
> +
> +extern void __init set_platform_trusted_keys(struct key* keyring);
> +
> +#endif /* CONFIG_INTEGRITY_PLATFORM_KEYRING */
>
> #endif /* _KEYS_SYSTEM_KEYRING_H */
> diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
> index f45d6edecf99..bfabc2a8111d 100644
> --- a/security/integrity/digsig.c
> +++ b/security/integrity/digsig.c
> @@ -89,6 +89,12 @@ static int __integrity_init_keyring(const unsigned int id, key_perm_t perm,
> keyring[id] = NULL;
> }
>
> +#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
> + if (id == INTEGRITY_KEYRING_PLATFORM) {
> + set_platform_trusted_keys(keyring[id]);
> + }
> +#endif
> +
> return err;
> }
>
On Wed, 2019-01-16 at 18:16 +0800, Kairui Song wrote:
> With KEXEC_BZIMAGE_VERIFY_SIG enabled, kexec_file_load will need to
> verify the kernel image.
The kexec_file_load syscall can verify the PE signed kernel image
signature, the kernel image signature stored as an xattr, or both.
Anyone booting the system with the "appraise_tcb" policy or with a
similar appraise policy rule, wanting to only verifying the PE signed
kernel image, will need to include a "dont_appraise
func=KEXEC_KERNEL_CHECK" rule in their custom policy.
> The image might be signed with third part keys,
> and the keys could be stored in firmware, then got loaded into the
> .platform keyring. Now we have a symbol .platform_trusted_keyring as the
> reference to .platform keyring, this patch makes use if it and allow
> kexec_file_load to verify the image against keys in .platform keyring.
There's no need to introduce the concept of "third party" or "firmware
keys" here. Referring to them as the "preboot" keys, can simplify the
above paragraph.
>
> This commit adds a VERIFY_USE_PLATFORM_KEYRING similar to previous
> VERIFY_USE_SECONDARY_KEYRING indicating that verify_pkcs7_signature
> should verify the signature using platform keyring. Also, decrease
> the error message log level when verification failed with -ENOKEY,
> so that if called tried multiple time with different keyring it
> won't generate extra noises.
>
> Signed-off-by: Kairui Song <[email protected]>
Reviewed/Tested-by: Mimi Zohar <[email protected]>
> ---
> arch/x86/kernel/kexec-bzimage64.c | 13 ++++++++++---
> certs/system_keyring.c | 13 ++++++++++++-
> include/linux/verification.h | 1 +
> 3 files changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
> index 7d97e432cbbc..2c007abd3d40 100644
> --- a/arch/x86/kernel/kexec-bzimage64.c
> +++ b/arch/x86/kernel/kexec-bzimage64.c
> @@ -534,9 +534,16 @@ static int bzImage64_cleanup(void *loader_data)
> #ifdef CONFIG_KEXEC_BZIMAGE_VERIFY_SIG
> static int bzImage64_verify_sig(const char *kernel, unsigned long kernel_len)
> {
> - return verify_pefile_signature(kernel, kernel_len,
> - VERIFY_USE_SECONDARY_KEYRING,
> - VERIFYING_KEXEC_PE_SIGNATURE);
> + int ret;
> + ret = verify_pefile_signature(kernel, kernel_len,
> + VERIFY_USE_SECONDARY_KEYRING,
> + VERIFYING_KEXEC_PE_SIGNATURE);
> + if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING)) {
> + ret = verify_pefile_signature(kernel, kernel_len,
> + VERIFY_USE_PLATFORM_KEYRING,
> + VERIFYING_KEXEC_PE_SIGNATURE);
> + }
> + return ret;
> }
> #endif
>
> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
> index 4690ef9cda8a..7085c286f4bd 100644
> --- a/certs/system_keyring.c
> +++ b/certs/system_keyring.c
> @@ -240,11 +240,22 @@ int verify_pkcs7_signature(const void *data, size_t len,
> #else
> trusted_keys = builtin_trusted_keys;
> #endif
> + } else if (trusted_keys == VERIFY_USE_PLATFORM_KEYRING) {
> +#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
> + trusted_keys = platform_trusted_keys;
> +#else
> + trusted_keys = NULL;
> +#endif
> + if (!trusted_keys) {
> + ret = -ENOKEY;
> + pr_devel("PKCS#7 platform keyring is not available\n");
> + goto error;
> + }
> }
> ret = pkcs7_validate_trust(pkcs7, trusted_keys);
> if (ret < 0) {
> if (ret == -ENOKEY)
> - pr_err("PKCS#7 signature not signed with a trusted key\n");
> + pr_devel("PKCS#7 signature not signed with a trusted key\n");
> goto error;
> }
>
> diff --git a/include/linux/verification.h b/include/linux/verification.h
> index cfa4730d607a..018fb5f13d44 100644
> --- a/include/linux/verification.h
> +++ b/include/linux/verification.h
> @@ -17,6 +17,7 @@
> * should be used.
> */
> #define VERIFY_USE_SECONDARY_KEYRING ((struct key *)1UL)
> +#define VERIFY_USE_PLATFORM_KEYRING ((struct key *)2UL)
>
> /*
> * The use to which an asymmetric key is being put.
On Wed, 2019-01-16 at 18:16 +0800, Kairui Song wrote:
> This patch series adds a .platform_trusted_keys in system_keyring as the
> reference to .platform keyring in integrity subsystem, when platform
> keyring is being initialized it will be updated. So other component could
> use this keyring as well.
Remove "other component could use ...".
>
> This patch series also let kexec_file_load use platform keyring as fall
> back if it failed to verify the image against secondary keyring, make it
> possible to load kernel signed by third part key if third party key is
> imported in the firmware.
This is the only reason for these patches. Please remove "also".
>
> After this patch kexec_file_load will be able to verify a signed PE
> bzImage using keys in platform keyring.
>
> Tested in a VM with locally signed kernel with pesign and imported the
> cert to EFI's MokList variable.
It's taken so long for me to review/test this patch set due to a
regression in sanity_check_segment_list(), introduced somewhere
between 4.20 and 5.0.0-rc1. The sgement overlap test - "if ((mend >
pstart) && (mstart < pend))" - fails, returning a -EINVAL.
Is anyone else seeing this?
Mimi
>
> Kairui Song (2):
> integrity, KEYS: add a reference to platform keyring
> kexec, KEYS: Make use of platform keyring for signature verify
>
> Update from V2:
> - Use IS_ENABLED in kexec_file_load to judge if platform_trusted_keys
> should be used for verifying image as suggested by Mimi Zohar
>
> Update from V1:
> - Make platform_trusted_keys static, and update commit message as suggested
> by Mimi Zohar
> - Always check if platform keyring is initialized before use it
>
> Kairui Song (2):
> integrity, KEYS: add a reference to platform keyring
> kexec, KEYS: Make use of platform keyring for signature verify
>
> arch/x86/kernel/kexec-bzimage64.c | 13 ++++++++++---
> certs/system_keyring.c | 22 +++++++++++++++++++++-
> include/keys/system_keyring.h | 5 +++++
> include/linux/verification.h | 1 +
> security/integrity/digsig.c | 6 ++++++
> 5 files changed, 43 insertions(+), 4 deletions(-)
>
On 01/17/19 at 08:08pm, Mimi Zohar wrote:
> On Wed, 2019-01-16 at 18:16 +0800, Kairui Song wrote:
> > This patch series adds a .platform_trusted_keys in system_keyring as the
> > reference to .platform keyring in integrity subsystem, when platform
> > keyring is being initialized it will be updated. So other component could
> > use this keyring as well.
>
> Remove "other component could use ...".
> >
> > This patch series also let kexec_file_load use platform keyring as fall
> > back if it failed to verify the image against secondary keyring, make it
> > possible to load kernel signed by third part key if third party key is
> > imported in the firmware.
>
> This is the only reason for these patches. ?Please remove "also".
>
> >
> > After this patch kexec_file_load will be able to verify a signed PE
> > bzImage using keys in platform keyring.
> >
> > Tested in a VM with locally signed kernel with pesign and imported the
> > cert to EFI's MokList variable.
>
> It's taken so long for me to review/test this patch set due to a
> regression in sanity_check_segment_list(), introduced somewhere
> between 4.20 and 5.0.0-rc1. ?The sgement overlap test - "if ((mend >
> pstart) && (mstart < pend))" - fails, returning a -EINVAL.
>
> Is anyone else seeing this?
Mimi, should be this issue? I have sent a fix for that.
https://lore.kernel.org/lkml/[email protected]/
Thanks
Dave
On Fri, 2019-01-18 at 09:35 +0800, Dave Young wrote:
> On 01/17/19 at 08:08pm, Mimi Zohar wrote:
> > It's taken so long for me to review/test this patch set due to a
> > regression in sanity_check_segment_list(), introduced somewhere
> > between 4.20 and 5.0.0-rc1. The sgement overlap test - "if ((mend >
> > pstart) && (mstart < pend))" - fails, returning a -EINVAL.
> >
> > Is anyone else seeing this?
>
> Mimi, should be this issue? I have sent a fix for that.
> https://lore.kernel.org/lkml/[email protected]/
Thanks, that resolved the regression.
Mimi
On 01/18/19 at 09:35am, Dave Young wrote:
> On 01/17/19 at 08:08pm, Mimi Zohar wrote:
> > On Wed, 2019-01-16 at 18:16 +0800, Kairui Song wrote:
> > > This patch series adds a .platform_trusted_keys in system_keyring as the
> > > reference to .platform keyring in integrity subsystem, when platform
> > > keyring is being initialized it will be updated. So other component could
> > > use this keyring as well.
> >
> > Remove "other component could use ...".
> > >
> > > This patch series also let kexec_file_load use platform keyring as fall
> > > back if it failed to verify the image against secondary keyring, make it
> > > possible to load kernel signed by third part key if third party key is
> > > imported in the firmware.
> >
> > This is the only reason for these patches. ?Please remove "also".
> >
> > >
> > > After this patch kexec_file_load will be able to verify a signed PE
> > > bzImage using keys in platform keyring.
> > >
> > > Tested in a VM with locally signed kernel with pesign and imported the
> > > cert to EFI's MokList variable.
> >
> > It's taken so long for me to review/test this patch set due to a
> > regression in sanity_check_segment_list(), introduced somewhere
> > between 4.20 and 5.0.0-rc1. ?The sgement overlap test - "if ((mend >
> > pstart) && (mstart < pend))" - fails, returning a -EINVAL.
> >
> > Is anyone else seeing this?
>
> Mimi, should be this issue? I have sent a fix for that.
> https://lore.kernel.org/lkml/[email protected]/
Hi, Kairui, I think you should know this while working on this series,
It is good to mention the test dependency in cover letter so that reviewers
can save time.
BTW, Boris took it in tip already:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=993a110319a4a60aadbd02f6defdebe048f7773b
>
> Thanks
> Dave
On Fri, Jan 18, 2019 at 10:00 AM Dave Young <[email protected]> wrote:
>
> On 01/18/19 at 09:35am, Dave Young wrote:
> > On 01/17/19 at 08:08pm, Mimi Zohar wrote:
> > > On Wed, 2019-01-16 at 18:16 +0800, Kairui Song wrote:
> > > > This patch series adds a .platform_trusted_keys in system_keyring as the
> > > > reference to .platform keyring in integrity subsystem, when platform
> > > > keyring is being initialized it will be updated. So other component could
> > > > use this keyring as well.
> > >
> > > Remove "other component could use ...".
> > > >
> > > > This patch series also let kexec_file_load use platform keyring as fall
> > > > back if it failed to verify the image against secondary keyring, make it
> > > > possible to load kernel signed by third part key if third party key is
> > > > imported in the firmware.
> > >
> > > This is the only reason for these patches. Please remove "also".
> > >
> > > >
> > > > After this patch kexec_file_load will be able to verify a signed PE
> > > > bzImage using keys in platform keyring.
> > > >
> > > > Tested in a VM with locally signed kernel with pesign and imported the
> > > > cert to EFI's MokList variable.
> > >
> > > It's taken so long for me to review/test this patch set due to a
> > > regression in sanity_check_segment_list(), introduced somewhere
> > > between 4.20 and 5.0.0-rc1. The sgement overlap test - "if ((mend >
> > > pstart) && (mstart < pend))" - fails, returning a -EINVAL.
> > >
> > > Is anyone else seeing this?
> >
> > Mimi, should be this issue? I have sent a fix for that.
> > https://lore.kernel.org/lkml/[email protected]/
>
> Hi, Kairui, I think you should know this while working on this series,
> It is good to mention the test dependency in cover letter so that reviewers
> can save time.
>
> BTW, Boris took it in tip already:
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=993a110319a4a60aadbd02f6defdebe048f7773b
>
Hi, thanks for the suggestion, I did apply your patch to avoid the
failure. Will add such info next time.
Will send out V4 and update commit message as suggested by Mimi
--
Best Regards,
Kairui Song