From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 716243B7746 for ; Thu, 30 Jul 2026 23:45:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785455141; cv=none; b=EiQ9PC52TaH+gGI+8PFj+9gFB9t07RRESH6iYnfpaMnwWknHcQ/melAXmXMwRUfJKI600LX58jmQHKeTEqkTQf/X1XygxvvRxYmRBwA52ENO6aV345glHJj6IVJgiQRTetODPXgqX1b6Hp7hhBf7VNrl11OaCku4+ydzQnrMFtA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785455141; c=relaxed/simple; bh=/oM7JBSTblLnG57a7tBXav9q+HOtRWW7AYV63dxcLZM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=uyl3YyKMyE3cNllc7YdIzMrL/I/xDD1AsWjsJu4K+J32Bh8LDcqgFzRMTLH+LrHs+9aGFTv9rVkgm4yXop75gzey4SWMMsoxXdfab4CwAL6B6LgXDa1CfWJXorJyTQpyN6P7qtnDY0mc1KRmSOporY3YOPY3KlfYurTdW5mSfTY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ZRndpjto; arc=none smtp.client-ip=209.85.219.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ZRndpjto" Received: by mail-qv1-f53.google.com with SMTP id 6a1803df08f44-8eefd4a8057so4593806d6.0 for ; Thu, 30 Jul 2026 16:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785455138; x=1786059938; 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=XnBhDRV9Lhz1WLumD8y8Q4NM2/ker0aTMu47IxfcVsk=; b=ZRndpjtoMMSnxrQZsuBN/kJWeNwlhKMPF0g+nbcyeCP4Z6VUN2vFZK+Cqdy3nED1Ko 4t8QImCZntTOBd2f/0X0K714fATQKD/a6d7VICi81f0wE4SkXAQCp2UZ+EffiDf62KNP c8bPViKeRSSLDbD7P83lD2V7lLeb1tpEI/KyIYkN9E4gQH6As8+5r6dquHwp3uB7/m7I 9TCJlAFIbKmg4U+8lIntRCTQRymPC5dM02NHFFZ07ObNaTwz6DPuMUbf1hNSJrJyallx efhuLWHtcgN0RmoKBaYA6E8bmp8x0exDywm5tzPeVVCI7u+igUz1/7Hp9rKEz7V7Zpfk mVMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785455138; x=1786059938; 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=XnBhDRV9Lhz1WLumD8y8Q4NM2/ker0aTMu47IxfcVsk=; b=HMNIXT9nr1CLQoVLZRbcOhS0H8qOPXP6XQNOtxcejgDr83GCkZDw4WtDXbUc8iSybE whTBvxXgUO8jG22II7EO7ERQ7XfCb5fQt1Vd+3FArt1zKVbaPdW4jZtIf56ao6KYEbEr nAjezzzVQ3j0dKJWA4K9fz3Lro0arIJlv/dENdF0G8QoEr8/dexAagMKl3CD+eAkZ1Xt nkF7U9tBSJAJRIWoF7Z6kR5ZhFUwWUpyVEcB+ij6vZEo3WqR/000gnFWy5fH8kTwLW42 XcITdpuTYBTj5nAR6Lmx0sS15x+6wFKpyWPHJiCOGAeq7PF97axlHjJemNLqN6nzkjIB y3XA== X-Forwarded-Encrypted: i=1; AHgh+RppxrVYg2VyIwSMpFE6p3gs7bQi8bUKptZCxD9T6VzxtfA2hFlgbMw1sgeHxu9B5nsh165hHk5pd57sPA0=@vger.kernel.org X-Gm-Message-State: AOJu0YzhS18J5ql/GqGPbKYqCqsXMcD63S4jNgMlAr6GifAyAKJ7fNDn Y20I7CmvUa8TjrQANug17wN82KfrkxjT4TK/y3jYMRfo2Q8HyiNqaoOc X-Gm-Gg: AR+sD13i/eSO3muKpiRM3ctvcJMRv8eTYCv0dyFXZNQkkszSF1nJT33u0lhRCMySxU5 1J5IJ8Trk6CCI3QsHJkrbaaIPpGvVApDfgHAXuDeYDg9nkuUN+J17KpAWWixFhcxSKUvr0uAg5a TGo6E9UzAWvJ4GaIaR6PsHdLPZplIggq7FC/laz1thjpomITNQkSH0xIWuQ2Yw/Y9O3iGoHzOeG rbakxV/npil3bsoh9lbrvrVc3R8jTvb3CDo5QAijE6mXZ+VsnMcjl1so5+d2+4RsoTGq0EWVxtj UtRQoiI+DcPy3xCeLAjA5HFn7/gR38OjdDUHd+WjaTULd9CtDLULz2MlwsRd8i2w19eLJSTy8iy Zqb9FugdgHk91/BbzY827SfU/7T6sFZ/D7lA6mQ0TsQ5tbMz0RlwrA9LRpHu0Agn9oZkRUAlcIF jUvfqspz4wpxvDOht+iuoRh4Wv5gX6ER5VeQlll9csvCtQqwT8EdecckQq2zJx7Wwgs4yVGnZEL endCTE46KzwlAdC31KHrMGNFiyJ2awSsP4mDMJOUpEO9Og8VgwtnRrai0jUwKI= X-Received: by 2002:a05:6214:1d06:b0:8fd:6dc5:94c with SMTP id 6a1803df08f44-9083482c8c6mr47873286d6.65.1785455138153; Thu, 30 Jul 2026 16:45:38 -0700 (PDT) Received: from battery.lan (pool-138-88-31-60.washdc.fios.verizon.net. [138.88.31.60]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-908323e8bc0sm28991836d6.26.2026.07.30.16.45.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Jul 2026 16:45:37 -0700 (PDT) From: David Windsor To: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , KP Singh , Jiri Olsa , Kumar Kartikeya Dwivedi , Emil Tsalapatis , Matt Bobrowski , Paul Moore , James Morris , "Serge E . Hallyn" , Casey Schaufler , Stephen Smalley , Ondrej Mosnacek , Mimi Zohar , Roberto Sassu , Dmitry Kasatkin , Eric Snowberg , Alexander Viro , Christian Brauner , Jan Kara , Shuah Khan Cc: bpf@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org, selinux@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, David Windsor Subject: [PATCH v6 bpf-next 0/4] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling Date: Thu, 30 Jul 2026 19:45:29 -0400 Message-ID: <20260730234533.1912709-1-dwindsor@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Many in-kernel LSMs (SELinux, Smack, IMA) store security labels in extended attributes. For these LSMs, atomic labeling during inode creation is critical: if the inode becomes accessible before its xattr is set, it is briefly unlabeled, which can disrupt LSMs making policy decisions based on file labels. Existing LSMs solve this by setting xattrs directly in the inode_init_security hook, which runs before the inode becomes accessible. BPF LSM programs currently lack this capability because the hook uses an output parameter (xattr_count) that BPF programs cannot write to, and existing kfuncs like bpf_set_dentry_xattr require a dentry that isn't available until after the inode is accessible. This series introduces the bpf_init_inode_xattr() kfunc, which takes the combined inode_init_security xattr context argument and claims a slot in it via the new security_lsmxattr_add() LSM helper. v6: - split struct lsm_xattrs / security_lsmxattr_add() into 2 patches (Paul) - drop the CONFIG_BPF_LSM bracketing in security_lsmxattr_add() (Paul) - have security_lsmxattr_add() take only extra name components (Paul) - return 0 from security_lsmxattr_add() when the filesystem does not provide an initxattrs callback (Paul) - selftests: label files in /dev/shm and skip when the hook does not run or the filesystem does not support xattrs at inode creation, fixing BPF CI failures on the 9p rootfs v5: - make the kfunc non-sleepable to avoid an ext4 deadlock (sashiko) - move xattr creation logic to security_lsmxattr_add() (Paul) - use distinct xattr names in init_inode_xattr_slot_limit v4: - introduce struct lsm_xattrs in separate patch (Alexei, Paul) - rename struct xattr_ctx to struct lsm_xattrs (Paul) - make lsm_xattrs.xattr_count unsigned int (Paul) - drop new_xattrs/xattr_count locals in security_inode_init_security() (Paul) - fold __bpf_init_inode_xattr() into bpf_init_inode_xattr() (Paul) - drop bpf_fs_kfuncs_filter() attach-point check; rely on verifier type enforcement (Alexei) - drop attach-time cap; enforce slot budget in the kfunc (Alexei) - allocate the combined xattr with GFP_NOFS (sashiko-bot) - replace init_inode_xattr_attach_cap selftest with runtime init_inode_xattr_slot_limit v3: - rename struct lsm_xattr_ctx to struct xattr_ctx (Paul) - increase BPF_LSM_INODE_INIT_XATTRS to 4 (Song) - enforce per-hook attachment cap at attach time to prevent runtime rejection (Paul) - add init_inode_xattr_attach_cap selftest v2: - pass the xattr state as a combined context object and drop the verifier fixup path (Kumar) - restrict bpf_init_inode_xattr labels to bpf.* namespace (Matt) - cap bpf_init_inode_xattr() at BPF_LSM_INODE_INIT_XATTRS slots per invocation (AI) v5: https://lore.kernel.org/bpf/20260708000956.46138-1-dwindsor@gmail.com/ David Windsor (4): security: introduce struct lsm_xattrs security: add security_lsmxattr_add() bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling selftests/bpf: add tests for bpf_init_inode_xattr kfunc fs/bpf_fs_kfuncs.c | 41 +++++ include/linux/bpf_lsm.h | 3 + include/linux/evm.h | 9 +- include/linux/lsm_hook_defs.h | 4 +- include/linux/lsm_hooks.h | 16 +- include/linux/security.h | 15 ++ security/bpf/hooks.c | 1 + security/integrity/evm/evm_main.c | 8 +- security/security.c | 120 ++++++++++++-- security/selinux/hooks.c | 4 +- security/smack/smack_lsm.c | 27 ++- tools/testing/selftests/bpf/bpf_kfuncs.h | 5 + .../selftests/bpf/prog_tests/fs_kfuncs.c | 156 ++++++++++++++++++ .../bpf/progs/test_init_inode_xattr.c | 33 ++++ 14 files changed, 395 insertions(+), 47 deletions(-) create mode 100644 tools/testing/selftests/bpf/progs/test_init_inode_xattr.c base-commit: 2659f94ed3be147942acbea96405efc562afb34c -- 2.53.0