From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm2-f1.google.com (mail-wm2-f1.google.com [74.125.225.129]) (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 B5B7534A794 for ; Wed, 8 Jul 2026 03:12:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.129 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783480352; cv=none; b=G4wGC685b/J9ZyDhumuNrbSsstmKiCmsK0wVqwarTYUAJ6N6ABm7+szGXcXy1SqZvgyiMOhLSjTMy/M/+u6vmRCHGdbConoIT7ssx5zycKUrvOIPDNyUxs44Gv8kUZFFsyAU/jk7dlJNnxDGxUSuXvg1hgHJVFysn0ViDKvNzGI= 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.129 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-f1.google.com with SMTP id 5b1f17b1804b1-493b829982dso470205e9.0 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=CFee17JmRtt4UQwcVumu6h4TGhzeF60+Hxs18KsquLZEpd9/Xfax+3tF6qMYUb91C1 Y1mTFyRD0zPJTt2zUocYtw250tKkPZBw70KURjUbTCrmM9AXYMPSmKdHBSArhTfLLe/t wa/cVvRZTty53f8qLcYW9DBRBFfkRk2+ikcdox5vnYKAVB29IomM577a4pT+TdxzpnO6 YvHv53bJOeWma7tWyA7/0SzgK+9ROTGwtaBAkOYf1+W0/pkB4tqyEtWiW3OUMt72r2M8 aW8kuCbUNppV2K2rYUxZpIxdk2pkkL0rKzWSjdoiWF7WgS+r8T9p1/9apvvQWZa1q69n gaxg== X-Forwarded-Encrypted: i=1; AHgh+Rpw+HxBcpJ7xAkJe62bSmXxhrBUUhJbB0kkELjhsnoYXn7TCqhFshPi1UzEBFxTwrA5HdLrvzQE/jzdy5CljQKmgXl5/zY=@vger.kernel.org X-Gm-Message-State: AOJu0Yze1jUu2FNrPMzdZqc5eiSnOQqeFg9KaUB9n4Yo1W/BMOO+pJvn nbWbqjSiktF2mMutajrnpokr13rsvkeCC404sQKKhEO0UQn1ElUajAu1 X-Gm-Gg: AfdE7cmWWsH03Ovel14wRNwQUe9PpXfonlDROSdRWUdOwXehQvQD3dhMy/ir+ub14QE CMI2/ZhTEUrPTwjXsk77BdTmVKGg9eQ+Ht08Vo+/2w+66UwdHcN8C2OMMGh8YqAut/isSPo9Vfb HJem9K7M3hLZhq3fAfuYcPu7UWd1qKZvRDi92GzROnb1h1bY2MEeEPBujqmvhx+oyJU1/vd90ic +tkfj6qWKjD4dQZ8NhBtcgLv/4ij1+Jf5++XwnYozKWmgBKLT+ZQakLtKz80JUbTZWs7RiHAxbd YXxwDTD9en3o0/Xz/oFrt9lwbvnKsz1IO4d+3zdPxDqmF8+CmyKLl8nz3ZwrF7Qq0khtqhbwHVg hb9cUNo9U1OHhZYXOLtLrSBUgD9tUSz7nVQ7C3L5vWPQQTLSsnlO70Dpcbdw0slcppd0fd0cRRk cELQPwkwkgnhAXvuD5PcqRXO9Kz77Kk8+AZqFKk85PcXDr5J5np3ZcfBS2JiTe9OoUfWtn/SMVG IAOYA1W8Isq7Y9+Xzzvau21GEdAeSwvoHIiMc+Y87T6cm0dYpiIZJ8= 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-security-module@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 > [...]