From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) (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 56C512D5A19 for ; Mon, 13 Apr 2026 16:42:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776098543; cv=none; b=NR5Bk5rntNA0kdPdjtiUSdHTN18NAfwo/Lil1zbJeDT/beiiePWX/CDz3qUXC6dBCUZ1u7kQPOsTxxrOUNaQxc7SAwG/i/2xWSyizZzgGw+1TPv/onvN5lyWA5wPzaYuUDYKZwDlLSys98fkzXdNRooEInVvd0vbXqYlKBCIf0Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776098543; c=relaxed/simple; bh=G+WYrb1BBVDoPFmFwGScCNyDrJlyYOjXSYKOQwe+8ko=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MK2ADZrahT2Jf5IuyU/MN55wMKd1FXnM5Dn5gpXcSiJvsysqYEtw4jujOs+dQsNyzU/mWzJbch0QwlmZMcT5y/Jur2hleV5T2G2pJ7u+IxdIMXsTn2h/RKTL34KfZyLpNFncvYO7DNofOjYZ+McUrqTjK7nA8dbUxNQfbJoM5gQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=E2wavPRL; arc=none smtp.client-ip=209.85.160.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="E2wavPRL" Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-50d59d249fbso48812031cf.0 for ; Mon, 13 Apr 2026 09:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1776098541; x=1776703341; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=jUiNyilK1I2myoXjgAEGP+spYezLcxgAYqqWit3D6Xk=; b=E2wavPRL5AmyZgB0g/U0hP95w+LHR0CODATHBR29H0d0H1ZgOljvH8X8HvEY3mXt5a YlnadNIjO+fQDkEchqiV9cHty+PdpSlVJ0f4C9c9V84ivaVyIHJVhYYiHOq6kNaLYdCy RS6GxQgi6h43fT46Qsn7sAG84AXG/H7JJnfCpu1q5aml+RfpX8WXFWxo1JtI9p6txnZa PdoMOOEpmP/FwRH5QMlO4oHklEDiJJ+80RerI/KkkD87VkTNCjDn28FG8unDsu3pExSz eHYOVnR1ITXBzK/9kIafEqDD5d9qV0i6BSWJek3gMW5q99EoszY3lceECT/YF1kRVaZz 9cvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776098541; x=1776703341; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jUiNyilK1I2myoXjgAEGP+spYezLcxgAYqqWit3D6Xk=; b=EThD+kN8mvU+qKKUMSCr7q3dDd9rQ1GhNDKDHIoU5gsSI6APcC6r/bXtCVlYvy7iFe Tjn+DuLTPsRQKnSORYzevYmZmRuUFTOfju0OXozmzsUrha7qw+f7BUuATgvtc5uCT77h q1eeDDEuDPJYC5dyRHLwvA3b6aajTgfxlPgtwH0o7h1nDOdhVFoTJycWSnU+E2sit8qy Knul2U3iz5+o8xrP5PloyJ5KLw5RQHLbLybrc0MRQT2u+ubVnU9sNyk5VYJfx6CP+ppC 2pabF9gOwod0j+gvJ4obuRzJ88/j/taMHHmu2QS12iFZeYSn5uZrubMO8UAljpTb3hr6 Q5MA== X-Forwarded-Encrypted: i=1; AFNElJ/ZeDGV1zTEiSj9h/AjFCfzTiymDiEHrCcKul9iVYC4ZBM8l0ryhpr1az88iLHeThuoMDRGRcq8RZ8170JjEWc=@vger.kernel.org X-Gm-Message-State: AOJu0Ywg+9O9PCpLJvy9H0n8LTs20N+2UEHKwPnx7zJk24cSyyCzhYeb 6MCMS/i2zFVIwXM6ntVXl5yu6nDYHzeNF9LHYP3CEaToJWGUucAUzvpYa92J1HqXsCc= X-Gm-Gg: AeBDiet5hooBvIe4rZjzdhAeThg/ZrBs9gkkjKX5AWRtgRVB7/2Hi0HY9fHIYdr3Sow DG6JxZAEFXNUGGLsA+n7KrKU6lF+GSkxP2XI+x2IxhXfhSCjufT5TBJfqRNnrrTjABYgtHL18dm KycFWxU5BrC6w3Y6PCHZLQ3aF+9G+qt0XUHss6r9QVkKj1giXQ3iUjGkdQHX5kHyQeI3TdGvEer GxFZZi05zUGnCDkRWn6qi72LzqvQU9QTfKUSSyW4MBRRrHJcYH2dJxnGvSYGwPB11Hd7Z/O9WJI yEmI25W9iAeLhawjLbdUc/rlxvlzsqRrtxAMnsdu1xaZcvydiiTBT2WR98dnm9Q9nsLbJrTBx0I r87z92cL0WaYsOqrC6Br/WoDzKwUV1yz5I8MgsTnGuU1fn2IC2ALUmyUnYm3E/wJ+wpWKYXjyON LEdirM5jIIqfsrQG1VNwOftN/X61U2GXQuUMeZ/6Tz07e84rzP3Sij1ZGn5uHRul+bqfXyIjd2i fg3/w== X-Received: by 2002:ac8:5ac8:0:b0:509:120d:4311 with SMTP id d75a77b69052e-50dd5c02761mr211953761cf.60.1776098541243; Mon, 13 Apr 2026 09:42:21 -0700 (PDT) Received: from ziepe.ca (crbknf0213w-47-54-130-67.pppoe-dynamic.high-speed.nl.bellaliant.net. [47.54.130.67]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-50de6bc04e0sm60997991cf.19.2026.04.13.09.42.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Apr 2026 09:42:20 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wCKMe-00000005Zr4-10vb; Mon, 13 Apr 2026 13:42:20 -0300 Date: Mon, 13 Apr 2026 13:42:20 -0300 From: Jason Gunthorpe To: Paul Moore Cc: Leon Romanovsky , Roberto Sassu , KP Singh , Matt Bobrowski , Alexei Starovoitov , Daniel Borkmann , John Fastabend , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , Stanislav Fomichev , Hao Luo , Jiri Olsa , Shuah Khan , Saeed Mahameed , Itay Avraham , Dave Jiang , Jonathan Cameron , bpf@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-rdma@vger.kernel.org, Chiara Meiohas , Maher Sanalla , linux-security-module@vger.kernel.org Subject: Re: [PATCH v2 0/4] Firmware LSM hook Message-ID: <20260413164220.GP3694781@ziepe.ca> References: <20260331-fw-lsm-hook-v2-0-78504703df1f@nvidia.com> <20260409121230.GA720371@unreal> <2dd138a2ae87f90c55dbc3178d9c798294fd4450.camel@huaweicloud.com> <20260409124553.GB720371@unreal> <20260412090006.GA21470@unreal> Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sun, Apr 12, 2026 at 09:38:35PM -0400, Paul Moore wrote: > > We are not limited to LSM solution, the goal is to intercept commands > > which are submitted to the FW and "security" bucket sounded right to us. > > Yes, it does sound "security relevant", but without a well defined > interface/format it is going to be difficult to write a generic LSM to > have any level of granularity beyond a basic "load firmware" > permission. I think to step back a bit, what this is trying to achieve is very similar to the iptables fwmark/secmark scheme. secmark allows the user to specify programmable rules via iptables which results in each packet being tagged with a SELinux context and then the userspace policy can consume that and make security decision based on that. Google is showing me examples of this to permit only certain processes to use certain network addresses. So this is exactly the same high level idea. The transport of the packet is different (firwmare cmd vs network) but otherwise it is all the same basic problem. We need a user programmable classifier like iptables. Once classified we want this to work with more than SELinux only, we have a particular interest in the eBPF LSM. In any case the userspace should be able to specify the security policy that applies to the kernel classified data. Following the fwmark example, if there was some programmable in-kernel function to convert the cmd into a SELinux label would we be able to enable SELinux following the SECMARK design? Would there be an objection if that in-kernel function was using a system-wide eBPF uploaded with some fwctl uAPI? Finally, would there be an objection to enabling the same function in eBPF by feeding it the entire command and have it classify and make a security decision in a single eBPF program? Is there some other way to enable eBPF? I see eBPF doesn't interwork with SECMARK today so there isn't a ready example? Jason