drivers/infiniband/core/device.c | 4 +- include/linux/security.h | 12 +-- security/integrity/ima/ima.h | 2 + security/integrity/ima/ima_main.c | 8 ++ security/integrity/ima/ima_policy.c | 151 ++++++++++++++++++++++------ security/security.c | 23 +++-- security/selinux/hooks.c | 2 +- security/selinux/selinuxfs.c | 2 +- 8 files changed, 155 insertions(+), 49 deletions(-)
This series backports patches in order to resolve the issue discussed here: https://lore.kernel.org/selinux/389334fe-6e12-96b2-6ce9-9f0e8fcb85bf@huawei.com/ This required backporting the non-blocking LSM policy update mechanism prerequisite patches. Paul Moore has reviewed the non-blocking LSM policy update backport, saying the SELinux part look good. The patchset was also reviewed by Mimi Zohar and everything looks ok. I've tested the patches against the said issue and can confirm that the issue is fixed. I've also run the LTP testcases on the fixed IMA and all tests are passed. This is a re-send of the original patchset as the original patchset might have a faulty cover letter. The original patchset could be found here: https://patchwork.kernel.org/project/linux-integrity/list/?series=709367 GUO Zihua (1): ima: Handle -ESTALE returned by ima_filter_rule_match() Janne Karhunen (2): LSM: switch to blocking policy update notifiers ima: use the lsm policy update notifier drivers/infiniband/core/device.c | 4 +- include/linux/security.h | 12 +-- security/integrity/ima/ima.h | 2 + security/integrity/ima/ima_main.c | 8 ++ security/integrity/ima/ima_policy.c | 151 ++++++++++++++++++++++------ security/security.c | 23 +++-- security/selinux/hooks.c | 2 +- security/selinux/selinuxfs.c | 2 +- 8 files changed, 155 insertions(+), 49 deletions(-) -- 2.17.1
On Wed, Feb 01, 2023 at 10:39:49AM +0800, GUO Zihua wrote: >This series backports patches in order to resolve the issue discussed here: >https://lore.kernel.org/selinux/389334fe-6e12-96b2-6ce9-9f0e8fcb85bf@huawei.com/ > >This required backporting the non-blocking LSM policy update mechanism >prerequisite patches. Do we not need this on newer kernels? Why only 4.19? -- Thanks, Sasha
On 2023/2/3 1:20, Sasha Levin wrote: > On Wed, Feb 01, 2023 at 10:39:49AM +0800, GUO Zihua wrote: >> This series backports patches in order to resolve the issue discussed >> here: >> https://lore.kernel.org/selinux/389334fe-6e12-96b2-6ce9-9f0e8fcb85bf@huawei.com/ >> >> This required backporting the non-blocking LSM policy update mechanism >> prerequisite patches. > > Do we not need this on newer kernels? Why only 4.19? > Hi Sasha. The issue mentioned in this patch was fixed already in the newer kernel. All three patches here are backports from mainline. -- Best GUO Zihua
On Fri, Feb 03, 2023 at 09:10:13AM +0800, Guozihua (Scott) wrote: > On 2023/2/3 1:20, Sasha Levin wrote: > > On Wed, Feb 01, 2023 at 10:39:49AM +0800, GUO Zihua wrote: > >> This series backports patches in order to resolve the issue discussed > >> here: > >> https://lore.kernel.org/selinux/389334fe-6e12-96b2-6ce9-9f0e8fcb85bf@huawei.com/ > >> > >> This required backporting the non-blocking LSM policy update mechanism > >> prerequisite patches. > > > > Do we not need this on newer kernels? Why only 4.19? > > > Hi Sasha. > > The issue mentioned in this patch was fixed already in the newer kernel. > All three patches here are backports from mainline. Ok, now queued up, thanks. greg k-h
On Fri, Feb 03, 2023 at 08:44:51AM +0100, Greg KH wrote: > On Fri, Feb 03, 2023 at 09:10:13AM +0800, Guozihua (Scott) wrote: > > On 2023/2/3 1:20, Sasha Levin wrote: > > > On Wed, Feb 01, 2023 at 10:39:49AM +0800, GUO Zihua wrote: > > >> This series backports patches in order to resolve the issue discussed > > >> here: > > >> https://lore.kernel.org/selinux/389334fe-6e12-96b2-6ce9-9f0e8fcb85bf@huawei.com/ > > >> > > >> This required backporting the non-blocking LSM policy update mechanism > > >> prerequisite patches. > > > > > > Do we not need this on newer kernels? Why only 4.19? > > > > > Hi Sasha. > > > > The issue mentioned in this patch was fixed already in the newer kernel. > > All three patches here are backports from mainline. > > Ok, now queued up, thanks. Nope, I've now dropped them all as you did not include the needed fix up commits as well. We can not add patches to the stable tree that are known broken, right? How well did you test this? I see at least 3 missing patches that you should have had in this patch series for it to work properly. greg k-h
On Fri, Feb 03, 2023 at 08:49:05AM +0100, Greg KH wrote:
> On Fri, Feb 03, 2023 at 08:44:51AM +0100, Greg KH wrote:
> > On Fri, Feb 03, 2023 at 09:10:13AM +0800, Guozihua (Scott) wrote:
> > > On 2023/2/3 1:20, Sasha Levin wrote:
> > > > On Wed, Feb 01, 2023 at 10:39:49AM +0800, GUO Zihua wrote:
> > > >> This series backports patches in order to resolve the issue discussed
> > > >> here:
> > > >> https://lore.kernel.org/selinux/389334fe-6e12-96b2-6ce9-9f0e8fcb85bf@huawei.com/
> > > >>
> > > >> This required backporting the non-blocking LSM policy update mechanism
> > > >> prerequisite patches.
> > > >
> > > > Do we not need this on newer kernels? Why only 4.19?
> > > >
> > > Hi Sasha.
> > >
> > > The issue mentioned in this patch was fixed already in the newer kernel.
> > > All three patches here are backports from mainline.
> >
> > Ok, now queued up, thanks.
>
> Nope, I've now dropped them all as you did not include the needed fix up
> commits as well. We can not add patches to the stable tree that are
> known broken, right?
>
> How well did you test this? I see at least 3 missing patches that you
> should have had in this patch series for it to work properly.
Ah, you didn't even test this series, as it breaks the build
as-submitted.
{sigh}
In order for us to take this, I think you need to find someone else who
will validate your patch series _FIRST_ before submitting it to us. And
I want their tested-by on them validating that it did actually work (if
for no other reason than to have someone else be willing to be
responsible if things go bad.)
Breaking our builds and forcing me to point out missing patches is not
how the stable kernel process works in any sane manner.
greg k-h
On 2023/2/3 15:54, Greg KH wrote:
> On Fri, Feb 03, 2023 at 08:49:05AM +0100, Greg KH wrote:
>> On Fri, Feb 03, 2023 at 08:44:51AM +0100, Greg KH wrote:
>>> On Fri, Feb 03, 2023 at 09:10:13AM +0800, Guozihua (Scott) wrote:
>>>> On 2023/2/3 1:20, Sasha Levin wrote:
>>>>> On Wed, Feb 01, 2023 at 10:39:49AM +0800, GUO Zihua wrote:
>>>>>> This series backports patches in order to resolve the issue discussed
>>>>>> here:
>>>>>> https://lore.kernel.org/selinux/389334fe-6e12-96b2-6ce9-9f0e8fcb85bf@huawei.com/
>>>>>>
>>>>>> This required backporting the non-blocking LSM policy update mechanism
>>>>>> prerequisite patches.
>>>>>
>>>>> Do we not need this on newer kernels? Why only 4.19?
>>>>>
>>>> Hi Sasha.
>>>>
>>>> The issue mentioned in this patch was fixed already in the newer kernel.
>>>> All three patches here are backports from mainline.
>>>
>>> Ok, now queued up, thanks.
>>
>> Nope, I've now dropped them all as you did not include the needed fix up
>> commits as well. We can not add patches to the stable tree that are
>> known broken, right?
>>
>> How well did you test this? I see at least 3 missing patches that you
>> should have had in this patch series for it to work properly.
>
> Ah, you didn't even test this series, as it breaks the build
> as-submitted.
>
> {sigh}
>
> In order for us to take this, I think you need to find someone else who
> will validate your patch series _FIRST_ before submitting it to us. And
> I want their tested-by on them validating that it did actually work (if
> for no other reason than to have someone else be willing to be
> responsible if things go bad.)
>
> Breaking our builds and forcing me to point out missing patches is not
> how the stable kernel process works in any sane manner.
>
> greg k-h
Sorry for the burden. Still trying to work out how things are done here.
It seems that when I test it out, it did not build with the allmodconfig
which would report an error. And by the "fixes up commit" I supposed it
mean the commits with the "Fixes" tag points to the three commits I
submitted.
I'll submit a new patch set soon, which would include the following
fixes commits.
Again, sorry for the burden.
--
Best
GUO Zihua
© 2016 - 2025 Red Hat, Inc.