Re: request commit for 6.1 too // scsi: megaraid_sas: Add flexible array member for SGLs
On June 9, 2023 3:42:12 PM PDT, Frank Reppin wrote: >Dear all, > >I've already followed the reply instructions on LKML - but it somewhat >messed up my message there (so probably nobody knows what I'm talking about) - >however ... > >Earlier this year you've committed > >scsi: megaraid_sas: Add flexible array member for SGLs >https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=a9a3629592ab > >... but it only made it into 6.3 at this time. > >I hereby kindly request to see this commit in LTS 6.1 too. Sure! These requests are handled through the stable mailing list (now added to To:). Greg, please backport a9a3629592ab to 6.1 (and 6.2). Thanks! -Kees > >Why? >Debian Bookworm is soon to be released (RC4 at this moment) and is not yet >aware of this issue... > >We're currently testing some new DELL servers and want to roll 'em out >once Bookworm is released. >Previous tests using Debian Bullseye (Kernel 5.10 based) where fine... >but all of a sudden - with Debian Bookworm (Kernel 6.1 based) this weird >call trace shows up in our logs - and this is hard to explain to QA ppl. > >Apart from this call trace showing up - I don't see any weird things. >The /dev/disk/by-uuid/ thingie I wrote about in > >https://lkml.org/lkml/2023/6/9/1384 > >is nonsense ofcourse - because upon further thinking about what I wrote >it came apparent that the command I'm using does change/nullify the UUID >I am talking about. > >Thankyou! >Frank Reppin > > -- Kees Cook
Re: Debian 8/jessie - SECCOMP_FILTER_FLAG_TSYNC [PATH]
Thanks for doing this backport! It looks like it's missing one bug fix patch, though: https://git.kernel.org/linus/69f6a34bdeea4fec50bb90619bc9602973119572 This is needed or some architectures in UP mode will hang when creating the init process. Also, this add the syscall for ARM: https://git.kernel.org/linus/839669714f0a85d677283690e6e164fb698ce206 And MIPS: https://git.kernel.org/linus/8855d608c145c1ca0e26f4da00741080bb49d80d And a fix for ARM ptrace when changing the syscall during seccomp: https://git.kernel.org/linus/42309ab450b608ddcfafa90e4cfa93a5001ecfba Thanks! -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150309182548.gb5...@outflux.net
Bug#712740: the default is fine
This is what /etc/sysctl.d/ is for: changing defaults. There are, in fact, real protections with this change. Namely, the delay of attack expansion. Take the case of a server being attacked. If there are ssh connections left open from that machine, without the ptrace restrictions, an attacker can trivially jump down the existing connections, expanding the scope of the attack. With the restrictions, they must construct a trap for the user to fall into (.bashrc, etc) and wait for re-establishment of connections before credential theft can occur. The same is true for various desktop scenarios. Full user access is game-over from a technical perspective, but there are real-world situations where this restriction is an improvement. Debugging applications, by default, will not be able to attach to existing running processes, that is certainly a down-side to the restriction. However, running processes under a debugger is still possible, and doing live debugging as root is still possible. The root user using strace -p is a very common sysadmin workflow, and it's affected by this restriction. Ubuntu carries patches to gdb, strace, and ltrace that contain more helpful error messages, so maybe Debian could carry those as well. Unfortunately, many upstreams have repeatedly refused to use the dumpable flag like ssh-agent does (e.g. gpg), so it won't work as a general solution. Blocking sibling ptracing also improves container security. This is a good default, and if specific system owners don't want it enabled, they can choose to turn it off in /etc/sysctl.d/, just like other things. -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130619174439.ga17...@outflux.net
Bug#679436: add drop_capabilities=... support, like kinit
Package: initramfs-tools
Version: 0.106
Severity: normal
Tags: patch
This adds knowledge of the drop_capabilities=... option that kinit
supports. When set, it gets passed to run-init's new -d option.
This lets a system owner drop capabilities (like CAP_SYS_MODULE and
CAP_SYS_RAWIO) before the system init starts.
Thanks,
-Kees
--
Kees Cook@debian.org
diff -Nru initramfs-tools-0.106/debian/changelog
initramfs-tools-0.107~0kees1/debian/changelog
--- initramfs-tools-0.106/debian/changelog 2012-06-07 05:40:53.0
-0700
+++ initramfs-tools-0.107~0kees1/debian/changelog 2012-06-28
09:59:06.0 -0700
@@ -1,3 +1,11 @@
+initramfs-tools (0.107~0kees1) unstable; urgency=low
+
+ * init: provide logic to mirror the new kinit kernel command line option
+drop_capabilities= This allows dropping of capabilities before
+system's init runs, via new -d option to run-init.
+
+ -- Kees Cook k...@debian.org Thu, 28 Jun 2012 09:52:04 -0700
+
initramfs-tools (0.106) unstable; urgency=high
[ Josh Triplett ]
diff -Nru initramfs-tools-0.106/init initramfs-tools-0.107~0kees1/init
--- initramfs-tools-0.106/init 2012-06-06 06:04:52.0 -0700
+++ initramfs-tools-0.107~0kees1/init 2012-06-28 09:56:59.0 -0700
@@ -54,6 +54,7 @@
export blacklist=
export resume=
export resume_offset=
+export drop_caps=
# Bring in the main config
. /conf/initramfs.conf
@@ -140,6 +141,9 @@
noresume)
noresume=y
;;
+ drop_capabilities=*)
+ drop_caps=-d ${x#drop_capabilities=}
+ ;;
panic=*)
panic=${x#panic=}
case ${panic} in
@@ -289,7 +293,7 @@
maybe_break init
# don't leak too much of env - some init(8) don't clear it
-# (keep init, rootmnt)
+# (keep init, rootmnt, drop_caps)
unset debug
unset MODPROBE_OPTIONS
unset DPKG_ARCH
@@ -315,10 +319,10 @@
mount -n -o move /proc ${rootmnt}/proc
# Chain to real filesystem
-if command -v switch_root /dev/null 21; then
+if [ -z $drop_caps ] command -v switch_root /dev/null 21; then
exec switch_root ${rootmnt} ${init} $@ ${rootmnt}/dev/console
${rootmnt}/dev/console
elif command -v run-init /dev/null 21; then
- exec run-init ${rootmnt} ${init} $@ ${rootmnt}/dev/console
${rootmnt}/dev/console
+ exec run-init ${drop_caps} ${rootmnt} ${init} $@
${rootmnt}/dev/console ${rootmnt}/dev/console
fi
echo Something went badly wrong in the initramfs.
panic Please file a bug on initramfs-tools.
Bug#676515: linux-2.6: AppArmor totally broken
Hi John, On Tue, Jun 26, 2012 at 10:48:38AM -0700, John Johansen wrote: On 06/23/2012 11:53 AM, intrigeri wrote: John Johansen wrote (17 Jun 2012 19:08:20 GMT) : On 06/15/2012 05:08 PM, Ben Hutchings wrote: If we don't want to restrict sockets used by the kernel, don't we need to store the kern flag for later use by aa_revalidate_sk()? For how apparmor is generally deployed it can get away with this, the kernel bits generally bail out earlier on the check for unconfined. That is not to say it isn't a good idea, or that it shouldn't be done. The fact is this patch is going to be replaced with completely rewritten controls, that do store info on the socket, it just hasn't happened yet due to resources and priorities (not my priorities). Ben, is this a blocker? I want to be convinced that this is not a bug, or else get a fix for it. I am looking at the kernel bits here, but I don't have a patch yet Do you think you'll manage to do it in time for the Wheezy freeze (June 30th)? Since denied has already been masked with ~quiet_mask, this condition can never be true. indeed Ben, is this a blocker? [...] This clearly is a bug and I want to be convinced that it is harmless or else get a fix for it. Right this breaks the controls over quieting of denial messages. Basically if policy specifies a reject should not be logged then the global controls that turn quieting off so that all rejects get logged aren't working for networking. This is an easy patch that I can provide separately or with the patch I am working on for the larger issue. Do you think you'll manage to prepare at least the easy fix it in time for the Wheezy freeze? Okay, there are 4 kernel patches, not all of them are needed depending on whether the network patch is applied or not. If you don't want to apply the networking patch 0001-apparmor-remove-advertising-the-support-of-network-r.patch Stops the kernel interface from incorrectly advertising that it supports network rules. A further patch (not attached) to userspace will also have to be applied If the networking patch is applied these two patches can be applied or ignored, 0001 will be folded into the compat interface patch upstream, and then 0002 will be folded into the networking patch 0001-apparmor-remove-advertising-the-support-of-network-r.patch 0002-apparmor-Advertise-network-mediation-from-the-compat.patch these two patches address the two bugs pointed out in the networking patch 0003-apparmor-Fix-quieting-of-audit-messages-for-network-.patch 0004-apparmor-Ensure-apparmor-does-not-mediate-kernel-bas.patch My preference would be to apply the networking patch, along with 0003 and 0004 posted here. -Kees -- Kees Cook -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120626182726.gq5...@outflux.net
Re: Linux kernel hardening - link restrictions
On Fri, Mar 02, 2012 at 05:11:58AM +, Ben Hutchings wrote: The longstanding link restriction patches were recently accepted by Andrew Morton and are likely to end up in Linux 3.4. I've applied these to src:linux-2.6 in svn and they should end up in the upcoming version 3.2.9-1. That's excellent news! (I am biased, obviously.) We know that these are going to break some programs, most notably 'at' (#597130, fixed in wheezy/sid). But of course it's possible to work around that by disabling the restriction, so I don't think this should result in a 'Breaks' relation. FWIW, as some background, at is the only package that I'm aware of breaking across 1.5 years of (a version of) this patch living in Ubuntu, and in many more years living in Openwall Linux and grsecurity. So I feel like going to break some is strong. :) I'm therefore intending to warn about this with the following NEWS entry in the linux-image metapackages: Index: debian/linux-image.NEWS === --- debian/linux-image.NEWS (revision 18757) +++ debian/linux-image.NEWS (working copy) @@ -1,3 +1,18 @@ +linux-latest (44) unstable; urgency=low + + * The new kernel version includes security restrictions on links, which +are enabled by default. These are specified in +Documentation/sysctl/fs.txt in the linux-doc-3.2 and linux-source-3.2 +packages. + +These restrictions may cause some legitimate programs to fail. +In particular, if the 'at' package is installed, you should either: +- Upgrade it to at least version 3.1.13-1 (or a backport of that) +or: +- Set sysctl fs.protected_hardlinks=0 (see /etc/sysctl.conf) + + -- Ben Hutchings b...@decadent.org.uk Fri, 02 Mar 2012 04:58:24 + + This seems like a sensible NEWS item to me. The use of may break seems better than going to break some. linux-latest-2.6 (26) unstable; urgency=low * The old IDE (PATA) drivers are no longer developed. Most PATA --- END --- (Why in the metapackages, you ask? Because apt-listchanges shows NEWS from upgraded packages, not new packages.) Does anyone have a better idea how to do this? Know about other packages that are affected? It's a trivial patch[1] to fix at. How about just backporting that change to stable, to avoid that known trouble too? This is what Ubuntu did for the Lucid LTS release that was getting backported kernels (with link restrictions) built for it. -Kees [1] http://anonscm.debian.org/gitweb/?p=collab-maint/at.git;a=commitdiff;h=f4114656c3a6c6f6070e315ffdf940a49eda3279 -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120302054021.gu3...@outflux.net
Bug#605090: Updated patch
On Wed, Feb 09, 2011 at 06:51:02PM +0100, maximilian attems wrote: Be more precise in what SELinux can't do for you? SELinux is only MAC. It attempts to protect userspace from userspace. From my view, the bulk of the benefits in grsec and PaX are protecting the kernel from userspace. Take for example the case of syscalls. There is nothing in a MAC that can filter syscalls, so if there is a new vulnerability in a syscall, you might get attacked, and no MAC can stop it. PaX adds a lot of internal hardening to mitigate most kernel exploitation attempts (for example, actually enforcing the kernel/userspace memory segmentation so that kernel code can't be tricked into running code from a userspace mapping, setting function pointers and call tables read-only so that an arbitrary write isn't instantly turned into a root-escalation, hiding the location of kernel addresses to frustrate attacks that need to find in-kernel offsets, actually checking the size of copy_to/from_user work to avoid overflows, the list goes on and on). (Emulating NX for bad hardware doesn't count these days). Why not? A giant amount of hardware lacks NX, and is still in active use, especially for Debian (people are turning more to Debian as other distros move their minimum instruction set requirements higher and higher). -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110209231848.gb1...@outflux.net
Bug#605090: Updated patch
Hi, On Wed, Jan 26, 2011 at 01:29:14PM +0100, Yves-Alexis Perez wrote: Due to the performances concerns, I've decided to keep UDEREF and KERNEXEC disabled on amd64 for now anyway, so those will disappear (independently of the i386 decision). This doesn't seem like a good idea. The bulk of heavy-duty kernel hardening is with KERNEXEC and UDEREF. If someone is interested in speed, they can choose i386. But if someone wants a hardened kernel and amd64, they should have the option. I'd leave those on for both. -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110126180715.gb4...@outflux.net
Re: Minutes of the Debian linux-2.6 Group Meeting
On Thu, Nov 11, 2010 at 13:52:12 +, maximilian attems wrote: LSM: Enable AppArmor? as well as/instead of Tomoyo? --- As the LSM need to be built we can't enable them. This needs a technical solution were code can be disregarded as init sections or similar. AppArmor seems more popular as Opensuse and Ubuntu uses it. Technicaly Tomoyo is said to be cleaner. What do you mean by can't here? You can build _all_ of them, actually. The active LSM is just selected at boot-time through the kernel command line arguments. If it's a concern over kernel size, upstream specifically removed the ability to make the LSM modular, so this means that no additional LSMs will ever be available in Debian? NX bit emulation and 32-bit mmap randomization -- We don't want to carry intrusive patches. The NX patch was rejected as such by upstream and thus we won't take it either. Why? These patches are well maintained, and touch areas of the kernel that do not change much (making them very easy to merge). Why leave non-PAE x86 users out in the code when so many other distros use some form of this patchset? I've worked to make sure they only touch CONFIG_X86_32, so they're extremely minimal. Currently we recommend PAE for bigger boxes but do not default to it. Action item by bwh and waldi to default Debian Installer to it and deprecate non PAE 686. This sounds great, regardless. Upstream status of the other patch is unknown, maks will consult Kees. In my mind, they[1] are a single patch -- the 32-bit mmap randomization is better named ASCII Armor ASLR, which doesn't have much value, IMO. The entropy is extremely low compared to upstream ASLR, but it would be actually 0 if left out in the nx-emu case. As such, it is only enabled on systems that are using nx-emu. I intend to try to get it upstreamed, but it's pretty far down on my TODO list[1]. Thanks, -Kees [1] http://git.kernel.org/?p=linux/kernel/git/frob/linux-2.6-roland.git;a=shortlog;h=refs/heads/fedora/x86-nx-emulation http://git.kernel.org/?p=linux/kernel/git/frob/linux-2.6-roland.git;a=shortlog;h=refs/heads/fedora/32bit-mmap-exec-randomization (this one is still missing one additional patch from me...) [2] https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Upstream%20Hardening -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101118192339.gf13...@outflux.net
Re: Minutes of the Debian linux-2.6 Group Meeting
Hi, On Thu, Nov 18, 2010 at 08:37:44PM +0100, Julien Cristau wrote: On Thu, Nov 18, 2010 at 11:23:39 -0800, Kees Cook wrote: On Thu, Nov 11, 2010 at 13:52:12 +, maximilian attems wrote: LSM: Enable AppArmor? as well as/instead of Tomoyo? --- As the LSM need to be built we can't enable them. This needs a technical solution were code can be disregarded as init sections or similar. AppArmor seems more popular as Opensuse and Ubuntu uses it. Technicaly Tomoyo is said to be cleaner. What do you mean by can't here? You can build _all_ of them, actually. The active LSM is just selected at boot-time through the kernel command line arguments. If it's a concern over kernel size, upstream specifically removed the ability to make the LSM modular, so this means that no additional LSMs will ever be available in Debian? See the second sentence. This needs a technical solution where code can be disregarded as init sections or similar. So your kernel has a bunch of LSMs builtin, but at boot time one of them is selected and you release the memory taken by the rest of them instead of keeping the code lying there unused. Right, my point was that upstream expressly moved away from that ability, which means, if combined with the other only if in upstream statements, the Debian kernel will only ever be built with one LSM. Now, don't get me wrong, I'd hugely prefer there be an __init-like way to handle this, and it actually touches on the constification work too. Still, blocking until the feature exists seems unfun. :) Thanks, -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101118200333.gg13...@outflux.net
Re: Minutes of the Debian linux-2.6 Group Meeting
On Thu, Nov 18, 2010 at 08:06:50PM +, Ben Hutchings wrote: On Thu, Nov 18, 2010 at 12:03:33PM -0800, Kees Cook wrote: Now, don't get me wrong, I'd hugely prefer there be an __init-like way to handle this, and it actually touches on the constification work too. Still, blocking until the feature exists seems unfun. :) I'm intending to work on this feature myself (and submit it upstream). Great! That'll be nice to have. -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101118200933.gi13...@outflux.net
Re: Minutes of the Debian linux-2.6 Group Meeting
On Thu, Nov 18, 2010 at 08:05:55PM +, Ben Hutchings wrote: On Thu, Nov 18, 2010 at 11:23:39AM -0800, Kees Cook wrote: Why? These patches are well maintained, and touch areas of the kernel that do not change much (making them very easy to merge). Why leave non-PAE x86 users out in the code when so many other distros use some form of this patchset? I've worked to make sure they only touch CONFIG_X86_32, so they're extremely minimal. [...] Then you should convince upstream that these are good and unintrusive. I intend to, but I'm certainly not the only one who can attempt it. I was hoping to get more people looking at and using the code as a first step. -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101118201059.gj13...@outflux.net
Re: Paris MiniDebConf Minutes
Hi, On Sat, 2010-11-06 at 22:23 +, Ben Hutchings wrote: On Sun, 2010-11-07 at 03:43 +0530, Ritesh Raj Sarraf wrote: The wiki lists most items marked as done. I am just curious to know what the decision has been made for AppArmor. Will it be enabled ? Only if we can find a way to make it modular or discardable. Hm? LSMs cannot be made modular. AppArmor is upstream already, so the question on the agenda was to add back the old-style interface methods and network mediation (so the userspace tools will work sanely). The desired LSM is selected at boot-time, so that's highly discardable. :) The agenda item wasn't asking for it to be the default LSM, just to be available at all. Thanks, -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101108203115.gp5...@outflux.net
Re: Paris MiniDebConf Minutes
On Mon, Nov 08, 2010 at 10:13:02PM +, Ben Hutchings wrote: By 'discardable' I mean that it would be possible to free the memory used for its code and static data if it was not used (similar to the way init code is discarded after boot). Right, this is an upstream limitation of the LSM when they made it non-modular, unfortunately. :( If a distro wants to make multiple LSMs available to their users, they have to compile them all in. Which is rather annoying. -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101108224321.gt5...@outflux.net
Re: item for kernel meeting -- NX emulation
On Tue, Nov 02, 2010 at 04:04:13PM +0100, maximilian attems wrote: hello Kees, On Fri, 29 Oct 2010, Kees Cook wrote: Thanks for adding this to the agenda! I've added details about both AppArmor and the nx-emulation bits to the wiki page. Let me know if you've got any questions. Do you know if newly split out 32bit-mmap-exec-randomization has a chance in going upstream or has already been submitted? I would fight it going upstream as it has terrible entropy. I feel it only has value when combined with the nx-emu patch, which would have 0 entropy for the relocated executable regions if left as-is. The goal discussed on the Fedora kernel list was to somehow get rewrites of the existing upstream ASLR so that it could be used with the nx-emu patch and then the 32bit-mmap-exec-randomization could be eliminated. The feature 32bit-mmap-exec-randomization is trying to implement is ASCII armor (leading 0 byte on addresses), but it's greedy-fit method creates a nearly deterministic layout for each given ELF. So if a way to do ASCII armor with the upstream ASLR can be created, it can be dropped. There has been no progress on this, though. -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101102154757.gj5...@outflux.net
Re: item for kernel meeting -- NX emulation
Hi, On Fri, Oct 29, 2010 at 08:43:12AM -0600, dann frazier wrote: On Fri, Oct 29, 2010 at 02:13:14PM +, maximilian attems wrote: On Fri, Oct 29, 2010 at 07:50:04AM -0600, dann frazier wrote: Kees poked me to see if Debian would consider including the NX emulation patch that Ubuntu and Fedora are currently shipping. I won't be able to make Paris this weekend, but I'd like to request that this get added to the agenda. Kees, can you provide a reference for the changes? [CC'ing the security team as well for possible feedback] items are to be found here, please just edit: http://wiki.debian.org/DebianKernel/Meetings appended. Thanks for adding this to the agenda! I've added details about both AppArmor and the nx-emulation bits to the wiki page. Let me know if you've got any questions. As far as AppArmor is concerned, I'll be uploading the userspace tools to experimental soon, since 2.6.36 is landing there now. Thanks, -Kees -- Kees Cook -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101029155057.gb5...@outflux.net
Bug#514938: alternatively...
Hi, On Thu, Feb 12, 2009 at 03:31:37PM +0100, maximilian attems wrote: do you have other patches from ubuntu queued up? I'm personally not aware of any single-item things to add, though there is a giant stack of patches against 0.92b in Ubuntu at the moment. I suspect there will be more to forward once Ubuntu 9.04 releases. I have CC'd Luke Yelavich, who did the 0.92b merge. Luke, anything to forward to Debian for initramfs-tools that isn't Ubuntu-specific? Thanks! -Kees -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514938: find/cpio exit codes ignored while building initramfs
Package: initramfs-tools
Version: 0.92o
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jaunty ubuntu-patch
The final stage of mkinitramfs that builds the image does not verify the
exit codes of find or cpio:
(cd ${DESTDIR} find . | cpio --quiet --dereference -o -H newc | gzip
${outfile}) || exit 1
Once bug 514936 is solved, this will be even more important, since cpio
will actually return errors. In bash, there is support for checking more
than just the final pipe command's exit code via the pipefail option.
Attached patch adds this behavior, and make sure the script uses bash (to
avoid future dash/bash migration issues).
Current behavior:
$ find /fail | cpio --quiet --dereference -o -H newc | gzip /tmp/archive.gz
find: `/fail': No such file or directory
$ echo $?
0
Desired behavior:
$ set -o pipefail
$ find /fail | cpio --quiet --dereference -o -H newc | gzip /tmp/archive.gz
find: `/fail': No such file or directory
$ echo $?
1
Also, I would recommend adding -e to the shell to catch single-command
failures during execution, though that's out of scope for this particular
bug.
Thanks!
-Kees
--
Kees Cook@debian.org
--- mkinitramfs~ 2009-02-11 17:18:41.0 -0800
+++ mkinitramfs 2009-02-11 17:19:40.0 -0800
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
umask 0022
export PATH='/usr/bin:/sbin:/bin'
@@ -296,6 +296,7 @@
fi
[ ${verbose} = y ] echo Building cpio ${outfile} initramfs
+set -o pipefail
(cd ${DESTDIR} find . | cpio --quiet --dereference -o -H newc | gzip ${outfile}) || exit 1
if [ -s ${__TMPCPIOGZ} ]; then
Bug#514938: alternatively...
Attached is a gross alternative to depending on bash...
--
Kees Cook@debian.org
--- mkinitramfs~ 2009-02-11 17:18:41.0 -0800
+++ mkinitramfs 2009-02-11 20:13:16.0 -0800
@@ -296,7 +296,24 @@
fi
[ ${verbose} = y ] echo Building cpio ${outfile} initramfs
-(cd ${DESTDIR} find . | cpio --quiet --dereference -o -H newc | gzip ${outfile}) || exit 1
+(
+# work around lack of set -o pipefail for the following pipe:
+# cd ${DESTDIR} find . | cpio --quiet --dereference -o -H newc | gzip ${outfile}
+exec 31
+eval `
+# http://cfaj.freeshell.org/shell/cus-faq-2.html
+exec 41 3 3-
+{
+cd ${DESTDIR} find . 4-; echo ec1=$?; 4
+} | {
+cpio --quiet --dereference -o -H newc 4-; echo ec2=$?; 4
+} | gzip ${outfile}
+echo ec3=$?; 4
+`
+if [ $ec1 -ne 0 ]; then exit $ec1; fi
+if [ $ec2 -ne 0 ]; then exit $ec2; fi
+if [ $ec3 -ne 0 ]; then exit $ec3; fi
+) || exit $?
if [ -s ${__TMPCPIOGZ} ]; then
cat ${__TMPCPIOGZ} ${outfile} || exit 1
