From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) (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 58945307AC7 for ; Mon, 13 Apr 2026 16:42:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776098543; cv=none; b=dcVd2PNs8Fy4dsFnXASn8OyZc4+BJtpibPZmwJwA/lVzKrEvO0dyobFscGazY+OJsJVO6AZ2e6gaGeSng3aJD3GneqZ8UFrfwBRXvinSsHS+0r76Jrp4FbrZoRXAxYkAhQ2B+RMn24kli+XprwebtFVL9PHMIzZZeAMeMExeY6s= 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.180 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-f180.google.com with SMTP id d75a77b69052e-50b2b289925so38512321cf.2 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=RsRohw/S+yukWR+FLWzeGwOd6wDwJ6huEOCc19iTG6hzt0ProZ/jZqJmEZXVsptsAp wMjpqbA6Iba3bzfkAa1eN+pVY49uHDQu+EYaN3+qKFq/CfdrefFXcWIqu9LDjgSZhP4I /zp4apw7wEsMbfCxsaFMDcRLEtNmK1iwOsbxdqMiiytqYyIUPtIjDbi5+QkyXOdL8Hz6 vAjXzoSAjvq88LruaMFo2T86smmCfFS7ATbPw5hSKw8AR4tI1txQYGPppj2ehT7hm51y h8HCQwdzxwWQ8H9SZCmbH1tZoy7BT/zyXyBtZfJHPHedHEMK2Nck3bRisRva+Qbg3fKf LeOQ== X-Forwarded-Encrypted: i=1; AFNElJ+6R9pPDG/rrsB45HB0YZ8OBBxMy1u0L0ST45STtwYjZ9+1EoiDxndFX7zfPPqGQ+c3vbwBjJ8xAdnards=@vger.kernel.org X-Gm-Message-State: AOJu0YwDJeOB/p+MQhU96FWHRQhR2d1CAXFh4LGWtsUjsCZI7PSFWuLg ICd31F2dhImrIxLtSWM3bAz17HNRaD6Ji0sEka/E8cs9Jj+qS7Ul2lbsD5W9RJTbWys= X-Gm-Gg: AeBDietwuMsiQ19CtlWoUBpVsUvg60F4gmtTEFg8CKl7l4xBQ+wR/VR0Sh+xXC/QXmw kx5dTa4fenBpgquUuzRP/eOA5y4I9/UEXBllLLkPcuIf+saY0j2qvN2nvS/WiD2RHbOQntre6wa MdgfHnc3v2VLxKO0ytBQoZqRjmbHPDEcn30zQ/X8CNBS8A9mbxoANjTWqCaPd9FDKmvm1KGX4bn lKl+Hc5uzVQPDeKnSpNtI0z/FH4yoDcWYwjUOfP7bMMHjlHw/1JfUxIDBQal7zJlvJjdaYyWNiz +gpJBwMieL1CI7QuAcODkw5eUQVRWsOhaTgiA3+XL4U+gGec4ayxf/9VunmF+CyeSXcWwTGVEUS zCimEOt728r2jCFpeNZYYD6hVymNTBZ37O8b2vpabqEKZsJyNYNohYOkQC1hJbSya1Rb5v1DUZd ZKM8NARrlTJDytEl0ohSvcojJz/PFcuL2JN3JRUNq5GxFz6RFvA0sKRwl4fRv0ca709vjyUeGPU gyohA== 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-kernel@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