On 10/05/2016 07:36 AM, Tyler Hicks wrote: > On 10/05/2016 02:46 AM, John Johansen wrote: >> On 10/04/2016 07:32 PM, Tyler Hicks wrote: >>> On 10/04/2016 06:31 PM, John Johansen wrote: >>>> exec_stack picked up a fix to address a semantic change introduced in >>>> 4.8 kernels. However this breaks the exec_stack test for kernel pre >>>> 4.8. This patch uses an apparmor kernel flag to detect whether the >>>> semantic change is present and adjusts the test accordingly. >>> >>> A couple questions below... >>> >>>> >>>> --- >>>> >>>> === modified file 'tests/regression/apparmor/exec_stack.sh' >>>> --- tests/regression/apparmor/exec_stack.sh 2016-09-29 04:11:29 >>>> +0000 >>>> +++ tests/regression/apparmor/exec_stack.sh 2016-10-04 21:15:48 >>>> +0000 >>>> @@ -43,6 +43,12 @@ >>>> >>>> touch $file $otherfile $sharedfile $thirdfile >>>> >>>> +if [ "$(kernel_features domain/fix_binfmt_elf_mmap)" == "true" ]; then >>> >>> Why is the kernel doing domain/fix_binfmt_elf_mmap instead of bumping >>> the kABI? Maybe I'm misunderstanding the purpose of the kABI but I >>> understood it to be bumped when there were was a change in mediation >>> that causes policy change. >>> >> >> For a few reasons. >> 1. I brought up bumping the potential of bumping the abi and got no >> feedback. > > Sorry about that. I'm still trying to fully understand how kABI is > intended to be used (I think I'm getting there now) so I don't know that > I could have provided much feedback. > >> 2. The abi bump here is odd in that it is kernel caused not apparmor. >> That doesn't mean we don't bump the abi but it is less clear. Hence 1 >> 3. I am worried that the patch that introduced the semantic change >> will show up in stable kernels as it is an information leak fix >> for tracing. For none ubuntu kernels this will mean a different >> abi on the apparmor side, so bumping the abi alone is problematic. >> Ubuntu is at v7, while upstream is at v6. We can bump the abi to v8 >> but what do we do for upstream or other distro kernels? We can't >> bump them to v7, nor v8 as they are missing other semantic changes. > > Interesting and frustrating problem. > >> >> This is a case where a sub version would be nice. >> >> so with that issue in place so it can be properly detected and conditioned >> in the regression tests. Since we can't currently tie it to a single >> abi number. >> >> With that said I am still open to bumping to v8 for stacking based >> kernels. But we need the flag to deal with v6 abi based kernels if >> this ever happens. >> >> I am no also open to the idea of using one or two bits of the abi >> for a sub version. So we can handle something like this better in the >> future. > > One or two bits doesn't seem like enough. If that's all that we have to > spare, I think I would have chosen 'domain/fix_binfmt_elf_mmap', too. > possibly. This has only happened a few times in the past so ideally it would be enough between major abi bumps.
With that said, When wrote this I was thinking it would need to fit into the current 11 bits used by policy loads to indicate the kabi that policy is targeting. I reality we could split this out into a separate number in which case we could have as many bits as we wanted. -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
