From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (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 66A1637E2E9 for ; Fri, 24 Apr 2026 22:13:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777068794; cv=none; b=WCfuFMpG/zRGScQQ8Z96AgOQX+ccPqU3madXHq5kxFSdFmE38aO0ceqlxRM25ilZW4fXh/kBBMxN/WQtmRtTMuUUIKTnth8U+KTNC2IzOqxKYYSTuawLYWgsdQAxuzHRyTW61euDkw8QglGP7QDwA3zCSjF+mS/ndMX/yEUP3sw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777068794; c=relaxed/simple; bh=edkfnYqeyMC0Qt+W6n8ze5hGF7NTNhj3oyNEAcTDdxw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NlCV6GAuGTprAeaHaec4Ha1iLdOb4lzzFBK+XeOfrj8wXJ5XKXPAUNjThjOUNqsHyAsx2N17mXCs6jS5gv1jHHKBYzoicVLu9veAiyyaWL30/5GbFxYPBd/ArhB3Bww8o2kvXrm+zDbmXYJl7iFvgOd6w14Tu1IzUqO+ld2XhVw= 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=H5m4vQCZ; arc=none smtp.client-ip=209.85.160.181 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="H5m4vQCZ" Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-506a6cf8242so60125681cf.1 for ; Fri, 24 Apr 2026 15:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1777068792; x=1777673592; 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=p1Bt8LRPmWuCECk46OUK1KhCrmrzQEbzIWvPlDI3cp4=; b=H5m4vQCZE27E+gDtn8BVCf5jLiPS6GNSYRuHd7oK/ryAnR76eU7gh4QWRI3SAXCvku xwbAjZ3hIBI5GEUgbOSGuhXCViPpczYPF9VhNc2dh89l7qQROTD8YZ3pfblRmIXAApD+ LLNyElsdRzbz0O8P7asNE1yJaILYoWrFSeatd7+ExO8xnYjLQgg2muQOyOklYWskuFkU cwfy9M7PKhf/GFqDNR2idR9iNUU//TC3BIEIHtpqSrhi/HtxH3xMTkMDNiCC7PJfnIaI RfTF+U+c9gQck78mXjxg5cQFxiXkgiK0mPHrBDKGiKFmfg+/2VAfJKkgnb8JLTc01FjS F9Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777068792; x=1777673592; 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=p1Bt8LRPmWuCECk46OUK1KhCrmrzQEbzIWvPlDI3cp4=; b=infTjG/4n6Bx1p2xuR6GkITdy3rr6l9C6z71SAbJOb4H1SIwvzPBuP3VWSayUzzl+3 QTMM7wP5/6QX9l0SRC5SAY7Z1DyctCJdIZXhj48W8XLNJ2WCuOv0D+fJ0TO494vbTh5d ssXxZb0WiQY6ZjUYrkZYgNu4NoKjje5uYKiMCl83GtH09Cn8zh5Prj5+gz2pvZvlzLaS Gp1HOAPqaRbWK/tMzrAtXY8zuc6urG/ihtEK379JnQffR7n6WrzMBcfTXGpssOjUgNPd 0lzqd2+AnqjhK+LnunV/T7+v1m6THuYKrwfp5vynqAPGjnkNQw4fRFViml0vlKuIAAZ6 F7Ag== X-Forwarded-Encrypted: i=1; AFNElJ8vBUWbvHiYDEYFI+iQwaTCAZ4Z3P4pkDFngRpn5bfJEdS553gX0boMBtkzpO1+ETswUxnZw2Iy6OMmRbw=@vger.kernel.org X-Gm-Message-State: AOJu0YyzA6R7e3Z3vcvKwkBSAGkSO28fbyHCnyR75OYE1QYJ2SMRN5bG hC+8W44oCOZ1zhQzR1zJ0hfLajubE5MbmvlkWNrISEqSbXDYyqK1qGA9L15+IrNa6GQ= X-Gm-Gg: AeBDietdq9d8+bctSghH4QT19hbo2KN6YV+PYLvh1tEfyrM0WujSc+yH+hVveES2yfe 5Td022h6CkYcx7ncStTmGtT6Ef/8pxAhC1S9tMEM8UTYXYr81NbOK88ehDJ5x2g2RTq9wklTy9R KBxbaLdfRhHX9ozgHhe0kLZ21AMQOepFUIFeNvclV5Z4D9zjm8CAMFlfAnM3+DpfBDhj5f9mAnu MEC5L35cI6Oy9qMC/3wHGER3q1GqXvK1YSNa1uEpYjuypcwMaQJRzKGPRINVquPXqVYdTX7xf+N yc2UO4TYnqvg+OwPrbi60TBaereIUAIC0JpAOj4tIo+xa0GIrKSuqvYc+MHUV71hEnbefIsGocK RTlhqkyk7Yhg0xrzhJKEhs5Z5C4LbSHND8B3spOAnCfD0fSnM4zZkJ4rAsUtllVFuCNIXS59F0r +gyEtag9FXYXhBK/KQ3g1K1iyrCxGAYMcig4+ZQqdfWAi81pxxXimA0LNvthepd8LAZT3tXH7AH ZBwVURZ4gW+OHOo X-Received: by 2002:ac8:7d15:0:b0:50f:b13e:b740 with SMTP id d75a77b69052e-50fb13eb934mr273244551cf.9.1777068792308; Fri, 24 Apr 2026 15:13:12 -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-50fc42c7fabsm78174021cf.9.2026.04.24.15.13.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Apr 2026 15:13:11 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wGOlq-00000004lHz-0nuV; Fri, 24 Apr 2026 19:13:10 -0300 Date: Fri, 24 Apr 2026 19:13:10 -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: <20260424221310.GA804026@ziepe.ca> References: <20260413164220.GP3694781@ziepe.ca> <20260413231920.GS3694781@ziepe.ca> <20260415134705.GG2577880@ziepe.ca> <20260417191749.GK2577880@ziepe.ca> <20260424143603.GB3611611@ziepe.ca> 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 Fri, Apr 24, 2026 at 04:59:30PM -0400, Paul Moore wrote: > > > > > Most LSMs will want to know who is initiating the firmware request > > > (the subject), the requested operation/opcode (the action/verb), and > > > the target of the request (the object, which in this case is likely > > > the kernel or the device). > > > > How is > > system_u:object_r:httpd_packet_t:s0 > > > > A kernel or device? > > It's not. It's one of two labels on a packet. I've cautioned you > about leaning too heavily on the secmark comparison as it falls apart > in a number of places, this is one of those places. But I want to label a packet too, you keep going back to it not being the same thing and I keep repeating that all I want to do is put labels on FWCTL packets :( > > It is a label for packet contents. I also want a label for packet contents. > > According to your explanations, my understanding is that you want a > fwctl RPC operation. That is not the same as the secmark label > assigned by an iptables/nftables rule. I view fwctl as an opaque packet based messaging subsystem. It communicates a packet to a remote CPU and returns a response packet back to the userspace. Trying to have the kernel assign fixed meaning to the content of the packets inside the kernel is contrary to the entire design of fwctl. It is like demanding the netstack parse HTTP packets as a precondition to using LSM. It makes no sense. Any LSM integration requires a labeling system that is not hard wired into the built kernel. I don't much care what it is, so long as the classification and label space are defined by userspace. You say it is not like secmark, fine, but I see a perfect mirror in secmark... > > You can take that view, it is certainly one valid way to look at it. > > > > But it is completely impractical. > > Elaborate on that, because from what I can tell that is the valid way > to look at it from a subject/verb/object perspective. We cannot have the kernel predefine verb labels. I'm completely fine with using verb if it can be dynamic and userspace can tell the kernel what the verbs labels are. This is the only reason I pointed at secmark, it shows a system that has both a user controller classifier and dynamic labels that are not fixed into the built kernel. ie it is flexible. > > > > The same way secmark cannot pre-identify all the XXX_packet_t's. > > > > > > Once again, I think there is a disconnect or misunderstanding, on a > > > SELinux system using secmark all of the packet types, e.g. > > > "XXX_packet_t's", *are* pre-defined in the SELinux policy. > > > > "Pre-defined" in a text files in user space controlled by the admin. > > That's not correct. It's kinda like saying the NIC driver sources are > simply "text files in user space controlled by the admin". That's very pedantic. I mean to the point I wonder if we are even speaking the same language. I said the labels are defined by userspace, you said no, and then explained that they are defined by userspace going through a bunch of steps: > The SELinux secmark labels are defined in the SELinux policy sources > which must be compiled and loaded into the kernel before they are > valid on a running system. Policy must be written not only to define > the secmark labels, but also to define the access control rules > which govern how those packets are handled by the system. The > iptables/nftables command lines simply assign a secmark label to a > packet; that's important, but only a small part of the total > equation. I understand all of this, I am totally fine with it. A package will install, a distribution will provide, or admin will write these things, and do all the steps to load them into the kernel. I don't see any issue with that. Hardwiring things into the built kernel is a problem that must be avoided because end users only run the kernel provided by the distribution. "recompiling the driver" is not an option that is available. Jason