On Wed, Mar 2, 2022 at 12:55 PM Yonghong Song <yhs@xxxxxx> wrote:
On 2/25/22 3:43 PM, Hao Luo wrote:
This patch allows bpf_syscall prog to perform some basic filesystem
operations: create, remove directories and unlink files. Three bpf
helpers are added for this purpose. When combined with the following
patches that allow pinning and getting bpf objects from bpf prog,
this feature can be used to create directory hierarchy in bpffs that
help manage bpf objects purely using bpf progs.
The added helpers subject to the same permission checks as their syscall
version. For example, one can not write to a read-only file system;
The identity of the current process is checked to see whether it has
sufficient permission to perform the operations.
Only directories and files in bpffs can be created or removed by these
helpers. But it won't be too hard to allow these helpers to operate
on files in other filesystems, if we want.
Signed-off-by: Hao Luo <haoluo@xxxxxxxxxx>
---
include/linux/bpf.h | 1 +
include/uapi/linux/bpf.h | 26 +++++
kernel/bpf/inode.c | 9 +-
kernel/bpf/syscall.c | 177 +++++++++++++++++++++++++++++++++
tools/include/uapi/linux/bpf.h | 26 +++++
5 files changed, 236 insertions(+), 3 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index f19abc59b6cd..fce5e26179f5 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -1584,6 +1584,7 @@ int bpf_link_new_fd(struct bpf_link *link);
struct file *bpf_link_new_file(struct bpf_link *link, int *reserved_fd);
struct bpf_link *bpf_link_get_from_fd(u32 ufd);
+bool bpf_path_is_bpf_dir(const struct path *path);
int bpf_obj_pin_user(u32 ufd, const char __user *pathname);
int bpf_obj_get_user(const char __user *pathname, int flags);
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index afe3d0d7f5f2..a5dbc794403d 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -5086,6 +5086,29 @@ union bpf_attr {
* Return
* 0 on success, or a negative error in case of failure. On error
* *dst* buffer is zeroed out.
+ *
+ * long bpf_mkdir(const char *pathname, int pathname_sz, u32 mode)
Can we make pathname_sz to be u32 instead of int? pathname_sz should
never be negative any way.
Also, I think it is a good idea to add 'u64 flags' parameter for all
three helpers, so we have room in the future to tune for new use cases.
SG. Will make this change.
Actually, I think I need to cap patthname_sz from above, to ensure
pathname_sz isn't too big. Is that necessary? I see there are other
helpers that don't have this type of check.
+ * Description[...]
+ * Attempts to create a directory name *pathname*. The argument
+ * *pathname_sz* specifies the length of the string *pathname*.
+ * The argument *mode* specifies the mode for the new directory. It
+ * is modified by the process's umask. It has the same semantic as
+ * the syscall mkdir(2).
+ * Return
+ * 0 on success, or a negative error in case of failure.
+ *
+ * long bpf_rmdir(const char *pathname, int pathname_sz)
+ * Description
+ * Deletes a directory, which must be empty.
+ * Return
+ * 0 on sucess, or a negative error in case of failure.
+ *
+ * long bpf_unlink(const char *pathname, int pathname_sz)
+ * Description
+ * Deletes a name and possibly the file it refers to. It has the
+ * same semantic as the syscall unlink(2).
+ * Return
+ * 0 on success, or a negative error in case of failure.
*/
#define __BPF_FUNC_MAPPER(FN) \
FN(unspec), \
@@ -5280,6 +5303,9 @@ union bpf_attr {
FN(xdp_load_bytes), \
FN(xdp_store_bytes), \
FN(copy_from_user_task), \
+ FN(mkdir), \
+ FN(rmdir), \
+ FN(unlink), \
/* */
/* integer value in 'imm' field of BPF_CALL instruction selects which helper