From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm2-f0.google.com (mail-wm2-f0.google.com [74.125.225.128]) (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 B5F1A34F259 for ; Wed, 8 Jul 2026 03:12:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.128 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783480352; cv=none; b=iGU4D6NoT0nXzNu2An4kpL4s7uAjEdziW77jc7GVxA2LXMdANMs14ta8JlKWA0iB96heAjYBZy/1kvKuO1gBXAhlhaMuYJebsSus1rxGWoNKwXLw+vyrDAppdDzazVXA77Kpg2Ficg2MrSVRhLXy3r3FJPIzN9FYtr9U3HQL1jc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783480352; c=relaxed/simple; bh=Pfob3D8mbkTTmUhLmKjlXVr2c00IRc98rAq6J6IGM8w=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=AD2ZZZ4PO7ie4Si9xwcVc1nyq/7uhvEELlY1eDeeJj7lt1j7Lkb9zlk/rBuxKr2lcx1CjHwdE2JOtfWYWqmYdhCajGQ3hNsQybW4zf5fkjnoZJ/IgMv1B/Nws73dEX0WVwStEQCS0jlBiDJdIDqEeE6MgMZf7KOMPO7ffCQcg6Y= 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=k/Fkq1VY; arc=none smtp.client-ip=74.125.225.128 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="k/Fkq1VY" Received: by mail-wm2-f0.google.com with SMTP id 5b1f17b1804b1-493c234fba7so433435e9.1 for ; Tue, 07 Jul 2026 20:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783480349; x=1784085149; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=Pfob3D8mbkTTmUhLmKjlXVr2c00IRc98rAq6J6IGM8w=; b=k/Fkq1VY6aeB5pCEiugfcDxREjIseLxREzoYRra3lE9/nqbw3tzGUDUwgcfTQhdPsO 6YRANdwssFS43X6i5wjYdG1mWrE/DRmgirvreyqiSlkwWfdz4a5eCsDpZRC+RTdSPmw0 s+W5PsJt+eRo2JyW4vt8cm8j6o18Bwrkmz2tCwBaIMcyksROnhGmOYOIVuwU8XGA3Wqy P9nmOlHdFf5X58K68DiuTgf7FFiW5HMU1uSojZ53q8h1A6VVKcR3ii21saKSMp6KCCIm 4KgFIa31hmpuSnLYxbi7pq9tr33pEdk0kCkz2ENTEr0iq5VKs6yKz183SaDGqJl8eQ5U mB8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783480349; x=1784085149; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Pfob3D8mbkTTmUhLmKjlXVr2c00IRc98rAq6J6IGM8w=; b=b/6fbPqgpnbxt+1IDTtkwlmwh4ILQlWSipC/mimQZSNZVoJVryGK6sMUG9N5CP4akX yejHuXbReFmPZpr7uT1m3sIN0XkeDaKV5bSRBLR9cFU9ryQTEGH4DOGMPyHdg+RNZPke S9+Y1ihKx4w73Lyqn8y8bcQQlKHgzF/Vq4Cb4s4ZrZd88nfDUli6zAttkWZDJIO1yx51 UiimcGIp0er1hsq2wreS0tEuxKxb6EIJhqS/9oA5u4KjkmPtBSQIYoziHhwUvLC2GP89 M4CIDgGbeFbl93ppVJPEtj3hx/VegcY8CC/AbrKzWO9y4Gb5H1KJjdydVFocTeEaJEYp /nOg== X-Forwarded-Encrypted: i=1; AHgh+RqXg4jAqduejuYL32Vnp0fJ81Mm//kZS9gLfzUj9tPQt384SvMETTB6GSshAKiicd7p6gEOwkijx0TO28A=@vger.kernel.org X-Gm-Message-State: AOJu0YyJU1JvH0cwztcFzc4GjzReYt02k6ksx/ogBcfnjKYt1IG9OubV fzJeqBamWubs+h/7V6Lf8AxmYSmyeUa5I2ycDVCPr+VLarsC3CCDrpQC X-Gm-Gg: AfdE7cldEb9OBD5uvLkN9xQwGL/li7t9FljhacRRDBzL3N7J1tz/zwqP0NqrGtfFE95 bH2LXELPS7TcUErxDRIPyW+5gLfof2hrbvd1qJFkJKKrAQ5L6OA4fWMadMahOkyS+iskQRpU6D3 HCKBw7GCyDfO5WsWaa+dbGKaB/f5ZzaPoUWKRP0bsD7b4wDVEUzPW/aAplWHjXCK1knTmIV339a Vm5U8WzjCPROGfyf6vLnsO3c7a6cRabemhJFvHcwDziCUqYvIoQW3/dCix7nIcHfGucOoL8Eb2N J9m01FnNYCfGQUzulLChPnKfVqO5K5rXiKqoGWvA3D4SvfUZZMK9jzebVfQtPQV2PqAE1LXDmdz RFLIK+jib7UvGC0lcM8XJNL7z621ig1PbBm6HDcg1+upZNqky6vrmvTjPWyyxs0CY/1C21KZa1c C7loWkUFV9zNdh48TJkqD1Oc38Qfp3Ge9NkrATtBbomdmJX0ka/4NemjSEhNTqTFnytBkwM2PMb EcxwjOD9VBdaB2eAZu1APgisQlMY1hVsOcU5Yi8igqV/3FCO4W8HrQ= X-Received: by 2002:a05:600c:6085:b0:492:454c:347c with SMTP id 5b1f17b1804b1-493e6859969mr4220535e9.7.1783480348874; Tue, 07 Jul 2026 20:12:28 -0700 (PDT) Received: from localhost (nat-icclus-192-26-29-3.epfl.ch. [192.26.29.3]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-493e610532fsm19286465e9.0.2026.07.07.20.12.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2026 20:12:28 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 08 Jul 2026 05:12:28 +0200 Message-Id: Cc: , , , , , , Subject: Re: [PATCH v5 bpf-next 0/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling From: "Kumar Kartikeya Dwivedi" To: "David Windsor" , "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" X-Mailer: aerc 0.21.0 References: <20260708000956.46138-1-dwindsor@gmail.com> In-Reply-To: <20260708000956.46138-1-dwindsor@gmail.com> On Wed Jul 8, 2026 at 2:09 AM CEST, David Windsor wrote: > 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. > There are various CI failures in newly added tests, I don't think any of th= em are passing. Please fix before respinning. https://github.com/kernel-patches/bpf/pull/12730 E.g. both test_init_inode_xattr and test_init_inode_xattr_slot do not have expected results. pw-bot: cr > [...]