AppArmorForPhabletKernels
DRAFT - Updating/syncing the phablet kernels to the apparmor3
This page is under construction
About apparmor3 in the phablet kernels
Apparmor3 in the phablet kernels is based on the upstream backport kernels of apparmor3.
However these Ubuntu phablet kernels do have their differences as some of the phablet kernels have picked up patches that change the LSM api presented. Eg. the maguro kernel has a backport of the __d_path api changes from commit 02125a826459a6ad142f8d91c5b6357562f96615 so it doesn't need that portion of the backport patches. When backporting Apparmor3 to previous kernels, these additional patches may also be needed.
All of these kernels started out using the appropriate version of the kernel backport patches and then where modified as needed.
To keep the patch count in the ubuntu kernel small and minimize churn, we use a squash of the dev tree, so there will be one main patch and maybe a few fix patches on top of it.
The steps in gross
- Update main Ubuntu kernel if not already done
- Update back port kernels
- Update phablet kernels
- Build
- Test
Get the apparmor kernel patches
The apparmor3 alpha6 patches can be found at
- git clone git://kernel.ubuntu.com/jj/ubuntu-utopic.git
the older alpha4 kernel patches can be found at
- git clone git://kernel.ubuntu.com/jj/ubuntu-saucy.git
There are multiple branches of backports against both stock and ubuntu kernels.
Stock kernels
- v3.0-backport-of-apparmor3
- v3.1-backport-of-apparmor3
- v3.4-backport-of-apparmor3
Ubuntu Phablet Kernels
- flo-aa3-backport
- flo-aa3-backport-presquash
- goldfish-aa3-backport
- goldfish-aa3-backport-presquash
- mako-aa3-backport
- mako-aa3-backport-presquash
- manta-aa3-backport
- manta-aa3-backport-presquash
older kernels branches available in the git://kernel.ubuntu.com/jj/ubuntu-saucy.git tree
- grouper-apparmor3
- grouper-presquash-apparmor3
- maguro-apparmor3
- maguro-presquash-apparmor3
- mako-apparmor3
- mako-apparmor3-presquash
- manta-apparmor3
- manta-apparmor3-presquash
For the Ubuntu kernels there is a presquash and squash branch of the backport. The presquash branch has the set of patches needed for the backport broken out. The other branch has squashed that set of patches into a single commit and this is what is synched to Ubuntu. This is done to minimize the number of patches that are reverted as apparmor is updated.
Note: the branches here are rebased as needed.
Porting to new kernels
The process of porting to a new kernel is very similar to updating a stock kernel backport of apparmor 3. However instead of starting with the Upstream apparmor dev tree, an existing backport kernel can be used as a template.
The easiest way to do the backport is as follows
- checkout the backport branch you want to base your kernel port on.
git checkout <backport kernel>
find the sha1 of the base apparmor3 patch. It will have a description similar to UBUNTU: SAUCE: (no-up) apparmor: Sync to apparmor 3 .... The full commit message will depend on the version it was synced from eg. alpha4, or beta1, ... git log --oneline
- checkout the sha1 of the base apparmor3 patch
git checkout <sha1 of base apparmor3 patch discovered in step 2>
- copy the apparmor directory to a temporary location
cp -r security/apparmor /tmp/
- create a new branch of the backport kernel which will become your new backport branch
git checkout -b <new-branch> <backport kernel>
- rebase your branch onto the kernel you are porting onto
git rebase --onto <branch of kernel you are porting to> <sha1 of base apparmor3 patch used above>
- this will start the rebase but stop with conflict errors you need to resolve. Instead of directly resolving them, copy the apparmor directory into the branch (this avoids all the work of trying to resolve the conflicts)
cp -r /tmp/apparmor/* security/apparmor/
- find which files are new
git status
- add the new and updated files
git add <file1> <file2> <...>
- continue the rebase
git rebase --continue
- resolve conflicts in the remaining backport patches as needed (see ??? on resolving conflicts with rebase)
- Build your kernel
- Test your kernel
Because the apparmor backports are done in such a way as to not touch any kernel code outside of apparmor it is possible that the backport patches will apply but further work is needed based on other patches that are in the kernel. An example of this is the maguro kernel which has a backport of commit 02125a8264 which makes the backport patch
UBUNTU: SAUCE: apparmor: 3.1 backport d_path api intro'd in 02125a82
unnecessary so it has been dropped from the maguro backport.
Update Ubuntu kernel with latest patches
updating the main kernels
- get the apparmor3 dev tree
- git clone ...
- git format patch v3.11 -o patches
- git revert ... git am patches/*
squash the patches into a single update
- git rebase -i HEAD~XX
now copy off the apparmor directory to do the update for phablet kernels. This is easier as a base for the sync than applying a patch because each kernel has a different base and you have to resolve conflicts etc.
- cp -r security/apparmor ./
now update the configs and ammend the previous commit (this keeps us at 1 patch to change in the future)
- fdr updateconfigs (you may need to do fdr clean first)
git add <config files> git commit --amend
Update the backport kernels
The backport kernels are a set of kernels designed to port apparmor3 back to different versions of the kernel. Eg. v3.4-backport-of-apparmor3 is apparmor3 backported to the 3.4 kernel.
While v3.4-backport-of-v3.10-apparmor is a backport of the v3.10 kernel version of apparmor back to the 3.4 kernel.
The only patches to update are the apparmor3 version, we do this here so we have a clean reference base to work from for the phablet kernels, as some of them require some tweaking due to backported patches etc.
The backport kernel patches try to not change the apparmor3 code, and to not change the kernel api of the kernel being ported to. So instead of direct patch a lot of macro magic is used in the new backport files. The goal is to keep the changes required to a minimum to make backports easier, and keep abis the same for binary blobs.
Also the set of patches is broken out 1 per patch that is reverted or fixed with info about the change. Including the kernel its needed for, the commit that introduced the change etc.
The first thing to do is look and see if there are new patches upstream that need to be reverted/adjust for. Eg. When moving apparmor3 dev to 3.11, a new patch 3.10 backport revert no delay vfree() was needed. Note the change so it can be worked on.
rebase to update the sync patch
- git rebase -i HEAD~XXX choose e as the option to update the patch
copy in the apparmor3 kernel (that we copied out above)
- cp -r apparmor/* security/apparmor
git add <any new or update files> git commit -a --amend
Now do any partial reverts you need to do, or create macros in the backport files
- git show XXXX security/apparmor | patch -Rp1
Don't generally do a git revert unless the patch is entirely in the apparmor dir.
- commit these changes and finish the rebase
Do this once and cherry-pick the changes to other backport branches.
Build the kernels
Update the kernels
Currently there are 4 supported phablet kernels
- manta 3.4 based mako 3.4 based grouper 3.1 based maguro 3.0 based
To update the phablet kernels I kept 3 branches as I find that easiest. A base, base-presquash-apparmor3, base-apparmor3. Eg.
- manta manta-apparmor3 manta-presquash-apparmor3
updating the phablet kernels
- git fetch
git checkout <base> git reset --hard origin/<base> git log security/apparmor
Identify the apparmor3 commits from last time, so we can revert them.
git revert <commit(s)> cp -r apparmor/* security/apparmor
git add <new files> git commit -s -a git cherry-pick <any new backport patches not in <base>-presquash
git checkout <base>-presquash-apparmor3 git log
find old base patch sha1
git rebase --onto <base> <old base patch sha1>
fix any conflicts if needed now save it for next time
git push -f zinc <base>-presquash-apparmor3
git checkout <base>-apparmor3 git reset --hard <base>-presquash-apparmor3 fdr updateconfigs git add <updated config file> git commit -sa git rebase -i HEAD~XXX
use fixup (f) to fold backport patches into base apparmor3 patch
now save it for the pull-request
git push -f zinc <base>-presquash-apparmo3
repeat for others
Support Notes
Installing a phablet device with Ubuntu touch
TODO
Updating the kernel in the emulator
build a kernel and get the bzImage or get the image from a deb:
$ dpkg-deb -x /linux-....deb ./extracted $ cp ./extracted/boot/vmlinuz-* ./bzImage-goldfish
copy the bzImage in to place. Eg:
$ cp bzImage-goldfish ~/.local/share/ubuntu-emulator/<name of emulator instance name>/ubuntu-kernel
Updating the kernel on the device
Also see: https://wiki.ubuntu.com/Kernel/Dev/AndroidKernel
build a kernel and get the zImage or extract the zImage from a deb:
$ dpkg-deb -x /linux-....deb ./extracted $ cp ./extracted/boot/vmlinuz-* ./zImage
push the kernel to the phablet:
$ adb push arch/arm/boot/zImage /data/ubuntu/ or $ adb push /home/jj/linux-image-3.1.10-6-grouper_3.1.10-6.14_armhf.deb /data/ubuntu/
connect to the tablet:
$ adb root $ adb shell
if android is the root system and ubuntu is in a chroot:
# ubuntu_chroot shell
- Find where to flash the kernel (see below: find the boot partition)
If using deb, install the kernel (from within adb). Eg dpkg -i linux-image-3.1.10-6-grouper_3.1.10-6.14_armhf.deb
- Flash the kernel:
if kernel from deb:
# abootimg -u /dev/mmcblk0p2 -k /boot/vmlinuz-3.1.10-6-grouper
if zImage:
# abootimg -u /dev/mmcblk0p6 -k /data/ubuntu/zImage
- reboot
Updating the kernel cmdline on the device
if you don't already have a bootimage.cfg, extract the bootimage:
# dd if=/dev/mmcblk0p2 of=./boot.img # abootimg -x ./boot.img
edit bootimage.cfg by adding options to cmdline:
cmdline = console=tty1 apparmor=0
update the flashed boot image (same partition as kernel):
abootimg -u /dev/mmcblk0p2 -f bootimg.cfg
Find the boot partition
List the block partitions (devices might be in /dev/block/platform in older releases or /dev/disk/by-partlabel in newer. Note /dev/... may be /dev/block/... on android.
- Older releases:
- nexus 7 (look for what 'LNX' points at)
- ls -la /dev/block/platform/sdhci-tegra.3/by-name/
lrwxrwxrwx 1 root root 20 Apr 3 09:21 LNX -> /dev/block/mmcblk0p2 LNX is the boot partition (where vmlinux resides) SOS is another boot partition (the recovery one but we won't use it)
- ls -la /dev/block/platform/sdhci-tegra.3/by-name/
- nexus 4 (look for what 'boot' points at)
- ls -al /dev/block/platform/msm_sdcc.1/by-name/
lrwxrwxrwx 1 root root 20 Apr 3 10:05 boot -> /dev/block/mmcblk0p6
- ls -al /dev/block/platform/msm_sdcc.1/by-name/
- nexus 7 (look for what 'LNX' points at)
- Newer releases:
- nexus 4 (look for what 'boot' points at)
- ls -al /dev/disk/by-partlabel/
lrwxrwxrwx 1 root root 15 May 14 13:02 boot -> ../../mmcblk0p6
- ls -al /dev/disk/by-partlabel/
- nexus 4 (look for what 'boot' points at)
Get boot partition info to check if its really set up as a boot partition
- abootimg -i /dev/block/mmcblk0p2 (older releases)
- abootimg -i abootimg -i /dev/mmcblk0p6 (newer releases)
SecurityTeam/AppArmorForPhabletKernels (last edited 2015-07-08 02:44:42 by jdstrand)