Linux-Integrity Archive on lore.kernel.org
 help / color / Atom feed
From: hpa@zytor.com
To: Rob Landley <rob@landley.net>,
	Roberto Sassu <roberto.sassu@huawei.com>,
	viro@zeniv.linux.org.uk
Cc: linux-security-module@vger.kernel.org,
	linux-integrity@vger.kernel.org, initramfs@vger.kernel.org,
	linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, zohar@linux.vnet.ibm.com,
	silviu.vlasceanu@huawei.com, dmitry.kasatkin@huawei.com,
	takondra@cisco.com, kamensky@cisco.com, arnd@arndb.de,
	james.w.mcmechan@gmail.com, niveditas98@gmail.com
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: <a0afd58f-c682-66b5-7478-c405a179d72a@landley.net>

On May 17, 2019 7:16:04 PM PDT, Rob Landley <rob@landley.net> wrote:
>On 5/17/19 4:41 PM, H. Peter Anvin wrote:
>> On 5/17/19 1:18 PM, hpa@zytor.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.

  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 \
    --to=hpa@zytor.com \
    --cc=arnd@arndb.de \
    --cc=dmitry.kasatkin@huawei.com \
    --cc=initramfs@vger.kernel.org \
    --cc=james.w.mcmechan@gmail.com \
    --cc=kamensky@cisco.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=niveditas98@gmail.com \
    --cc=rob@landley.net \
    --cc=roberto.sassu@huawei.com \
    --cc=silviu.vlasceanu@huawei.com \
    --cc=takondra@cisco.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zohar@linux.vnet.ibm.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 \
		linux-integrity@vger.kernel.org linux-integrity@archiver.kernel.org
	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