From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) (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 0C1C739F180 for ; Fri, 17 Apr 2026 14:09:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776434958; cv=none; b=Ze2/hLfH2W0+pGgH0csled7FY2NNWfJHU03b4WPLnUDr2rKznca3FCT8s1AA3pFsjgtO3tTH9R9AjMHlTf5nnneJSANECsGo9vuMfDToPD80WH322Gi6237IDyq54UCQeMpWbnfvW0nrRm6+0XnpaYKGX08apXQh3FIHj2Dzp2I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776434958; c=relaxed/simple; bh=hDINANr2lOJehHhWpqIs2vMJtnPVOcOP7GCyF4OaGKs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=iojJQgvG+LWo0Vo0n2bI2FxfA3M2BcOpolmWZF9MAaCTbFaMEq32OiK1kKERe3qzOoVzx/RdfDhVKgSHIV8iJcCaPQJDSsSBob/YJAimoENU4ETUQlFiwk8XnypOQ3FsmEoqXDRwsriliR9oKBvMkhMOnzosiRI2wgcPPW4gYg4= 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=EYAGvC4j; arc=none smtp.client-ip=209.85.128.169 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="EYAGvC4j" Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-79ee5037d44so10516957b3.0 for ; Fri, 17 Apr 2026 07:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776434956; x=1777039756; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=RYPsDqc9ytAePTJ20Ne3zqUb8fDAuukERSfY3WHaxOA=; b=EYAGvC4j2gc320KPtDy7GR4LSTuEqbYEccwn4F+MWD96oNGpeHEkZ6lCUw/W98cl1X 6HhoBqs2HxaU44ksYDWZST0OD4S8irBCn352sZ7H8T6yr8liRImsm5/6LXumUVAlwstZ Wj24xX9CpYIS7ZREB3sgOMPOOxAS+YnOBOaFpPDURj4KzlHuVVABaScbVdEY6L1uj+US qzmCLT15jRJL1a7yYidAtBmpqDG6mDfaO+/13J8jtzIvy7dNbi3+m5e0Yc9YMvEbGNVj i3TvuzuBbIQzuuMl12+5qSKpztNRBw02tgURv/u9TL7YcSQZmDOzLEJ+aMb0BMXmlAQT C9YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776434956; x=1777039756; h=in-reply-to:content-transfer-encoding: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=RYPsDqc9ytAePTJ20Ne3zqUb8fDAuukERSfY3WHaxOA=; b=d6oeNfH5nYm+Ea6laSTFAAJL5D2aOO63M4yj3AeI1D2SEMtcP4UJIyMrVmd0GCS4Sl AK3OhMrqFewZf2hx2ia2p8F/Oaqv47oja31BFuqs7SX2uGXwZiDHUTW0aJ4PBTbVd3CA oj9KdaWj0D/vzxLNI1n3jBcOgsJot/IpteIIMzDY5qV6O4gR51rGHBGnDtnwFoOkAlbL op9/91GimP73QOVqUDrUlfAmg3uOKEd/BxGAwgc/qq9P1npFmaG6VlPYnfKxVCiIgRxL wzPzcq1r8VWtLFpasbX4Q4jppmeG7EQsX3bcI/tGe+irf1N3CvL841iuNp0rJ6778Ffn PrXQ== X-Forwarded-Encrypted: i=1; AFNElJ/VdK+yakt9+E+yE1UZAi9opfDIbPExTDupcTE1PH0wyPeJhvWPqRdyPBk1jHus9HOVW/fTNaucIsQOOAc=@vger.kernel.org X-Gm-Message-State: AOJu0Ywjw0qkcKkxVuXOBxLmDWda83IhPgv9gljm5sMzaFmDfamwuJGa I6mCCKO1h/h2bRNw5Dke9ViY3cOLP8UBex1M8gvm7dwVGevV53B+1RHL X-Gm-Gg: AeBDieuy38XW4cG1JxHtgRL2cNqwXcpA1/HYzmPHJvH93ZLzO9mOG1i/qB+Dfiib6Ca CVpzVSDwPJ0xrZhVOcj8vYz8L4NOEsjERpWQ8jJxXVHyNm4O/zEywgXdhX85HAHRpu37rXyv7TH XvUHtO5AceYhsJk6shhViOeKAe4hMV9whVYgLR5MfLlh34gej/0+1ShyFtGJmOnD0iifNJ++uut F7m3aToDoZP1UT5/yzng1Ph0/ndcp280Aog2cm09Enr9DZTWoSVByoAQBLYQhmgnwIxmKj5OcvL Nr9+XWzx0T+HWFASEj9XBy29KueU472Ve7wP3PLXHtPFMdKDT8Zeyrh57AUZRkx1X//kt+G5rPD YJTVxdwjhYNh/e/usoAfyA8lYYu5bLmjJVklV7hbzQhfKZ6ZP5yKNeTRs9ldv4yOnO0+BnX8i4I SO6DuLngVeH5b0V50x3Mh//jd+0lBqM8E4pZXcEshit7VCDhlT/coDCvsYOCGfqmucGkXK X-Received: by 2002:a05:690c:f05:b0:7ba:a726:58ad with SMTP id 00721157ae682-7baa7266dc8mr830267b3.26.1776434956044; Fri, 17 Apr 2026 07:09:16 -0700 (PDT) Received: from suesslenovo ([129.222.87.6]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7b9ee99bb32sm6550297b3.30.2026.04.17.07.09.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Apr 2026 07:09:15 -0700 (PDT) Date: Fri, 17 Apr 2026 10:09:13 -0400 From: Justin Suess To: Song Liu Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, kpsingh@kernel.org, paul@paul-moore.com, mic@digikod.net, viro@zeniv.linux.org.uk, brauner@kernel.org, kees@kernel.org, gnoack@google.com, jack@suse.cz, jmorris@namei.org, serge@hallyn.com, yonghong.song@linux.dev, martin.lau@linux.dev, m@maowtm.org, eddyz87@gmail.com, john.fastabend@gmail.com, sdf@fomichev.me, skhan@linuxfoundation.org, bpf@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [RFC PATCH 08/20] bpf: Add Landlock ruleset map type Message-ID: References: <20260407200157.3874806-1-utilityemal77@gmail.com> <20260407200157.3874806-9-utilityemal77@gmail.com> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Apr 16, 2026 at 04:47:40PM -0700, Song Liu wrote: > On Thu, Apr 16, 2026 at 2:53 PM Justin Suess wrote: > [...] > > I don't think we can pass the FD number via a map, since the FD is > > process specific. And it needs to be done in a way where we can lookup > > the specific ruleset the FD points to safely. > > > > So we'd need some other way to load the ruleset from a file descriptor, > > either through a new userspace side BPF call or similar mechanism. > > > > Is there some other common pattern for FDs --> kptr I can follow? > > I didn't find an exact example like this. There must be a way to achieve > this. In the worst case, we can add a kfunc for this. > I think new kfunc is a doable approach. I could make a kfunc taking a struct *task_struct and an FD that looks up a landlock ruleset within a given task that returns a trusted kptr. Something like: struct bpf_landlock_ruleset* bpf_landlock_get_ruleset_from_fd(struct task_struct* task, int fd) And tagging it with KF_ACQUIRE + KF_RET_NULL. Then keep the existing kfunc for putting the ruleset and enforcing it on a struct linux_binprm. The BPF program would need to get a reference to a task struct of the program creating the rulesets with bpf_task_from_pid for instance. Then they could use the task_struct with another plain integer map to store FD numbers and then use the rulesets or store them in a map of __kptr objects for later usage. Would this be more acceptable? > > Basically the pattern I need is userspace must create the file > > descriptor, BPF converts that FD into a refcounted kernel object, and > > even if userspace closes the FD BPF needs to hold a reference on the > > underlying ruleset structure. > > > > (In this patch this was accomplished through the map_ops) > > > > Let me know what you think Song. I do understand the benefit of having a > > __kptr instead, the refcounting is all there, and it would allow storing > > rulesets in multiple map types. (and one less map type to maintain). > > A new type of map for each FD referenced kernel type is non-starter. > It is impossible to add UAPI for a specific use case. > You've convinced me. I could see a lot of problems if everyone wanting to add their specialized maps, it would be difficult to maintain. It's probably best to keep the specialized map types to core kernel interfaces only that are unlikely to change. > Thanks, > Song > > > Mickaël, do you have any thoughts on this? I have v2 basically ready, > > although it uses the BPF_MAP_TYPE_LANDLOCK_RULESET it changes a lot on > > the Landlock side.