the patch aufs3-standalone-base-combined.patch fails to patch hardened-sources 3.11.7. It fails on the following files: include/linux/mm.h kernel/fork.c mm/mmap.c I manually adjusted the patch for hardened-sources 3.11.7 and have it up on my git-hub overlay: https://github.com/andyrj/portage-overlay/blob/master/sys-kernel/hardened-sources/files/aufs3-standalone-base-mmap-combined-3.11.7.patch I hope that is helpful in updating the sys-fs/aufs3 patch for hardened-sources kernels.
Could you please provide a patch with goes on top of the upstream aufs3 patch?
Created attachment 367804 [details, diff] Original path from the package that fails for hardened
making new patch that can go on after the current patch created by aufs3. I'm not sure how that will work exactly since the patch fails and kills the build. Will attach to this bug shortly.
Created attachment 367808 [details, diff] patch set for changes necessary for aufs3 patch to work on hardened sources
sys-fs/aufs3-3_p20140119 also fails to apply to hardened-sources-3.11.7-r1. The patch at github above worked for me.
@hardened I need to drop support if I don't get input from you. I don't use it so I cannot test it. And upstream isn't willed to include support because I cannot really explain what the patches do.
Created attachment 373978 [details, diff] sys-fs/aufs3-3_p20140310 ebuild patch tested with sys-kernel/hardened-sources-3.13.2-r3
Created attachment 373980 [details, diff] hardened-kernel.patch
well actually the module builds correctly, but fails to load: haze ~ # modprobe -v aufs insmod /lib/modules/3.13.2-hardened-r3/misc/aufs.ko modprobe: ERROR: could not insert 'aufs': Exec format error yes, i did rebuild the kernel after emerging sys-fs/aufs3-3_p20140310
This seems to still be an issue on newer hardened. Neither attached patches or those from the linked git seems to work on latest stable, hardened-sources-3.14.5-r2.. Tried to apply the patches manually but then it didnt compile, im not really a kernel programmer tho :P
Also failing for me, on hardened-sources-3.14.5-r2 and hardened-sources-3.15.5-r1. What to do?
(In reply to Marckus Knight from comment #11) > What to do? Kindly ask the hardened team to provide a new patch.
Ok I suppose that can be done. Isn't it easier to invite/add them to this bug? I don't know how they prefer to be reached.
Created attachment 381388 [details, diff] aufs3-hardened-3.15.patch I fixed up the patch. This patch should be applied to aufs3-standalone-base-mmap-combined.patch, after that aufs3-standalone-base-mmap-combined.patch will apply cleanly to linux-3.15.5-hardened-r1. I do not know how to use aufs3, I just fixed up the patch. Can someone test? # cp /var/tmp/portage/sys-fs/aufs3-3_p20140721/temp/aufs3-standalone/aufs3-standalone-base-mmap-combined.patch /tmp/ # patch < ~/aufs3-hardened-3.15.patch patching file aufs3-standalone-base-mmap-combined.patch # patch -p1 --dry-run --force -d /usr/src/linux < /tmp/aufs3-standalone-base-mmap-combined.patch patching file drivers/block/loop.c patching file fs/inode.c Hunk #2 succeeded at 1501 (offset 4 lines). Hunk #3 succeeded at 1517 (offset 4 lines). patching file fs/splice.c patching file include/linux/fs.h Hunk #1 succeeded at 2607 (offset 1 line). patching file include/linux/splice.h patching file fs/namespace.c Hunk #2 succeeded at 1571 (offset 6 lines). patching file fs/notify/group.c patching file fs/notify/mark.c patching file fs/open.c Hunk #1 succeeded at 64 (offset 2 lines). Hunk #2 succeeded at 306 (offset 6 lines). patching file security/commoncap.c Hunk #1 succeeded at 1017 (offset 29 lines). patching file security/device_cgroup.c patching file security/security.c Hunk #1 succeeded at 402 (offset -5 lines). Hunk #2 succeeded at 419 (offset -5 lines). Hunk #3 succeeded at 428 (offset -5 lines). Hunk #4 succeeded at 456 (offset -5 lines). Hunk #5 succeeded at 464 (offset -5 lines). Hunk #6 succeeded at 472 (offset -5 lines). Hunk #7 succeeded at 558 (offset -5 lines). Hunk #8 succeeded at 573 (offset -5 lines). Hunk #9 succeeded at 696 (offset -5 lines). Hunk #10 succeeded at 757 (offset -5 lines). patching file fs/buffer.c patching file fs/proc/nommu.c patching file fs/proc/task_mmu.c Hunk #1 succeeded at 289 (offset 24 lines). Hunk #2 succeeded at 1473 with fuzz 2 (offset 62 lines). patching file fs/proc/task_nommu.c patching file include/linux/mm.h Hunk #2 succeeded at 1182 (offset 6 lines). patching file include/linux/mm_types.h patching file kernel/fork.c Hunk #1 succeeded at 433 (offset 17 lines). patching file mm/filemap.c patching file mm/fremap.c Hunk #1 succeeded at 228 (offset 5 lines). patching file mm/madvise.c Hunk #1 succeeded at 358 (offset 31 lines). patching file mm/memory.c Hunk #1 succeeded at 3001 (offset 196 lines). patching file mm/mmap.c Hunk #1 succeeded at 272 (offset 22 lines). Hunk #2 succeeded at 884 (offset 23 lines). Hunk #3 succeeded at 1803 (offset 162 lines). Hunk #4 succeeded at 2832 (offset 400 lines). Hunk #5 succeeded at 2883 (offset 432 lines). Hunk #6 succeeded at 3346 (offset 506 lines). patching file mm/msync.c patching file mm/nommu.c Hunk #1 succeeded at 654 (offset -1 lines). Hunk #2 succeeded at 819 (offset -1 lines). Hunk #3 succeeded at 1372 (offset -10 lines). Hunk #4 succeeded at 1448 (offset -10 lines).
(In reply to Jason Zaman from comment #14) > I fixed up the patch. > > This patch should be applied to aufs3-standalone-base-mmap-combined.patch, > after that aufs3-standalone-base-mmap-combined.patch will apply cleanly to > linux-3.15.5-hardened-r1. > > I do not know how to use aufs3, I just fixed up the patch. Can someone test? > > > # cp > /var/tmp/portage/sys-fs/aufs3-3_p20140721/temp/aufs3-standalone/aufs3- > standalone-base-mmap-combined.patch /tmp/ > > # patch < ~/aufs3-hardened-3.15.patch > patching file aufs3-standalone-base-mmap-combined.patch > Thank you for trying to fix this. Unfortunately your patch fails on my system: # cp /var/tmp/portage/sys-fs/aufs3-3_p20140721/temp/aufs3-standalone/aufs3-standalone-base-mmap-combined.patch /tmp/ # bugz attachment 381388 [details, diff] # patch < aufs3-hardened-3.15.patch patching file aufs3-standalone-base-mmap-combined.patch Hunk #2 FAILED at 546. Hunk #3 FAILED at 681. 2 out of 3 hunks FAILED -- saving rejects to file aufs3-standalone-base-mmap-combined.patch.rej Reject file content: --- aufs3-standalone-base-mmap-combined.orig.patch 2014-07-22 23:19:45.058853643 +0400 +++ aufs3-standalone-base-mmap-combined.patch 2014-07-22 23:56:17.952854144 +0400 @@ -546,14 +546,14 @@ --- a/kernel/fork.c +++ b/kernel/fork.c @@ -416,7 +416,7 @@ static int dup_mmap(struct mm_struct *mm, struct mm_struct *oldmm) - struct inode *inode = file_inode(file); - struct address_space *mapping = file->f_mapping; + struct inode *inode = file_inode(file); + struct address_space *mapping = file->f_mapping; -- get_file(file); -+ vma_get_file(tmp); - if (tmp->vm_flags & VM_DENYWRITE) - atomic_dec(&inode->i_writecount); - mutex_lock(&mapping->i_mmap_mutex); +- get_file(file); ++ vma_get_file(tmp); + if (tmp->vm_flags & VM_DENYWRITE) + atomic_dec(&inode->i_writecount); + mutex_lock(&mapping->i_mmap_mutex); only in patch2: unchanged: --- a/mm/filemap.c @@ -681,9 +681,9 @@ if (new->vm_file) - fput(new->vm_file); + vma_fput(new); - unlink_anon_vmas(new); out_free_mpol: mpol_put(vma_policy(new)); + out_free_vma: @@ -2840,7 +2840,7 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap, if (anon_vma_clone(new_vma, vma)) goto out_free_mempol;
it fails because some indentation mismatch... below patch does apply fine, but then pax-3.11.patch because missing f_op_sp.c file, removing the offending hunks makes the patch apply and the module build correctly, but after recompiling the kernel and modprobing the aufs module i get the same result of comment 9: modprobe: ERROR: could not insert 'aufs': Exec format error from dmesg: [ 141.208390] attempted module disagrees about version of symbol module_layout
Created attachment 381556 [details, diff] hardened-kernel.patch
I'm really not sure what to do here. I'm not familiar with aufs3 and don't want to start mucking with a patch I don't understand.
Zero_Chaos (?) seems to got this working with the sys-kernel/pentoo-sources-3.15.5 in the pentoo overlay. Can someone more than me please confirm this? If this indeed is working, maybe try its 4310_aufs3.patch on a newer hardened-sources?
I can confirm that it's working. I've been running pentoo kernels with aufs3 patches for a few months and I haven't noticed any obvious bugs and instabilities.
(In reply to Anthony Basile from comment #18) > I'm really not sure what to do here. I'm not familiar with aufs3 and don't > want to start mucking with a patch I don't understand. I don't understand the patch or hardened stuff, so I cannot help it to go upstream or fix it. I we want to have aufs3 for hardened sources I need help.
Created attachment 388648 [details, diff] Patch for aufs3 and hardened-sources-3.14.17-r1 This is patch should be for hardened-sources-3.14.17-r1, but cannot test it. I cannot find a way to make either "emerge aufs3" or get ebuild to ignore the "kernel patch" test in the src_prepare() ebuild phase. Also disabling "kernel-patch" use flag does not switch off the verify mechanism and the call to git overwrites my patch. Can some one help? @Lecher: upstream aufs3 patches are against vanilla, on hardened-sources the grsecurity patch changes some patch hunks contexts. It would be possible to use "pax_kernel" use flag to combinediff the patch?
Created attachment 388850 [details, diff] aufs3-3_p20141103.aufs3 ebuild patch to include hardened-kernel.patch and pax-3.14.patch
Created attachment 388852 [details, diff] Patch for aufs3-mmap.patch and hardened-sources
Created attachment 388854 [details, diff] aufs3 ebuild patch to include hardened-kernel.patch and pax-3.14.patch
Created attachment 388856 [details, diff] aufs3-mmap.patch patch and hardened-sources-3.14
Created attachment 388858 [details, diff] aufs3 PAX patch for upstream branch aufs3.14
At last I have a modprobing (still to test) AUFS3 module for hardened-sources-3.14.17-r1. Thanks to frank I created my portage overlay, patching AUFS3 ebuild to use the hardened-kernel.patch (to aufs3-mmap.patch) and pax-3.14.patch (fs/aufs/f_op_sp.c is missing from upstream since aufs3.8 branch). Now the problem is to find how to avoid patch patching...
(In reply to Andrea Zuccherelli from comment #28) > At last I have a modprobing (still to test) AUFS3 module for > hardened-sources-3.14.17-r1. > > Thanks to frank I created my portage overlay, patching AUFS3 ebuild to use > the hardened-kernel.patch (to aufs3-mmap.patch) and pax-3.14.patch > (fs/aufs/f_op_sp.c is missing from upstream since aufs3.8 branch). > > Now the problem is to find how to avoid patch patching... I cannot support this patch. I can leave this bug open if people want to work on it independantly but I don't have the times or means to support and test.
*** Bug 560738 has been marked as a duplicate of this bug. ***
(In reply to Anthony Basile from comment #29) > (In reply to Andrea Zuccherelli from comment #28) > > At last I have a modprobing (still to test) AUFS3 module for > > hardened-sources-3.14.17-r1. > > > > Thanks to frank I created my portage overlay, patching AUFS3 ebuild to use > > the hardened-kernel.patch (to aufs3-mmap.patch) and pax-3.14.patch > > (fs/aufs/f_op_sp.c is missing from upstream since aufs3.8 branch). > > > > Now the problem is to find how to avoid patch patching... > > I cannot support this patch. I can leave this bug open if people want to > work on it independantly but I don't have the times or means to support and > test. Note that the ebuild still contains USE=pax_kernel and https://wiki.gentoo.org/wiki/Aufs states that aufs can _only_ be used with hardened-sources and gives instructions for doing so. Should these be changed?
I propose this bug is closed, as 3.x hardened kernels were removed from portage some time ago, and last bug update was 2015. Incidentally, I have successfully applied manjaro patches to my gentoo-sources v3.12.52 stable without issue. Is there a reason why hardened kernels are required/used in Gentoo for aufs?
Package gone wrt #650126.
