BPF List
 help / color / mirror / Atom feed
From: Song Liu <songliubraving@meta.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Song Liu <song@kernel.org>, bpf <bpf@vger.kernel.org>,
	Linux-Fsdevel <linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Kernel Team <kernel-team@meta.com>,
	Andrii Nakryiko <andrii@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	"brauner@kernel.org" <brauner@kernel.org>,
	Jan Kara <jack@suse.cz>, KP Singh <kpsingh@kernel.org>,
	"mattbobrowski@google.com" <mattbobrowski@google.com>
Subject: Re: [PATCH bpf-next 1/2] bpf: Add kfunc bpf_get_dentry_xattr() to read xattr from dentry
Date: Fri, 26 Jul 2024 07:01:39 +0000	[thread overview]
Message-ID: <B0E4F345-9958-44C2-9985-96F77F0DEF0F@fb.com> (raw)
In-Reply-To: <20240726053430.GB99483@ZenIV>

Hi Al, 

Thanks for your quick reply. 

> On Jul 25, 2024, at 10:34 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> 
> On Thu, Jul 25, 2024 at 04:47:05PM -0700, Song Liu wrote:
> 
>> +__bpf_kfunc struct dentry *bpf_file_dentry(const struct file *file)
>> +{
>> + /* file_dentry() does not hold reference to the dentry. We add a
>> + * dget() here so that we can add KF_ACQUIRE flag to
>> + * bpf_file_dentry().
>> + */
>> + return dget(file_dentry(file));
>> +}
>> +
>> +__bpf_kfunc struct dentry *bpf_dget_parent(struct dentry *dentry)
>> +{
>> + return dget_parent(dentry);
>> +}
>> +
>> +__bpf_kfunc void bpf_dput(struct dentry *dentry)
>> +{
>> + return dput(dentry);
>> +}
> 
> If you keep a file reference, why bother grabbing dentry one?
> If not, you have a very bad trouble if that opened file is the only
> thing that keeps the filesystem busy.

Yes, we keep a file reference for the duration of the BPF program. 
Therefore, it is technically not necessary to grab a dentry one.
However, we grab a dentry reference to make the dentry pointer 
returned by bpf_file_dentry() a trusted pointer from BPF verifier's 
POV, so that these kfuncs are more robust. 

The following explanation is a bit long. Please let me know if it 
turns out confusing.


==== What is trusted pointer? ====

Trusted point is the mechanism to make sure bpf kfuncs are 
called with valid pointer. The BPF verifier requires certain BPF 
kfuncs (helpers) are called with trusted pointers. A pointer is 
trusted if one of the following two is true:

1. The pointer is passed directly by the tracepoint/kprobe, i.e., 
   no pointer walking, no non-zero offset. For example, 

   int bpf_security_file_open(struct file *file)  /* file is trusted */
   {
       /* mapping is not trusted */
       struct address_space    *mapping = file->f_mapping;

       /* file2 is not trusted */
       struct file *file2 = file + 1;
   }

2. The pointer is returned by a kfunc with KF_ACQUIRE. This pointer 
   has to be released by a kfunc with KF_RELEASE. KF_ACQUIRE and 
   KF_RELEASE kfuncs are like any _get() _put() pairs. 


==== bpf_dget_parent and bpf_dput ====

In this case, bpf_dget_parent() is a KF_ACQUIRE kfunc and 
bpf_dput() is a KF_RELEASE function. They are just like regular
_get() _put() functions. 

The BPF verifier makes sure pointers acquired by bpf_dget_parent() 
is always released by bpf_dput() before the BPF program returns. 
For example, in the following BPF program:

xxxx(struct dentry *d)
{
    struct dentry *parent = bpf_dget_parent(d); 

    /* main logic */
     
    bpf_dput(parent);
}

If the bpf_dput() call is missing, the verifier will not allow
the program to load. 


==== More on kfunc safety ====

Trusted point makes kfunc calls safe. In this case, we want 
bpf_get_dentry_xattr() to only take trusted dentry pointer. 
For example, in the security_inode_listxattr LSM hook:

bpf_security_inode_listxattr(struct dentry *dentry)
{
       /* This is allowed, dentry is an input and thus
        * is trusted 
        */
       bpf_get_dentry_xattr(dentry); 


       /* This is not allowed, as dentry->d_parent is 
        * not trusted
        */
       bpf_get_dentry_xattr(dentry->d_parent);


       /* This is allowed, as bpf_dget_parent() holds  
        * a reference to d_parent, and returns a trusted
        * pointer
        */
       struct dentry *parent = bpf_dget_parent(dentry);


       /* The following is needed, as we need the release 
        * parent pointer. If this line is missing, this
        * program cannot pass BPF verifier. 
        */
       bpf_dput(parent);
}


==== bpf_file_dentry ====

In this use case, we want to get from file pointer, such as
LSM hook security_file_open() to the dentry and thus walk the
directory tree. However, security_file_open() does not pass
in a dentry pointer, and file->f_path.dentry is not a trusted
pointer. There are two ways to get a trusted dentry pointer
from a file pointer:

1. As what we do here, use bpf_file_dentry() to hold a 
   reference on file->f_path.dentry and return a trusted 
   pointer. 
2. Give the verifier special knowledge that if file pointer
   is trusted, file->f_path.dentry is also trusted. This 
   can be achieve with the following macros:
      BTF_TYPE_SAFE_TRUSTED
      BTF_TYPE_SAFE_RCU
      BTF_TYPE_SAFE_RCU_OR_NULL. 

Using the second method here requires a little more work in the
BPF verifier, as dentry is not a simple pointer in struct file, 
but f_path.dentry. Therefore, I chose current approach that
bpf_file_dentry() holds a reference on dentry pointer, and the 
pointer has to be released with bpf_dput(). 

For more details about trusted pointers in kfuncs, please refer to 
Documentation/bpf/kfuncs.rst. 

Does this answer your question? 

Thanks,
Song


> It's almost certainly a wrong interface; please, explain what
> exactly are you trying to do here.






  reply	other threads:[~2024-07-26  7:01 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-25 23:47 [PATCH bpf-next 0/2] Add kfuncs to support reading xattr from dentry Song Liu
2024-07-25 23:47 ` [PATCH bpf-next 1/2] bpf: Add kfunc bpf_get_dentry_xattr() to read " Song Liu
2024-07-26  5:34   ` Al Viro
2024-07-26  7:01     ` Song Liu [this message]
2024-07-25 23:47 ` [PATCH bpf-next 2/2] selftests/bpf: Add tests for bpf_get_dentry_xattr Song Liu
2024-07-26  7:06   ` Christian Brauner
2024-07-26  9:19     ` Song Liu
2024-07-26 11:51       ` Christian Brauner
2024-07-26 19:43         ` Song Liu
2024-07-29 13:46           ` Christian Brauner
2024-07-30  5:58             ` Song Liu
2024-07-30  8:59               ` Christian Brauner
2024-08-19  7:18             ` Song Liu
2024-08-19 11:16               ` Christian Brauner
2024-08-19 13:12                 ` Mickaël Salaün
2024-08-19 20:35                   ` Song Liu
2024-08-20 12:45                     ` Mickaël Salaün
2024-08-20 17:42                       ` Song Liu
2024-08-20 21:11                         ` Paul Moore
2024-08-21  3:43                           ` Song Liu
2024-08-23 10:38                             ` Mickaël Salaün
2024-08-19 20:25                 ` Song Liu
2024-08-20  5:42                   ` Song Liu
2024-08-20  6:29                   ` Al Viro
2024-08-20  7:23                     ` Song Liu

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=B0E4F345-9958-44C2-9985-96F77F0DEF0F@fb.com \
    --to=songliubraving@meta.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=jack@suse.cz \
    --cc=kernel-team@meta.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=mattbobrowski@google.com \
    --cc=song@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox