From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=74.125.82.179 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793907476; b=rqVF+IKJZEWkdB90ESX3B9OvtlVhyk8wV3dF6I0y43zUrYZ+AZlDZzjLktZGnvWsj2eb SCAGsISmw2mboOLvQpvNWtYT01FA+escLIqaVJYMKF2lx2bHQ0a3+gAIXe8MTm7Z4EXlO cOQqMdDkvck3tmv7zGCUM0z6P8Tqe5eXHzeP1+jbSNyS9oCss4tDAcJPRnSV1YtQAsFBt HeTecA1LArlX28nSibg6biZXMZNigGD1FNGkVM2kU+lUbfxDrTQqPYondw8jf/qjH8/Os MwnCScCM9fAbegPK0CZMb+pZzMLsWBLjxIdi85xvsfnZWfQgTjjEEruNJZvVp/ip9Zg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793907476; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received:Received: From:To:Cc:Subject:Date:Message-ID:X-Mailer:MIME-Version: Content-Transfer-Encoding; bh=3ALiLRgUIlPUP7r35NUTeM7wiuqIXdzicUpxLmxb19E=; b=EBb8lguOsltEUX2FviUOyJQHBd8oAAWe1XnbQxMPGnjx9uRZ5gZsCVb4gMnu1dljm+mo 6gwOZO0B3BOy8aYM6PNYU4JzMQZezzrbIrbhFymmfSGP6kFeusI9gUjanjEA1p4R6ZHZO cdRhbrHTGfmebLAlldHBXU5pTXJ/Qi1pl1GW5n2LMFz1U1Dvp5X7JKU4X3PR7DjWIBKZw RWmJ3AxBela/wmyNwJmRQgSot370QYb1AMURApEn3VNs5HRdQiuzR9grreT4DAKgWeP63 NKta0hvrjaNsnYKGAZv33aMpt165t7EheMsHaXMfMDjEnmiVpDF2sFWksksTxYygaQQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=arista.com; spf=pass smtp.mailfrom=arista.com; dkim=pass header.d=arista.com header.i=@arista.com header.a=rsa-sha256 header.s=google header.b=CtJWa3tE; arc=none smtp.remote-ip=74.125.82.179 Received: from mail-dy1-f179.google.com (mail-dy1-f179.google.com [74.125.82.179]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AB7B7606B9F1 for ; Thu, 5 Nov 2026 19:37:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org AB7B7606B9F1 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=arista.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arista.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=arista.com header.i=@arista.com header.a=rsa-sha256 header.s=google header.b=CtJWa3tE Received: by mail-dy1-f179.google.com with SMTP id 5a478bee46e88-36d6765756fso2917124eec.1 for ; Thu, 05 Nov 2026 11:37:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=google; t=1793907474; x=1794512274; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=3ALiLRgUIlPUP7r35NUTeM7wiuqIXdzicUpxLmxb19E=; b=CtJWa3tEL/dQ/RdyYOmPv2dc/ZxWSmCzdkel6b5w4cFqUR8L8Yi6Jqvw3+gCKmj1Wb 8F2PKydr3mpYlrF8QH3i7YW/bayrWHul9bNjqh+POZbqKFiRA8ayJ67ofnOCXF+sQIcp mYJ3+ovEP8dkI6pcu9/gDn0ViYnsz86zDwEZdGq/yHQDWuWIqJN+tcZFgE8J/4OINklC A3S8WWTFwSLWNOiYD0tjjK366TSXcc98utBOaoeROKpMMcYhCu2LFzpCHZWbEUJoLF8+ hpvZa1olcHLdvPqnS1eJtevWQK3BISF3T9V9gHs6DqgAFfkmwshhrXpzShEuswdCN2pq U8qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793907474; x=1794512274; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=3ALiLRgUIlPUP7r35NUTeM7wiuqIXdzicUpxLmxb19E=; b=YTHKjdE8q8gnAFUIaVrqq7Rax+KCX3KEpxY/wawkP6KnzwouN1S5L9jP49j+sSUYMm /b1O1gI0DLl7a8DrUavETnv9B7XvIF+mbBac4wZ6MDMn19g2xucRf9GkbA5rdq9UFRbM yB9Qb2EQH0/iDaFftAmzsPy3ibKygk+rsQjrMY2GXpIHxA5BvtI3J3r/b9DSL/1HOqgG FtJyCIhebW371+aXfSrqNWLIffKL+Q8ITBPiO4bPpPQbfjvUH0xxR6RnMALlzGHdOFiD VeWHuVS7TkVjyHxRBULG832EDhCPwodpWbC6jE8AH9HeELTRS9CpHtyiQoWHpEdkpmAQ 8fag== X-Forwarded-Encrypted: i=1; AKwUvByLSdT4QHi0ccjm4Ffapke5oirwBSNufzN0xkkdzNeRIXAOYCAjKl6uXKQC3zDK5PeFzR/inuAqLsJ7EXk=@vger.kernel.org X-Gm-Message-State: APuU4Z/4/RHvBBMYmtMUEOwazRfL66SXf7rVOwF1Z5oJZSLbfp+ihd3k cDOZKBeQI0z+gOGl2UUpECwKeQy9YmSjgncSwGAW0DHlkjrEzZfkxZ6OOqehPp+OtQ== X-Gm-Gg: AYBFou3PZ/uxqhLrIJSw+rT9d5k7H3OeTKITRm7XoYkgUyYoOgdXkEzZGf8UNURWC4h dRsgfYhVZEwoO3JBDC/VVSen0qLRiJx6jH8t7naOgHKdqS2+nl9BgBl1om347WHnFqnO8CpXsSR bNcxfAINqdBQtCev4gAnnohHAXs4bN9tHDKrgxn1EJ0ccLhscNUyAeZZ7ZdY+b8oljhoMkSvxgH YM9TrJTHAihScqWqjfwtao5d0rLsEF0c0nBQ1nyzoqkojpW8G8QpiRtb4v5msexKyDwFi2cw/ha 1q86+qeQcuEcQAHBmfnrcgR3AhcQLNdMYdg/X8mNnWl4gha3xAGm85iSc4einS2IvbovQYHmBgA oX/MpGjkNZVwciYGlox86HodmmRbyGfuLD0Aqo3AJoxFUtXwYRJu7yIjJFR9Em+rEQvO3Ni7yTT N3PcwUicH98EijkSYJau60pBDd8WyKNcYRW5ttEELmDmmXTkTIVkR6EXhMNW4j+nMxNbhOEyBRE dVqF0fifBq1m+1FePtX9FhaCi5s01kKIZw8RilOTIL4lil6pLz2GkmjdRXhqBQ3PrLnuTwRBzUR iARW6DrEPLTnU9K+JsQbUEtePRBfQKdCBuyl4g/84efpskQGUSG0n85LW2YpUudO98sN2txSuSP L5RxT9XXXGd3pv9crO+fdHSk= X-Received: by 2002:a05:693c:40c8:b0:36d:2b02:86a6 with SMTP id 5a478bee46e88-36f72cc1ae3mr274930eec.4.1793907473472; Thu, 05 Nov 2026 11:37:53 -0800 (PST) Received: from dannyhu-upstreamLinux.sjc.aristanetworks.com ([74.123.28.19]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-36f72ec8a02sm326134eec.11.2026.11.05.11.37.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Nov 2026 11:37:53 -0800 (PST) From: Danny Hu To: Alexander Viro , Christian Brauner Cc: Mimi Zohar , Roberto Sassu , Dmitry Kasatkin , Eric Snowberg , Jan Kara , Victor Kamensky , Taras Kondratiuk , Zheng Zengkai , zhangguangzhi , Danny Hu , Jason Yan , silviu.vlasceanu@huawei.com, hpa@zytor.com, arnd@arndb.de, james.w.mcmechan@gmail.com, niveditas98@gmail.com, pierre@arista.com, julien@arista.com, kbharathi@arista.com, alexandr.lobakin@intel.com, linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kbuild@vger.kernel.org, initramfs@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, bug-cpio@gnu.org Subject: [PATCH v6 0/4] initramfs: add support for xattrs in the initial ram disk Date: Thu, 5 Nov 2026 11:37:39 -0800 Message-ID: <20261105193743.2654656-1-dannyhu@arista.com> X-Mailer: git-send-email 2.51.0 X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 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 changes in v6 address issues identified by the Sashiko AI review. v5 revision: https://lore.kernel.org/linux-fsdevel/20261030210944.2143778-1-dannyhu@arista.com/. The major difference from v5 is that this revision introduces a new state in the initramfs parser that specifically handles buffering metadata entries in memory. This has the benefit of preventing a metadata file from being created in the rootfs, eliminating the need for a metadata flag and separates metadata collection from do_copy. Sashiko identified the lack of support for POSIX ACL xattr restoration; while this is true, the primary use case of this feature is restoration of the security.ima xattr for IMA. Therefore, POSIX ACL xattr restoration is out of scope for this patchset and can be implemented later on when needed. This revision also adds xattr length validation, bounds checks that prevent overflow, improvements to tracking of the metadata target and fixes to gen_init_cpio to handle a NULL ptr and to define the __packed macro. This v5 revives Roberto Sassu's v4 series posted on May 23, 2019 (https://lkml.org/lkml/2019/5/23/415). The github issue tracking the revival of this patchset is here (https://github.com/linux-integrity/linux/issues/11). This revision incorporates unpublished changes from other contributors that can be found in (https://github.com/linux-integrity/linux/tree/initramfs-xattr-v1-devel-v1) and adapts the implementation to newer kernel interfaces. Compared with v4, this revision adds an IMA deadlock fix for restoring security.ima xattrs during initramfs unpacking, switches to a Kconfig choice for metadata type selection, and updates gen_initramfs.sh to pass source paths to gen_init_cpio for nonregular entries, allowing their xattrs to be read from the correct source object that will be included in the archive. This revision also includes various improvements to error path cleanup, debug output and tool documentation. 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 would require adapting adding the dedicated CollectMetadata state along with the pathname target tracking. 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 Changes in v6: - Document that POSIX ACL restoration is currently unsupported - Validate xattr name and value lengths and compare metadata header and entry sizes to remaining buffer when performing bounds checks to avoid pointer arithmetic overflow - Introduce a dedicated CollectMetadata state to consume METADATA!!! entries in memory. This replaces the metadata flag and avoids creating the metadata entry as a file in the rootfs. - Verify metadata entry checksums before restoring xattrs - Initialize and improve tracking of the previous_name_buf so skipped or failed entries do not leave an uninitialized or stale metadata target - Fix gen_init_cpio handling NULL path ptr and define __packed before including the shared metadata header Changes in v5 relative to v4: - Rebase onto vfs.all - Add an IMA fix to avoid a deadlock during initramfs metadata restoration - Use u32 metadata record lengths and reject records smaller than their header - Improve debug output for binary xattr data - Cleanup metadata buffers at the end of unpack_to_rootfs() - For CONFIG_INITRAMFS_FILE_METADATA, replace the metadata string prompt with a none/xattr choice - Fix resource cleanup and format specifiers in gen_init_cpio - Update gen_initramfs.sh to pass source paths to gen_init_cpio.c for nonregular entries (slink, dir, nod). Modify gen_init_cpio to properly collect xattrs from the source object. Without this change, xattrs will not get included for slink, dir and nod. - Add documentation of xattr option in usage() for gen_init_cpio 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 Danny Hu (1): ima: skip algorithm availability check until initramfs unpacking is finished 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 | 19 +++ init/initramfs.c | 206 ++++++++++++++++++++++-- security/integrity/ima/ima_appraise.c | 25 +++ usr/Kconfig | 19 +++ usr/Makefile | 3 +- usr/gen_init_cpio.c | 221 ++++++++++++++++++++++---- usr/gen_initramfs.sh | 15 +- 7 files changed, 460 insertions(+), 48 deletions(-) create mode 100644 include/linux/initramfs.h base-commit: 2c3ba1f1cb416b81d617b92a24a4bcaa48d574e3 -- 2.51.0