lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <FAF78781-2684-4482-9D4D-445B91C15E97@zytor.com> Date: Wed, 22 May 2019 09:18:36 -0700 From: hpa@...or.com To: Rob Landley <rob@...dley.net>, Roberto Sassu <roberto.sassu@...wei.com>, viro@...iv.linux.org.uk CC: linux-security-module@...r.kernel.org, linux-integrity@...r.kernel.org, initramfs@...r.kernel.org, linux-api@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, zohar@...ux.vnet.ibm.com, silviu.vlasceanu@...wei.com, dmitry.kasatkin@...wei.com, takondra@...co.com, kamensky@...co.com, arnd@...db.de, james.w.mcmechan@...il.com, niveditas98@...il.com Subject: Re: [PATCH v3 2/2] initramfs: introduce do_readxattrs() On May 17, 2019 7:16:04 PM PDT, Rob Landley <rob@...dley.net> wrote: >On 5/17/19 4:41 PM, H. Peter Anvin wrote: >> On 5/17/19 1:18 PM, hpa@...or.com wrote: >>> >>> Ok... I just realized this does not work for a modular initramfs, >composed at load time from multiple files, which is a very real >problem. Should be easy enough to deal with: instead of one large file, >use one companion file per source file, perhaps something like >filename..xattrs (suggesting double dots to make it less likely to >conflict with a "real" file.) No leading dot, as it makes it more >likely that archivers will sort them before the file proper. >>> >>> A side benefit is that the format can be simpler as there is no need >to encode the filename. >>> >>> A technically cleaner solution still, but which would need archiver >modifications, would be to encode the xattrs as an optionally nameless >file (just an empty string) with a new file mode value, immediately >following the original file. The advantage there is that the archiver >itself could support xattrs and other extended metadata (which has been >requested elsewhere); the disadvantage obviously is that that it >requires new support in the archiver. However, at least it ought to be >simpler since it is still a higher protocol level than the cpio archive >itself. >>> >>> There's already one special case in cpio, which is the >"!!!TRAILER!!!" filename; although I don't think it is part of the >formal spec, to the extent there is one, I would expect that in >practice it is always encoded with a mode of 0, which incidentally >could be used to unbreak the case where such a filename actually >exists. So one way to support such extended metadata would be to set >mode to 0 and use the filename to encode the type of metadata. I wonder >how existing GNU or BSD cpio (the BSD one is better maintained these >days) would deal with reading such a file; it would at least not be a >regression if it just read it still, possibly with warnings. It could >also be possible to use bits 17:16 in the mode, which are traditionally >always zero (mode_t being 16 bits), but I believe are present in most >or all of the cpio formats for historical reasons. It might be accepted >better by existing implementations to use one of these high bits >combined with S_IFREG, I dont know. >> >> >> Correction: it's just !!!TRAILER!!!. > >We documented it as "TRAILER!!!" without leading !!!, and that its >purpose is to >flush hardlinks: > >https://www.kernel.org/doc/Documentation/early-userspace/buffer-format.txt > >That's what toybox cpio has been producing. Kernel consumes it just >fine. Just >checked busybox cpio and that's what they're producing as well... > >Rob Yes, TRAILER!!! is correct. Somehow I managed to get it wrong twice. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Powered by blists - more mailing lists