On 2022/12/9 18:27, Greg KH wrote: > On Fri, Dec 09, 2022 at 05:38:00PM +0800, Guozihua (Scott) wrote: >> On 2022/12/9 17:32, Guozihua (Scott) wrote: >>> On 2022/12/9 17:22, Greg KH wrote: >>>> On Fri, Dec 09, 2022 at 05:11:40PM +0800, Guozihua (Scott) wrote: >>>>> On 2022/12/9 17:00, Greg KH wrote: >>>>>> On Fri, Dec 09, 2022 at 04:59:17PM +0800, Guozihua (Scott) wrote: >>>>>>> On 2022/12/9 16:46, Greg KH wrote: >>>>>>>> On Fri, Dec 09, 2022 at 03:53:25PM +0800, Guozihua (Scott) wrote: >>>>>>>>> On 2022/12/9 15:12, Greg KH wrote: >>>>>>>>>> On Fri, Dec 09, 2022 at 03:00:35PM +0800, Guozihua (Scott) wrote: >>>>>>>>>>> Hi community. >>>>>>>>>>> >>>>>>>>>>> Previously our team reported a race condition in IMA relates to LSM based >>>>>>>>>>> rules which would case IMA to match files that should be filtered out under >>>>>>>>>>> normal condition. The issue was originally analyzed and fixed on mainstream. >>>>>>>>>>> The patch and the discussion could be found here: >>>>>>>>>>> https://lore.kernel.org/all/20220921125804.59490-1-guozihua@xxxxxxxxxx/ >>>>>>>>>>> >>>>>>>>>>> After that, we did a regression test on 4.19 LTS and the same issue arises. >>>>>>>>>>> Further analysis reveled that the issue is from a completely different >>>>>>>>>>> cause. >>>>>>>>>> >>>>>>>>>> What commit in the tree fixed this in newer kernels? Why can't we just >>>>>>>>>> backport that one to 4.19.y as well? >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> >>>>>>>>>> greg k-h >>>>>>>>> >>>>>>>>> Hi Greg, >>>>>>>>> >>>>>>>>> The fix for mainline is now on linux-next, commit d57378d3aa4d ("ima: >>>>>>>>> Simplify ima_lsm_copy_rule") and c7423dbdbc9ece ("ima: Handle -ESTALE >>>>>>>>> returned by ima_filter_rule_match()"). However, these patches cannot be >>>>>>>>> picked directly into 4.19.y due to code difference. >>>>>>>> >>>>>>>> Ok, so it's much more than just 4.19 that's an issue here. And are >>>>>>>> those commits tagged for stable inclusion? >>>>>>> >>>>>>> Not actually, not on the commit itself. >>>>>> >>>>>> That's not good. When they hit Linus's tree, please submit backports to >>>>>> the stable mailing list so that they can be picked up. >>>>> Thing is these commits cannot be simply backported to 4.19.y. Preceding >>>>> patches are missing. How do we do backporting in this situation? Do we >>>>> first backport the preceding patches? Or maybe we develop another >>>>> solution for 4.19.y? >>>> >>>> First they need to go to newer kernel trees, and then worry about 4.19. >>>> We never want anyone to upgrade to a newer kernel and have a regression. >>>> >>>> Also, we can't do anything until they hit Linus's tree, as per the >>>> stable kernel rules. >>> Alright. We'll wait for these patches to be in Linus' tree. But should >>> we stick to a backport from mainstream or we form a different solution >>> for LTS? > > We always want to have a normal backport of what is in Linus's tree if > at all possible. Whenever we diverge from that, we almost always get it > wrong and have to fix it up again later. > >> BTW, I have a look into it and if we are backporting mainstream's >> solution, we would also needs to backport b16942455193 ("ima: use the >> lsm policy update notifier") > > That's fine, please just send a patch series to the stable list when > needed. > > thanks, > > greg k-h Thanks Greg. Any thought from Mimi? -- Best GUO Zihua
