AppArmorForPhabletKernels

Differences between revisions 2 and 16 (spanning 14 versions)
Revision 2 as of 2013-08-27 18:45:10
Size: 7330
Editor: jjohansen
Comment:
Revision 16 as of 2015-07-08 02:44:42
Size: 3217
Editor: jdstrand
Comment: cleanup 'Updating the kernel cmdline on the device'
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
== About apparmor3 in the phablet kerenls ==
Apparmor3 in the phablet kernels is based on the upstream backport kernels of apparmor3.

However they 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 <tt>__d_path</tt> api changes from commit 02125a826459a6ad142f8d91c5b6357562f96615 so it doesn't need that portion of the backport patches.

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
1. Update main Ubuntu kernel if not already done
2. Update back port kernels
3. Update phablet kernels
4. Build
5. Test

== Get the apparmor kernel patches ==

The apparmor3 patches on saucy can be found at
  git clone git://kernel.ubuntu.com/jj/ubuntu-saucy.git

Note: the branches here are rebased as needed.

== Update Ubuntu kernel with latest patches ==

updating the main kernels
  get the apparmor3 dev tree
      git clone ...
  dump the patches past the base kernel version
      git format patch v3.11 -o patches
  get the current ubuntu kernel
  check that all the fix patches have made it into the dev version being applied if not you will need to reapply them
  revert all apparmor patches that ubuntu is carrying beyond the base kernel version.
     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.

== Update the phablet 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 keept 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

== Build the kernels ==

== Test the kernels ==
== About apparmor3 in the phablet kernels ==
<<Include(SecurityTeam/AppArmorForPreviousKernels, , from="== About apparmor3 in previous kernels ==")>>
Line 136: Line 10:
foo TODO

== Updating the kernel in the emulator ==
 0. 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
}}}
 0. copy the bzImage in to place. Eg:{{{
$ cp bzImage-goldfish ~/.local/share/ubuntu-emulator/<name of emulator instance name>/ubuntu-kernel
}}}
Line 140: Line 23:
build a kernel and get the zImage or a .deb Also see: https://wiki.ubuntu.com/Kernel/Dev/AndroidKernel
Line 142: Line 25:
 0. 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
}}}
 0. push the kernel to the phablet:{{{
$ adb push arch/arm/boot/zImage /data/ubuntu/
Line 143: Line 32:
push the kernel to the phablet
  adb push arch/arm/boot/zImage /data/ubuntu/
Line 146: Line 33:
  adb push /home/jj/linux-image-3.1.10-6-grouper_3.1.10-6.14_armhf.deb /data/ubuntu/
Line 148: Line 34:
connect to the tablet
  adb root
  adb shell
$ adb push /home/jj/linux-image-3.1.10-6-grouper_3.1.10-6.14_armhf.deb /data/ubuntu/
}}}
 0. connect to the tablet:{{{
$ adb root
$ adb shell
}}}
Line 152: Line 41:
if android is the root system and ubuntu is in a chroot
  ubuntu_chroot shell

if a deb install the kernel
  dpkg -i linux-image-3.1.10-6-grouper_3.1.10-6.14_armhf.deb

find where to flash the kernel (see below: find the boot partition)

flash the kernel (/dev/... is /dev/block/... on android)
  abootimg -u /dev/mmcblk0p2 -k /boot/vmlinuz-3.1.10-6-grouper

reboot
 0. if android is the root system and ubuntu is in a chroot:{{{
# ubuntu_chroot shell
}}}
 0. Find where to flash the kernel (see below: find the boot partition)
 0. 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`
 0. 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
}}}
 0. reboot
Line 167: Line 57:
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
 0. if you don't already have a bootimage.cfg, extract the bootimage:{{{
# dd if=/dev/mmcblk0p2 of=./boot.img
# abootimg -x ./boot.img
}}}
 0. edit bootimage.cfg by adding options to cmdline:{{{
Line 173: Line 63:

update the flashed boot image (same partition as kernel)
}}}
 0. update the flashed boot image (same partition as kernel):{{{
Line 176: Line 66:
}}}
Line 178: Line 69:
== 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)
  * 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
 * 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
Line 179: Line 84:
find the boot partition

list the block partitions
• nexus 7
     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)

• nexus 4
       ls -al /dev/block/platform/msm_sdcc.1/by-name/
       lrwxrwxrwx 1 root root 20 Apr 3 10:05 boot -> /dev/block/mmcblk0p6


get boot partition info to check if its really set up as a boot partition
  abootimg -i /dev/block/mmcblk0p2
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)

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

  1. Update main Ubuntu kernel if not already done
  2. Update back port kernels
  3. Update phablet kernels
  4. Build
  5. 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

  1. checkout the backport branch you want to base your kernel port on.

    git checkout <backport kernel>

  2. 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

  3. checkout the sha1 of the base apparmor3 patch

    git checkout <sha1 of base apparmor3 patch discovered in step 2>

  4. copy the apparmor directory to a temporary location

    cp -r security/apparmor /tmp/

  5. create a new branch of the backport kernel which will become your new backport branch

    git checkout -b <new-branch> <backport kernel>

  6. 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>

  7. 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/

  8. find which files are new

    git status

  9. add the new and updated files

    git add <file1> <file2> <...>

  10. continue the rebase

    git rebase --continue

  11. resolve conflicts in the remaining backport patches as needed (see ??? on resolving conflicts with rebase)
  12. Build your kernel
  13. 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 ...
    dump the patches past the base kernel version
    • git format patch v3.11 -o patches
    get the current ubuntu kernel check that all the fix patches have made it into the dev version being applied if not you will need to reapply them revert all apparmor patches that ubuntu is carrying beyond the base kernel version.
    • 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

  1. 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
  2. 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

  1. 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
  2. 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/
  3. connect to the tablet:

    $ adb root
    $ adb shell
  4. if android is the root system and ubuntu is in a chroot:

    # ubuntu_chroot shell
  5. Find where to flash the kernel (see below: find the boot partition)
  6. 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

  7. 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
  8. reboot

Updating the kernel cmdline on the device

  1. if you don't already have a bootimage.cfg, extract the bootimage:

    # dd if=/dev/mmcblk0p2 of=./boot.img
    # abootimg -x ./boot.img
  2. edit bootimage.cfg by adding options to cmdline:

      cmdline = console=tty1 apparmor=0
  3. 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)

    • 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

  • 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

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)