From: email@example.com To: Rob Landley <firstname.lastname@example.org>, Roberto Sassu <email@example.com>, firstname.lastname@example.org Cc: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH v3 2/2] initramfs: introduce do_readxattrs() Date: Wed, 22 May 2019 09:18:36 -0700 Message-ID: <FAF78781-2684-4482-9D4D-445B91C15E97@zytor.com> (raw) In-Reply-To: <email@example.com> On May 17, 2019 7:16:04 PM PDT, Rob Landley <firstname.lastname@example.org> wrote: >On 5/17/19 4:41 PM, H. Peter Anvin wrote: >> On 5/17/19 1:18 PM, email@example.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.
next prev parent reply index Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-17 16:55 [PATCH v3 0/2] initramfs: add support for xattrs in the initial ram disk Roberto Sassu 2019-05-17 16:55 ` [PATCH v3 1/2] initramfs: set extended attributes Roberto Sassu 2019-05-17 16:55 ` [PATCH v3 2/2] initramfs: introduce do_readxattrs() Roberto Sassu 2019-05-17 20:18 ` hpa 2019-05-17 21:02 ` Arvind Sankar 2019-05-17 21:10 ` Arvind Sankar 2019-05-20 8:16 ` Roberto Sassu 2019-05-17 21:47 ` H. Peter Anvin 2019-05-17 22:17 ` Arvind Sankar 2019-05-20 9:39 ` Roberto Sassu 2019-05-22 16:17 ` hpa 2019-05-22 17:22 ` Roberto Sassu 2019-05-22 19:26 ` Rob Landley 2019-05-22 20:21 ` Taras Kondratiuk 2019-05-17 21:17 ` Rob Landley 2019-05-17 21:41 ` H. Peter Anvin 2019-05-18 2:16 ` Rob Landley 2019-05-22 16:18 ` hpa [this message] 2019-05-20 8:47 ` Roberto Sassu 2019-05-17 23:09 ` kbuild test robot 2019-05-18 1:02 ` kbuild test robot 2019-05-18 5:49 ` kbuild test robot
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=FAF78781-2684-4482-9D4D-445B91C15E97@zytor.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-Integrity Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-integrity/0 linux-integrity/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-integrity linux-integrity/ https://lore.kernel.org/linux-integrity \ firstname.lastname@example.org email@example.com public-inbox-index linux-integrity Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-integrity AGPL code for this site: git clone https://public-inbox.org/ public-inbox