From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) (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 0D14D71 for ; Wed, 12 May 2021 21:56:19 +0000 (UTC) Received: by mail-pg1-f177.google.com with SMTP id t193so6786732pgb.4 for ; Wed, 12 May 2021 14:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=hBIs9zoBCXixFNxxI1Y+QgjxyyGXOI7pXer0FPPUGm0=; b=h89iCqDDuXOH0Vk/EDXInZ940Xzs4Le9rckXb8+3vJOmj6dTacxaNPcSLCegTrOdPY n/RRF55MyoEnnk4FE2zPC3Vgvy5Vu81rSVKuf+1SCruex/PQseABn2OyfW034Zb/divX a6XhRDaw3OAQ0UFEObBl1ZgXy6I40MTOh2snwYyxQ2U/xlM14eBI/3qPZu3Djt2+zTWU cN8LIg8YRa8g29WSkLKVk0u6z9CUP8pOE9/AaS9/kkzQW/RjlN2qquZFLUWAQSLvkAn2 HYtEkb12kZhbIjOtBpQq3kaGeZjooaW+uYeFTnTLfzj/q/cMc+ic7sm2ETM+9aF8gfiG ABwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=hBIs9zoBCXixFNxxI1Y+QgjxyyGXOI7pXer0FPPUGm0=; b=OYCYgXvhn59PbYCRfnzOTZylzeiGXkCqEwQSquuW4/75YLCVgW+Dbex1wSe/tKDhFE H/TjWoOEZlCpyF65tUHZWdUyn3ZR84+qSyQRdsRKSWK4SfjgbEiu48mDhiFFuzFXM3nS jNCygm7Qn5Kc6/1OED+SW/U3tPz2S7iy0oyimG8PXhU817nR5knGuQB/MBT/5J/k22r3 GFXvlcoH+xdK/dliu3EjPZFmE6njvJRTu7HQQCIDFmjyNU/uEn1HNKsBBpL/AlXr29qa Y2dXGcE1O3EiQuhDyby2wffj9UFGkTpUPt62hpaiWnC8ANOPHGrcEcqA3wAJM/4XaMtn pE3g== X-Gm-Message-State: AOAM532dB7VLuy38tMxIt/XDLklHyDginWeaOyJplqRGlVtPTTYIfN0K sBmEKGUxzRVT+LO8okiQn24= X-Google-Smtp-Source: ABdhPJzzHHVxOgUL5O+vv5ub4DxlXrQ8ixk7FCr/isi0NgKkbD5mfmURGn7iMDGC1xGCebwLWPPt0w== X-Received: by 2002:a05:6a00:7d4:b029:28e:2b3:58bf with SMTP id n20-20020a056a0007d4b029028e02b358bfmr36865687pfu.77.1620856579425; Wed, 12 May 2021 14:56:19 -0700 (PDT) Received: from ast-mbp.dhcp.thefacebook.com ([2620:10d:c090:400::5:c6f4]) by smtp.gmail.com with ESMTPSA id 15sm567382pjf.57.2021.05.12.14.56.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 May 2021 14:56:18 -0700 (PDT) Date: Wed, 12 May 2021 14:56:13 -0700 From: Alexei Starovoitov To: YiFei Zhu Cc: containers@lists.linux.dev, bpf , YiFei Zhu , LSM List , Alexei Starovoitov , Andrea Arcangeli , Andy Lutomirski , Austin Kuo , Claudio Canella , Daniel Borkmann , Daniel Gruss , Dimitrios Skarlatos , Giuseppe Scrivano , Hubertus Franke , Jann Horn , Jinghao Jia , Josep Torrellas , Kees Cook , Sargun Dhillon , Tianyin Xu , Tobin Feldman-Fitzthum , Tom Hromatka , Will Drewry Subject: Re: [RFC PATCH bpf-next seccomp 12/12] seccomp-ebpf: support task storage from BPF-LSM, defaulting to group leader Message-ID: <20210512215613.jtvvyu7mahfkztdf@ast-mbp.dhcp.thefacebook.com> References: <20210511015814.5sr37y4ogf5cr7c5@ast-mbp.dhcp.thefacebook.com> X-Mailing-List: containers@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, May 11, 2021 at 12:44:46AM -0500, YiFei Zhu wrote: > On Mon, May 10, 2021 at 8:58 PM Alexei Starovoitov > wrote: > > > > On Mon, May 10, 2021 at 12:22:49PM -0500, YiFei Zhu wrote: > > > + > > > +BPF_CALL_4(bpf_task_storage_get_default_leader, struct bpf_map *, map, > > > + struct task_struct *, task, void *, value, u64, flags) > > > +{ > > > + if (!task) > > > + task = current->group_leader; > > > > Did you actually need it to be group_leader or current is enough? > > If so loading BTF is not necessary. > > I think if task_storage were to be used to apply a policy onto a set > of tasks, there are probably more use cases to perform the state > transitions across an entire process than state transitions across a > single thread. Though, since seccomp only applies to the process tree > a lot of use cases of a per-process storage would be covered by a > global datasec too. > > > You could have exposed it bpf_get_current_task_btf() and passed its > > return value into bpf_task_storage_get. > > > > On the other side loading BTF can be relaxed to unpriv, > > but doing current->group_leader deref will make it priv only anyway. > > Yeah, that deref is what I was concerned about. It seems that if I > expose BTF structs to a prog type it gains the ability to deref it, > and I definitely don't want unpriv reading task_structs. Though yeah > we could potentially change the verifier to prohibit PTR_TO_BTF_ID > deref and any pointer arithmetic on it... > > How about, we expose bpf_get_current_task_btf to unpriv, prohibit > unpriv deref and pointer arithmetic, and have NULL be > current->group_leader? This way, unpriv has access to both per-thread > and per-process. NULL to mean current->group_leader is too specific and not extensible. I'd rather add another bpf_get_current_task_btf-like helper that returns parent or group_leader depending on flags. For now I wouldn't even do that. As you said hashmap with key=pid will work fine. task_local_storage is a performance optimization. I'd focus on landing the key bits before optimizing.