On 07/12/2017 05:17 AM, Goldwyn Rodrigues wrote: > > > On 07/07/2017 11:03 AM, John Johansen wrote: >> yes sorry, I been chasing some bugs and 4.14 dev work while waiting >> for the 4.13 security tree merge. Now that that has happened I will >> work on finishing up the 4.13 backports >> > > I may be able to help a bit with the ports. How are you going about the > ports? There seem to be some patches in ubuntu-zesty git. > those would be old. The ports are done as a snapshot based on a specific version (for upstream based kernels it could be done as a cherry-pick of all apparmor patches between the kernel version being backported and the target kernel, instead of a squash but that doesn't work for ubuntu kernels for the dev branches because Ubuntu is uses rebase kernels and the ubuntu dev patches haven't been carried in a way to make the cherry-pick feasible), with a set of patches doing remapping and reverts as needed to make the specific version of apparmor work on the backport kernel.
you might want to look at the v4.10-aa3.6-backport-to-v4.1 branch as an example. It ports the the Ubuntu v4.10 kernel based version of apparmor back to a v4.1 kernel. 6722fdfc74f0 apparmor: 4.1 backport revert LSM: Split security.h 3c4ed7bd 44d7680489dc apparmor: 4.1 backport LSM: Add security module hook list heads e20b043a 74f801879918 apparmor: 4.1 backport LSM: Switch to lists of hooks b1d9e6b0 8e3b91cba4e2 UBUNTU: SAUCE: apparmor: 4.4 backport to supprt wrappers for ->i_mutex access 5955102c 3dd38cf3ed3b apparmor: 4.5 backport partial revert of tty: Make tty_files_lock 4a510969 8aa24c824808 apparmor 4.6 backport support constification of struct path in LSM hooks ba270079b854 apparmor: 4.8 backport support current_time() api dec1c92bd92d apparmor: backport setup base backport files 2cbb2f8d48ff securityfs: update interface to allow inode_ops, and setup from vfs fns 734f9b3ba45a apparmor: sync of apparmor 3.6+ (16.10) It starts with the snapshot (which could be a squash or cherry pick of a couple hundred patches in the case of 4.13) and then cherry-picks any other kernel changes that apparmor may depend on (securityfs: ...), the sets up some base backport files, and has a commit per necessary revert change working back to the target kernel (4.1 in this case). This allows us to create the 4.0 backport by just adding patches to the 4.1 backport, and to track what changes were needed for the backport. The backports try very hard to isolate changes needed to the apparmor code instead of picking/reverting patches to the kernel tree. We haven't been able to avoid it in all cases (eg. securityfs) but we have managed to mostly isolate the changes to the apparmor source code. > In the LSS 2016 talks, you mention of an RFC. Do you have it documented? > I would need to see/perform the use cases before I can even start with > the ports. > The RFCs are going to come as part of the 4.14 work, they aren't ready yet > Would you have a tree which can be cloned for the patches still need to > be ported or have a development tree? I did check out the linux-apparmor > tree [1], but it does not seem to have more than what is present in the > apparmor-utils. > > [1] git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor > right, I have been doing the Ubuntu based backports in the git://kernel.ubuntu.com/jj/linux-apparmor-backports The kernel.org tree is only used for upstream based work. I will be pusing branches to there but since the 4.13 versions will be based on upstream, I will also likely be pushing them to the kernel.org tree. I'll push what I have of the 4.13 backports when I get back tomorrow -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor