All of lore.kernel.org
 help / color / mirror / Atom feed
From: KP Singh <kpsingh@chromium.org>
To: KP Singh <kpsingh@chromium.org>
Cc: Martin KaFai Lau <kafai@fb.com>,
	linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Paul Turner <pjt@google.com>, Jann Horn <jannh@google.com>,
	Florent Revest <revest@chromium.org>
Subject: Re: [PATCH bpf-next v4 2/4] bpf: Implement bpf_local_storage for inodes
Date: Tue, 21 Jul 2020 00:44:11 +0200	[thread overview]
Message-ID: <20200720224411.GA1873800@google.com> (raw)
In-Reply-To: <20200715225911.GA1194150@google.com>

On 16-Jul 00:59, KP Singh wrote:
> On 15-Jul 14:57, Martin KaFai Lau wrote:
> > On Thu, Jul 09, 2020 at 12:12:37PM +0200, KP Singh wrote:
> > > From: KP Singh <kpsingh@google.com>
> > > 
> > > 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.
> > > 
> > > Signed-off-by: KP Singh <kpsingh@google.com>
> > 
> > [ ... ]
> > 
> > 
> > > +static void *bpf_inode_storage_lookup_elem(struct bpf_map *map, void *key)
> > > +{
> > > +	struct bpf_local_storage_data *sdata;
> > > +	struct inode *inode;
> > > +	int err = -EINVAL;
> > > +
> > > +	if (key) {
> > > +		inode = *(struct inode **)(key);
> > The bpf_inode_storage_lookup_elem() here and the (update|delete)_elem() below
> > are called from the userspace syscall.  How the userspace may provide this key?
> 
> I realized this when I replied about the _fd_ name in the sk helpers.
> I am going to mark them as unsupported for now for inodes.
> 
> We could, probably and separately, use a combination of the device
> and inode number as a key from userspace.

I actually implemented these as:

static int bpf_fd_inode_storage_delete_elem(struct bpf_map *map, void *key)
{
	struct file *f;
	int fd;

	fd = *(int *)key;
	f = fcheck(fd);
	if (!f)
		return -EINVAL;

	return inode_storage_delete(f->f_inode, map);
}

This keeps it similar to sk_storage and the userspace can just pass an
fd.

- KP

> 
> - KP
> 
> > 
> > > +		sdata = inode_storage_lookup(inode, map, true);
> > > +		return sdata ? sdata->data : NULL;
> > > +	}
> > > +
> > > +	return ERR_PTR(err);
> > > +}
> > > +
> > > +static int bpf_inode_storage_update_elem(struct bpf_map *map, void *key,
> > > +					 void *value, u64 map_flags)
> > > +{
> > > +	struct bpf_local_storage_data *sdata;
> > > +	struct inode *inode;
> > > +	int err = -EINVAL;
> > > +
> > > +	if (key) {
> > > +		inode = *(struct inode **)(key);
> > > +		sdata = map->ops->map_local_storage_update(inode, map, value,
> > > +							   map_flags);
> > > +		return PTR_ERR_OR_ZERO(sdata);
> > > +	}
> > > +	return err;
> > > +}
> > > +
> > > +static int inode_storage_delete(struct inode *inode, struct bpf_map *map)
> > > +{
> > > +	struct bpf_local_storage_data *sdata;
> > > +
> > > +	sdata = inode_storage_lookup(inode, map, false);
> > > +	if (!sdata)
> > > +		return -ENOENT;
> > > +
> > > +	bpf_selem_unlink_map_elem(SELEM(sdata));
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +static int bpf_inode_storage_delete_elem(struct bpf_map *map, void *key)
> > > +{
> > > +	struct inode *inode;
> > > +	int err = -EINVAL;
> > > +
> > > +	if (key) {
> > > +		inode = *(struct inode **)(key);
> > > +		err = inode_storage_delete(inode, map);
> > > +	}
> > > +
> > > +	return err;
> > > +}
> > > +
> > 
> > [ ... ]
> > 
> > > +static int inode_storage_map_btf_id;
> > > +const struct bpf_map_ops inode_storage_map_ops = {
> > > +	.map_alloc_check = bpf_local_storage_map_alloc_check,
> > > +	.map_alloc = inode_storage_map_alloc,
> > > +	.map_free = inode_storage_map_free,
> > > +	.map_get_next_key = notsupp_get_next_key,
> > > +	.map_lookup_elem = bpf_inode_storage_lookup_elem,
> > > +	.map_update_elem = bpf_inode_storage_update_elem,
> > > +	.map_delete_elem = bpf_inode_storage_delete_elem,
> > > +	.map_check_btf = bpf_local_storage_map_check_btf,
> > > +	.map_btf_name = "bpf_local_storage_map",
> > > +	.map_btf_id = &inode_storage_map_btf_id,
> > > +	.map_local_storage_alloc = inode_storage_alloc,
> > > +	.map_selem_alloc = inode_selem_alloc,
> > > +	.map_local_storage_update = inode_storage_update,
> > > +	.map_local_storage_unlink = unlink_inode_storage,
> > > +};
> > > +

  reply	other threads:[~2020-07-20 22:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-09 10:12 [PATCH bpf-next v4 0/4] Generalizing bpf_local_storage KP Singh
2020-07-09 10:12 ` [PATCH bpf-next v4 1/4] bpf: Generalize bpf_sk_storage KP Singh
2020-07-10  6:59   ` Martin KaFai Lau
     [not found]     ` <CACYkzJ7szyY8vY=Rv_gr7RbMty=pxyZpPPzTpaREAa5_k0tAfg@mail.gmail.com>
     [not found]       ` <20200715064339.gxtb4qwl77macuxt@kafai-mbp>
     [not found]         ` <CACYkzJ7GmSPt8WV5nSNB2irH+Dn9QywSabZyLvqEcae2-jTuHQ@mail.gmail.com>
2020-07-15  8:57           ` KP Singh
2020-07-20 11:18   ` kernel test robot
2020-07-20 11:18     ` kernel test robot
2020-07-09 10:12 ` [PATCH bpf-next v4 2/4] bpf: Implement bpf_local_storage for inodes KP Singh
2020-07-15 21:57   ` Martin KaFai Lau
2020-07-15 22:59     ` KP Singh
2020-07-20 22:44       ` KP Singh [this message]
2020-07-09 10:12 ` [PATCH bpf-next v4 3/4] bpf: Allow local storage to be used from LSM programs KP Singh
2020-07-09 10:12 ` [PATCH bpf-next v4 4/4] bpf: Add selftests for local_storage KP Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200720224411.GA1873800@google.com \
    --to=kpsingh@chromium.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jannh@google.com \
    --cc=kafai@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=pjt@google.com \
    --cc=revest@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.