From: Roberto Sassu <roberto.sassu@huawei.com>
To: Alexander Lobakin <alexandr.lobakin@intel.com>
Cc: "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>,
"initramfs@vger.kernel.org" <initramfs@vger.kernel.org>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"bug-cpio@gnu.org" <bug-cpio@gnu.org>,
"zohar@linux.vnet.ibm.com" <zohar@linux.vnet.ibm.com>,
Silviu Vlasceanu <Silviu.Vlasceanu@huawei.com>,
Dmitry Kasatkin <dmitry.kasatkin@huawei.com>,
"takondra@cisco.com" <takondra@cisco.com>,
"kamensky@cisco.com" <kamensky@cisco.com>,
"hpa@zytor.com" <hpa@zytor.com>, "arnd@arndb.de" <arnd@arndb.de>,
"rob@landley.net" <rob@landley.net>,
"james.w.mcmechan@gmail.com" <james.w.mcmechan@gmail.com>,
"niveditas98@gmail.com" <niveditas98@gmail.com>
Subject: RE: [PATCH v4 0/3] initramfs: add support for xattrs in the initial ram disk
Date: Wed, 15 Jun 2022 16:03:35 +0000 [thread overview]
Message-ID: <d6479ebe656d4a75909b556d4cbcee22@huawei.com> (raw)
In-Reply-To: <20220615155034.1271240-1-alexandr.lobakin@intel.com>
> From: Alexander Lobakin [mailto:alexandr.lobakin@intel.com]
> Sent: Wednesday, June 15, 2022 5:51 PM
> From: Roberto Sassu <roberto.sassu@huawei.com>
> Date: Thu, 23 May 2019 14:18:00 +0200
>
> > This patch set aims at solving the following use case: appraise files from
> > the initial ram disk. To do that, IMA checks the signature/hash from the
>
> Hi,
> is this[0] relatable somehow?
Hi Alexander
seems a separate problem. For that, we opted for having a dedicated
kernel option:
https://github.com/openeuler-mirror/kernel/commit/18a502f7e3b1de7b9ba0c70896ce08ee13d052da
Thanks
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Yang Xi, Li He
> > security.ima xattr. Unfortunately, this use case cannot be implemented
> > currently, as the CPIO format does not support xattrs.
> >
> > This proposal consists in including file metadata as additional files named
> > METADATA!!!, for each file added to the ram disk. The CPIO parser in the
> > kernel recognizes these special files from the file name, and calls the
> > appropriate parser to add metadata to the previously extracted file. It has
> > been proposed to use bit 17:16 of the file mode as a way to recognize files
> > with metadata, but both the kernel and the cpio tool declare the file mode
> > as unsigned short.
> >
> > The difference from v2, v3 (https://lkml.org/lkml/2019/5/9/230,
> > https://lkml.org/lkml/2019/5/17/466) is that file metadata are stored in
> > separate files instead of a single file. Given that files with metadata
> > must immediately follow the files metadata will be added to, image
> > generators have to be modified in this version.
> >
> > The difference from v1 (https://lkml.org/lkml/2018/11/22/1182) is that
> > all files have the same name. The file metadata are added to is always the
> > previous one, and the image generator in user space will make sure that
> > files are in the correct sequence.
> >
> > The difference with another proposal
> > (https://lore.kernel.org/patchwork/cover/888071/) is that xattrs can be
> > included in an image without changing the image format. Files with metadata
> > will appear as regular files. It will be task of the parser in the kernel
> > to process them.
> >
> > This patch set extends the format of data defined in patch 9/15 of the last
> > proposal. It adds header version and type, so that new formats can be
> > defined and arbitrary metadata types can be processed.
> >
> > The changes introduced by this patch set don't cause any compatibility
> > issue: kernels without the metadata parser simply extract the special files
> > and don't process metadata; kernels with the metadata parser don't process
> > metadata if the special files are not included in the image.
> >
> > >>From the kernel space perspective, backporting this functionality to older
> > kernels should be very easy. It is sufficient to add two calls to the new
> > function do_process_metadata() in do_copy(), and to check the file name in
> > do_name(). From the user space perspective, unlike the previous version of
> > the patch set, it is required to modify the image generators in order to
> > include metadata as separate files.
> >
> > Changelog
> >
> > v3:
> > - include file metadata as separate files named METADATA!!!
> > - add the possibility to include in the ram disk arbitrary metadata types
> >
> > v2:
> > - replace ksys_lsetxattr() with kern_path() and vfs_setxattr()
> > (suggested by Jann Horn)
> > - replace ksys_open()/ksys_read()/ksys_close() with
> > filp_open()/kernel_read()/fput()
> > (suggested by Jann Horn)
> > - use path variable instead of name_buf in do_readxattrs()
> > - set last byte of str to 0 in do_readxattrs()
> > - call do_readxattrs() in do_name() before replacing an existing
> > .xattr-list
> > - pass pathname to do_setxattrs()
> >
> > v1:
> > - move xattr unmarshaling to CPIO parser
> >
> >
> > Mimi Zohar (1):
> > initramfs: add file metadata
> >
> > Roberto Sassu (2):
> > initramfs: read metadata from special file METADATA!!!
> > gen_init_cpio: add support for file metadata
> >
> > include/linux/initramfs.h | 21 ++++++
> > init/initramfs.c | 137 +++++++++++++++++++++++++++++++++++++-
> > usr/Kconfig | 8 +++
> > usr/Makefile | 4 +-
> > usr/gen_init_cpio.c | 137 ++++++++++++++++++++++++++++++++++++--
> > usr/gen_initramfs_list.sh | 10 ++-
> > 6 files changed, 305 insertions(+), 12 deletions(-)
> > create mode 100644 include/linux/initramfs.h
> >
> > --
> > 2.17.1
>
> [0] https://lore.kernel.org/all/20210702233727.21301-1-alobakin@pm.me
>
> Thanks,
> Olek
next prev parent reply other threads:[~2022-06-15 16:03 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-23 12:18 [PATCH v4 0/3] initramfs: add support for xattrs in the initial ram disk Roberto Sassu
2019-05-23 12:18 ` [PATCH v4 1/3] initramfs: add file metadata Roberto Sassu
2022-06-15 17:54 ` Eugeniu Rosca
2019-05-23 12:18 ` [PATCH v4 2/3] initramfs: read metadata from special file METADATA!!! Roberto Sassu
2019-07-01 12:54 ` Mimi Zohar
2019-05-23 12:18 ` [PATCH v4 3/3] gen_init_cpio: add support for file metadata Roberto Sassu
2019-06-30 15:27 ` Mimi Zohar
2022-06-16 14:47 ` Eugeniu Rosca
2022-06-16 15:16 ` Eugeniu Rosca
2022-06-30 15:06 ` Roberto Sassu
2022-06-30 20:38 ` Eugeniu Rosca
2019-06-03 9:31 ` [PATCH v4 0/3] initramfs: add support for xattrs in the initial ram disk Roberto Sassu
2019-06-03 18:32 ` Rob Landley
2019-06-26 8:15 ` Roberto Sassu
2019-06-30 15:39 ` Mimi Zohar
2019-07-01 13:42 ` Roberto Sassu
2019-07-01 14:31 ` Mimi Zohar
2019-07-15 16:54 ` Roberto Sassu
2019-07-24 15:34 ` Roberto Sassu
2022-06-09 10:26 ` Eugeniu Rosca
2022-06-09 11:05 ` Roberto Sassu
2022-06-10 15:33 ` Eugeniu Rosca
2022-06-10 15:38 ` Roberto Sassu
2022-06-15 9:27 ` Eugeniu Rosca
2022-07-18 16:36 ` Jim Baxter
2022-07-18 16:49 ` Roberto Sassu
2022-07-18 18:08 ` Jim Baxter
2022-07-19 6:55 ` Roberto Sassu
2022-07-19 11:50 ` Rob Landley
2022-07-19 12:26 ` Roberto Sassu
2022-07-19 14:14 ` Rob Landley
2022-07-20 11:52 ` Roberto Sassu
2022-07-29 10:37 ` Jim Baxter
2022-07-30 9:39 ` Rob Landley
2022-07-19 11:33 ` Rob Landley
2022-07-19 11:00 ` Rob Landley
2019-07-01 13:22 ` Mimi Zohar
2022-06-15 15:50 ` Alexander Lobakin
2022-06-15 16:03 ` Roberto Sassu [this message]
2022-06-16 13:24 ` Eugeniu Rosca
Reply instructions:
You may reply publicly 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=d6479ebe656d4a75909b556d4cbcee22@huawei.com \
--to=roberto.sassu@huawei.com \
--cc=Silviu.Vlasceanu@huawei.com \
--cc=alexandr.lobakin@intel.com \
--cc=arnd@arndb.de \
--cc=bug-cpio@gnu.org \
--cc=dmitry.kasatkin@huawei.com \
--cc=hpa@zytor.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=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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).