Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2929933pxa; Tue, 25 Aug 2020 07:13:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxFmt0EcNe6RvBE4vDd6UNxzGi5vYaX+54sDxABrWvbalaFkurjLJNf/o/AvJIo38NxLDqw X-Received: by 2002:a05:6402:1299:: with SMTP id w25mr10604035edv.349.1598364825197; Tue, 25 Aug 2020 07:13:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598364825; cv=none; d=google.com; s=arc-20160816; b=ZdmdxwuR1L+gn6DIyUKDHvRDo3waTH8OsS61Gn8no107QCdEeMYeoRS3QzzLuLxHNN K/JvOeH7ivyMZ0jI1AWrfRwnD3FJda3sfSPNSEGL77JcXuuT9eOd62YuP6wbwveP/mJY 4CajX+HyAeRFqcuF2tnCqO/LARmnATFRnBH0DmZMysIHXZmqWSq2s1ac22CQj39VOU8w yIVNTVR0KPQgZJDhSkbT9Z8JZ8UXp4FVCjt/egTWdZ0D+8QaGPbKKO3VXhKyfexIcE2Y cXMPXAxvbnTChC3BdhuG4MkWrPTgmvuVVGinOX+TcMjAzZQeW8Yzpd19Knv5L5XCNmxw UW3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=KBFZttGfteQiG/F6m1JwLuRmWwiLtOn1NGTSQxlL0R8=; b=v+c54BRI2a/OSSPLtlQD8sK47pq8Jv2B7plAVTeTmv5SzALHS4otnYJV7Y1xChlnHC ZFfUtM0Z28u7vCXbZmfVx420mTTuNZE/p7R4DlsMemCJkXf+XDQ606yZt8QcRsfqGo/S XIgTw729yQS9aa1iEEIxWxHX/FxUWznguy7kdvNARpGvfQfGixmDv38n2lOelGnQH576 vtbNrEOWtLcCMkCiV2vN+e7XwMHsELsDuQcM1fM2784+U9jMiAW1zSHxpVrAsFBuJ1ep AoD2vn5hsG8h1cBfgvgV7t/fs83XF6qqcnW7YJgTE5Wkjx2tFgmEuv5Eefu7RnGm9v8L IhCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=jLnUNSiR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w6si8696564ejb.150.2020.08.25.07.13.22; Tue, 25 Aug 2020 07:13:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=jLnUNSiR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726149AbgHYOKe (ORCPT + 99 others); Tue, 25 Aug 2020 10:10:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58858 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726090AbgHYOK3 (ORCPT ); Tue, 25 Aug 2020 10:10:29 -0400 Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [IPv6:2a00:1450:4864:20::642]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B5A9C061756 for ; Tue, 25 Aug 2020 07:10:29 -0700 (PDT) Received: by mail-ej1-x642.google.com with SMTP id j25so7560069ejk.9 for ; Tue, 25 Aug 2020 07:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KBFZttGfteQiG/F6m1JwLuRmWwiLtOn1NGTSQxlL0R8=; b=jLnUNSiRkVPmazSgOpBGGkBIFbQgn3SubSGBtfI3udYnQF9YnvGbPLGw/Bg6gNQG51 2HwfjMpqoLNbtQmB1chriB3Xc8+RWCRJunAgmt/FWga/wQK351I3xuMzc9ungM1zD6Tt VRfW5hS51m8ANRTTusv4bV+aPInEeBnWiAcyo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KBFZttGfteQiG/F6m1JwLuRmWwiLtOn1NGTSQxlL0R8=; b=YJ/Tskzc4eIf5eQdqUUcrKf+Bask1JTqRxysldLqUfS+3TjSyDFpZNq9/sKqUlTbzW ESI6kyTQG9UWaaifu+oGlaOb83j/3TD7i98eZrmM7aEAaU6XvrLXaTtYyvbEXKapcibs 61khgIkOTWkt/lx/hZAuizMCLEl4JMGYmWETL/9TZVtxPaaywSLLWGftjLRvzPRqAqpN zaSAaYxcqXH2EJcXgO3eevQ1SsEz5ouyOoG+/Ak9ASX01Ejmh+ehNpD6f5pqiQ8stUri vs2z6Vrhy/jIvyEZ+fios6+86j0uPcOp4GixtFmmdHQnMoi90GBJcRABT6zJ10/ZElrN Xrrg== X-Gm-Message-State: AOAM533w8flLq4zfzN5D4Heae5cwvM7otV1SJOvDw+5jqfA6/fiDCFrh OvLe2QhJmq3ZjY7CKltPvBbTsA== X-Received: by 2002:a17:906:553:: with SMTP id k19mr11039230eja.401.1598364627531; Tue, 25 Aug 2020 07:10:27 -0700 (PDT) Received: from [192.168.2.66] ([81.6.44.51]) by smtp.gmail.com with ESMTPSA id dj16sm7658961edb.5.2020.08.25.07.10.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Aug 2020 07:10:27 -0700 (PDT) Subject: Re: [PATCH bpf-next v9 5/7] bpf: Implement bpf_local_storage for inodes To: Martin KaFai Lau Cc: linux-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-security-module@vger.kernel.org, Alexei Starovoitov , Daniel Borkmann , Paul Turner , Jann Horn , Florent Revest References: <20200823165612.404892-1-kpsingh@chromium.org> <20200823165612.404892-6-kpsingh@chromium.org> <20200825005249.tu4c54fg36jt3rh4@kafai-mbp.dhcp.thefacebook.com> From: KP Singh Message-ID: <8d188285-96f5-3b17-126f-5e842702e339@chromium.org> Date: Tue, 25 Aug 2020 16:10:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200825005249.tu4c54fg36jt3rh4@kafai-mbp.dhcp.thefacebook.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/25/20 2:52 AM, Martin KaFai Lau wrote: > On Sun, Aug 23, 2020 at 06:56:10PM +0200, KP Singh wrote: >> From: KP Singh >> >> Similar to bpf_local_storage for sockets, add local storage for inodes. >> The life-cycle of storage is managed with the life-cycle of the inode. >> i.e. the storage is destroyed along with the owning inode. >> >> The BPF LSM allocates an __rcu pointer to the bpf_local_storage in the >> security blob which are now stackable and can co-exist with other LSMs. >> > [ ... ] > >> diff --git a/kernel/bpf/bpf_inode_storage.c b/kernel/bpf/bpf_inode_storage.c >> new file mode 100644 >> index 000000000000..b0b283c224c1 >> --- /dev/null >> +++ b/kernel/bpf/bpf_inode_storage.c [...] >> + >> +DEFINE_BPF_STORAGE_CACHE(inode_cache); >> + >> +static struct bpf_local_storage __rcu ** >> +inode_storage_ptr(void *owner) >> +{ >> + struct inode *inode = owner; >> + struct bpf_storage_blob *bsb; >> + >> + bsb = bpf_inode(inode); >> + if (!bsb) >> + return NULL; > just noticed this one. NULL could be returned here. When will it happen? This can happen if CONFIG_BPF_LSM is enabled but "bpf" is not in the list of active LSMs. > >> + return &bsb->storage; >> +} >> + >> +static struct bpf_local_storage_data *inode_storage_lookup(struct inode *inode, >> + struct bpf_map *map, >> + bool cacheit_lockit) >> +{ [...] > path first before calling the bpf_local_storage_update() since > this case is specific to inode local storage. > > Same for the other bpf_local_storage_update() cases. If you're okay with this I can send a new series with the following updates. diff --git a/kernel/bpf/bpf_inode_storage.c b/kernel/bpf/bpf_inode_storage.c index b0b283c224c1..74546cee814d 100644 --- a/kernel/bpf/bpf_inode_storage.c +++ b/kernel/bpf/bpf_inode_storage.c @@ -125,7 +125,7 @@ static int bpf_fd_inode_storage_update_elem(struct bpf_map *map, void *key, fd = *(int *)key; f = fget_raw(fd); - if (!f) + if (!f || !inode_storage_ptr(f->f_inode)) return -EBADF; sdata = bpf_local_storage_update(f->f_inode, @@ -171,6 +171,14 @@ BPF_CALL_4(bpf_inode_storage_get, struct bpf_map *, map, struct inode *, inode, if (flags & ~(BPF_LOCAL_STORAGE_GET_F_CREATE)) return (unsigned long)NULL; + /* explicitly check that the inode_storage_ptr is not + * NULL as inode_storage_lookup returns NULL in this case and + * and bpf_local_storage_update expects the owner to have a + * valid storage pointer. + */ + if (!inode_storage_ptr(inode)) + return (unsigned long)NULL; + sdata = inode_storage_lookup(inode, map, true); if (sdata) return (unsigned long)sdata->data; > >> + (struct bpf_local_storage_map *)map, >> + value, map_flags); >> + fput(f); >> + return PTR_ERR_OR_ZERO(sdata); >> +} >> + > [...] >> + return (unsigned long)NULL; >> +} >> + > >> diff --git a/security/bpf/hooks.c b/security/bpf/hooks.c >> index 32d32d485451..35f9b19259e5 100644 >> --- a/security/bpf/hooks.c >> +++ b/security/bpf/hooks.c >> @@ -3,6 +3,7 @@ >> /* >> * Copyright (C) 2020 Google LLC. >> */ >> +#include > Is it needed? No. Removed. Thanks! > >> #include >> #include >> >> @@ -11,6 +12,7 @@ static struct security_hook_list bpf_lsm_hooks[] __lsm_ro_after_init = { >> LSM_HOOK_INIT(NAME, bpf_lsm_##NAME), [...] >> + .blobs = &bpf_lsm_blob_sizes >> };