Netfilter-Devel Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH] iptables: open eBPF programs in read only mode
@ 2020-03-20  3:00 Maciej Żenczykowski
  2020-03-26 13:59 ` Pablo Neira Ayuso
  2020-03-31 16:07 ` [PATCH v3] " Maciej Żenczykowski
  0 siblings, 2 replies; 12+ messages in thread
From: Maciej Żenczykowski @ 2020-03-20  3:00 UTC (permalink / raw)
  To: Maciej Żenczykowski, Pablo Neira Ayuso, Florian Westphal
  Cc: Linux Network Development Mailing List, netfilter-devel,
	Chenbo Feng, Alexei Starovoitov, Willem de Bruijn

From: Maciej Żenczykowski <maze@google.com>

Adjust the mode eBPF programs are opened in so 0400 pinned bpf programs
work without requiring CAP_DAC_OVERRIDE.

This matches Linux 5.2's:
  commit e547ff3f803e779a3898f1f48447b29f43c54085
  Author: Chenbo Feng <fengc@google.com>
  Date:   Tue May 14 19:42:57 2019 -0700

    bpf: relax inode permission check for retrieving bpf program

    For iptable module to load a bpf program from a pinned location, it
    only retrieve a loaded program and cannot change the program content so
    requiring a write permission for it might not be necessary.
    Also when adding or removing an unrelated iptable rule, it might need to
    flush and reload the xt_bpf related rules as well and triggers the inode
    permission check. It might be better to remove the write premission
    check for the inode so we won't need to grant write access to all the
    processes that flush and restore iptables rules.

  kernel/bpf/inode.c:
  - int ret = inode_permission(inode, MAY_READ | MAY_WRITE);
  + int ret = inode_permission(inode, MAY_READ);

In practice, AFAICT, the xt_bpf match .fd field isn't even used by new
kernels, but I believe it might be needed for compatibility with old ones
(though I'm pretty sure table modifications on them will outright fail).

Test: builds, passes Android test suite (albeit on an older iptables base),
  git grep bpf_obj_get - finds no other users
Cc: Chenbo Feng <fengc@google.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Willem de Bruijn <willemb@google.com>
Signed-off-by: Maciej Żenczykowski <maze@google.com>
---
 extensions/libxt_bpf.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/extensions/libxt_bpf.c b/extensions/libxt_bpf.c
index 92958247..bf46505c 100644
--- a/extensions/libxt_bpf.c
+++ b/extensions/libxt_bpf.c
@@ -61,12 +61,13 @@ static const struct xt_option_entry bpf_opts_v1[] = {
 	XTOPT_TABLEEND,
 };
 
-static int bpf_obj_get(const char *filepath)
+static int bpf_obj_get_readonly(const char *filepath)
 {
 #if defined HAVE_LINUX_BPF_H && defined __NR_bpf && defined BPF_FS_MAGIC
 	union bpf_attr attr;
 
 	memset(&attr, 0, sizeof(attr));
+	attr.file_flags = BPF_F_RDONLY;
 	attr.pathname = (__u64) filepath;
 
 	return syscall(__NR_bpf, BPF_OBJ_GET, &attr, sizeof(attr));
@@ -125,7 +126,7 @@ static void bpf_parse_string(struct sock_filter *pc, __u16 *lenp, __u16 len_max,
 static void bpf_parse_obj_pinned(struct xt_bpf_info_v1 *bi,
 				 const char *filepath)
 {
-	bi->fd = bpf_obj_get(filepath);
+	bi->fd = bpf_obj_get_readonly(filepath);
 	if (bi->fd < 0)
 		xtables_error(PARAMETER_PROBLEM,
 			      "bpf: failed to get bpf object");
-- 
2.25.1.696.g5e7596f4ac-goog


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] iptables: open eBPF programs in read only mode
  2020-03-20  3:00 [PATCH] iptables: open eBPF programs in read only mode Maciej Żenczykowski
@ 2020-03-26 13:59 ` Pablo Neira Ayuso
  2020-03-26 14:08   ` Maciej Żenczykowski
  2020-03-31 16:07 ` [PATCH v3] " Maciej Żenczykowski
  1 sibling, 1 reply; 12+ messages in thread
From: Pablo Neira Ayuso @ 2020-03-26 13:59 UTC (permalink / raw)
  To: Maciej Żenczykowski
  Cc: Maciej Żenczykowski, Florian Westphal,
	Linux Network Development Mailing List, netfilter-devel,
	Chenbo Feng, Alexei Starovoitov, Willem de Bruijn

On Thu, Mar 19, 2020 at 08:00:15PM -0700, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski <maze@google.com>
> 
> Adjust the mode eBPF programs are opened in so 0400 pinned bpf programs
> work without requiring CAP_DAC_OVERRIDE.

Unfortunately this is breaking stuff:

libxt_bpf.c: In function ‘bpf_obj_get_readonly’:
libxt_bpf.c:70:6: error: ‘union bpf_attr’ has no member named ‘file_flags’
   70 |  attr.file_flags = BPF_F_RDONLY;
      |      ^
libxt_bpf.c:70:20: error: ‘BPF_F_RDONLY’ undeclared (first use in this function)
   70 |  attr.file_flags = BPF_F_RDONLY;
      |                    ^~~~~~~~~~~~

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] iptables: open eBPF programs in read only mode
  2020-03-26 13:59 ` Pablo Neira Ayuso
@ 2020-03-26 14:08   ` Maciej Żenczykowski
  2020-03-26 14:13     ` Maciej Żenczykowski
  0 siblings, 1 reply; 12+ messages in thread
From: Maciej Żenczykowski @ 2020-03-26 14:08 UTC (permalink / raw)
  To: Pablo Neira Ayuso
  Cc: Florian Westphal, Linux Network Development Mailing List,
	Netfilter Development Mailinglist, Chenbo Feng,
	Alexei Starovoitov, Willem de Bruijn

I don't get it.  It builds for me.

And it doesn't if I insert an intentional syntax error in the same line,
so I'm definitely compiling exactly that code.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] iptables: open eBPF programs in read only mode
  2020-03-26 14:08   ` Maciej Żenczykowski
@ 2020-03-26 14:13     ` Maciej Żenczykowski
  2020-03-26 14:16       ` Maciej Żenczykowski
  0 siblings, 1 reply; 12+ messages in thread
From: Maciej Żenczykowski @ 2020-03-26 14:13 UTC (permalink / raw)
  To: Pablo Neira Ayuso
  Cc: Florian Westphal, Linux Network Development Mailing List,
	Netfilter Development Mailinglist, Chenbo Feng,
	Alexei Starovoitov, Willem de Bruijn

I think your build system's kernel headers are old.

Linux 4.15-rc1 commit 6e71b04a82248ccf13a94b85cbc674a9fefe53f5
Author: Chenbo Feng <fengc@google.com>
Date:   Wed Oct 18 13:00:22 2017 -0700

    bpf: Add file mode configuration into bpf maps
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -218,6 +218,10 @@ enum bpf_attach_type {

 #define BPF_OBJ_NAME_LEN 16U

+/* Flags for accessing BPF object */
+#define BPF_F_RDONLY           (1U << 3)
+#define BPF_F_WRONLY           (1U << 4)
+
 union bpf_attr {
        struct { /* anonymous struct used by BPF_MAP_CREATE command */
                __u32   map_type;       /* one of enum bpf_map_type */
@@ -260,6 +264,7 @@ union bpf_attr {
        struct { /* anonymous struct used by BPF_OBJ_* commands */
                __aligned_u64   pathname;
                __u32           bpf_fd;
+               __u32           file_flags;
        };

        struct { /* anonymous struct used by BPF_PROG_ATTACH/DETACH commands */

On Thu, Mar 26, 2020 at 7:08 AM Maciej Żenczykowski
<zenczykowski@gmail.com> wrote:
>
> I don't get it.  It builds for me.
>
> And it doesn't if I insert an intentional syntax error in the same line,
> so I'm definitely compiling exactly that code.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] iptables: open eBPF programs in read only mode
  2020-03-26 14:13     ` Maciej Żenczykowski
@ 2020-03-26 14:16       ` Maciej Żenczykowski
  2020-03-26 14:19         ` Maciej Żenczykowski
  2020-03-26 14:22         ` [PATCH] " Pablo Neira Ayuso
  0 siblings, 2 replies; 12+ messages in thread
From: Maciej Żenczykowski @ 2020-03-26 14:16 UTC (permalink / raw)
  To: Pablo Neira Ayuso
  Cc: Florian Westphal, Linux Network Development Mailing List,
	Netfilter Development Mailinglist, Chenbo Feng,
	Alexei Starovoitov, Willem de Bruijn

I guess maybe we could wrap it in a

#ifdef BPF_F_RDONLY
attr.file_flags = BPF_F_RDONLY;
#endif

if we want to continue supporting building against pre-4.15 kernel headers...

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] iptables: open eBPF programs in read only mode
  2020-03-26 14:16       ` Maciej Żenczykowski
@ 2020-03-26 14:19         ` Maciej Żenczykowski
  2020-03-26 14:28           ` [PATCH v2] " Maciej Żenczykowski
  2020-03-26 14:22         ` [PATCH] " Pablo Neira Ayuso
  1 sibling, 1 reply; 12+ messages in thread
From: Maciej Żenczykowski @ 2020-03-26 14:19 UTC (permalink / raw)
  To: Pablo Neira Ayuso
  Cc: Florian Westphal, Linux Network Development Mailing List,
	Netfilter Development Mailinglist, Chenbo Feng,
	Alexei Starovoitov, Willem de Bruijn

Ugh, and I guess that on a pre-4.15 kernel it would cause failures due
to unknown flag...

Maybe we need to try with flag and fallback to without...

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] iptables: open eBPF programs in read only mode
  2020-03-26 14:16       ` Maciej Żenczykowski
  2020-03-26 14:19         ` Maciej Żenczykowski
@ 2020-03-26 14:22         ` " Pablo Neira Ayuso
  1 sibling, 0 replies; 12+ messages in thread
From: Pablo Neira Ayuso @ 2020-03-26 14:22 UTC (permalink / raw)
  To: Maciej Żenczykowski
  Cc: Florian Westphal, Linux Network Development Mailing List,
	Netfilter Development Mailinglist, Chenbo Feng,
	Alexei Starovoitov, Willem de Bruijn

On Thu, Mar 26, 2020 at 07:16:16AM -0700, Maciej Żenczykowski wrote:
> I guess maybe we could wrap it in a
> 
> #ifdef BPF_F_RDONLY
> attr.file_flags = BPF_F_RDONLY;
> #endif
> 
> if we want to continue supporting building against pre-4.15 kernel headers...

You can probably add a cached copy of this header file to the iptables
tree via your patch like. This is done in other existing extensions to
not rely on the available kernel headers.

There is no parity between userspace iptables and kernel version, it
is good if you make sure this compiles for older kernels are still
supported.

Thank you.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [PATCH v2] iptables: open eBPF programs in read only mode
  2020-03-26 14:19         ` Maciej Żenczykowski
@ 2020-03-26 14:28           ` " Maciej Żenczykowski
  2020-03-26 18:30             ` Jakub Kicinski
  0 siblings, 1 reply; 12+ messages in thread
From: Maciej Żenczykowski @ 2020-03-26 14:28 UTC (permalink / raw)
  To: Maciej Żenczykowski, Pablo Neira Ayuso, Florian Westphal
  Cc: Linux Network Development Mailing List,
	Netfilter Development Mailing List, Chenbo Feng,
	Alexei Starovoitov, Willem de Bruijn

From: Maciej Żenczykowski <maze@google.com>

Adjust the mode eBPF programs are opened in so 0400 pinned bpf programs
work without requiring CAP_DAC_OVERRIDE.

This matches Linux 5.2's:
  commit e547ff3f803e779a3898f1f48447b29f43c54085
  Author: Chenbo Feng <fengc@google.com>
  Date:   Tue May 14 19:42:57 2019 -0700

    bpf: relax inode permission check for retrieving bpf program

    For iptable module to load a bpf program from a pinned location, it
    only retrieve a loaded program and cannot change the program content so
    requiring a write permission for it might not be necessary.
    Also when adding or removing an unrelated iptable rule, it might need to
    flush and reload the xt_bpf related rules as well and triggers the inode
    permission check. It might be better to remove the write premission
    check for the inode so we won't need to grant write access to all the
    processes that flush and restore iptables rules.

  kernel/bpf/inode.c:
  - int ret = inode_permission(inode, MAY_READ | MAY_WRITE);
  + int ret = inode_permission(inode, MAY_READ);

In practice, AFAICT, the xt_bpf match .fd field isn't even used by new
kernels, but I believe it might be needed for compatibility with old ones
(though I'm pretty sure table modifications on them will outright fail).

Test: builds, passes Android test suite (albeit on an older iptables base),
  git grep bpf_obj_get - finds no other users
Cc: Chenbo Feng <fengc@google.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Willem de Bruijn <willemb@google.com>
Signed-off-by: Maciej Żenczykowski <maze@google.com>
---
 extensions/libxt_bpf.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/extensions/libxt_bpf.c b/extensions/libxt_bpf.c
index 92958247..44cdd5cb 100644
--- a/extensions/libxt_bpf.c
+++ b/extensions/libxt_bpf.c
@@ -61,11 +61,22 @@ static const struct xt_option_entry bpf_opts_v1[] = {
 	XTOPT_TABLEEND,
 };
 
-static int bpf_obj_get(const char *filepath)
+static int bpf_obj_get_readonly(const char *filepath)
 {
 #if defined HAVE_LINUX_BPF_H && defined __NR_bpf && defined BPF_FS_MAGIC
 	union bpf_attr attr;
+	// file_flags && BPF_F_RDONLY requires Linux 4.15+ uapi kernel headers
+#ifdef BPF_F_RDONLY
+	int fd;
 
+	memset(&attr, 0, sizeof(attr));
+	attr.pathname = (__u64) filepath;
+	attr.file_flags = BPF_F_RDONLY;
+	fd = syscall(__NR_bpf, BPF_OBJ_GET, &attr, sizeof(attr));
+	if (fd >= 0) return fd;
+
+	// on any error fallback to default R/W access for pre-4.15-rc1 kernels
+#endif
 	memset(&attr, 0, sizeof(attr));
 	attr.pathname = (__u64) filepath;
 
@@ -125,7 +136,7 @@ static void bpf_parse_string(struct sock_filter *pc, __u16 *lenp, __u16 len_max,
 static void bpf_parse_obj_pinned(struct xt_bpf_info_v1 *bi,
 				 const char *filepath)
 {
-	bi->fd = bpf_obj_get(filepath);
+	bi->fd = bpf_obj_get_readonly(filepath);
 	if (bi->fd < 0)
 		xtables_error(PARAMETER_PROBLEM,
 			      "bpf: failed to get bpf object");
-- 
2.25.1.696.g5e7596f4ac-goog


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] iptables: open eBPF programs in read only mode
  2020-03-26 14:28           ` [PATCH v2] " Maciej Żenczykowski
@ 2020-03-26 18:30             ` Jakub Kicinski
  2020-03-26 18:34               ` Maciej Żenczykowski
  0 siblings, 1 reply; 12+ messages in thread
From: Jakub Kicinski @ 2020-03-26 18:30 UTC (permalink / raw)
  To: Maciej Żenczykowski
  Cc: Maciej Żenczykowski, Pablo Neira Ayuso, Florian Westphal,
	Linux Network Development Mailing List,
	Netfilter Development Mailing List, Chenbo Feng,
	Alexei Starovoitov, Willem de Bruijn

On Thu, 26 Mar 2020 07:28:03 -0700 Maciej Żenczykowski wrote:
> diff --git a/extensions/libxt_bpf.c b/extensions/libxt_bpf.c
> index 92958247..44cdd5cb 100644
> --- a/extensions/libxt_bpf.c
> +++ b/extensions/libxt_bpf.c
> @@ -61,11 +61,22 @@ static const struct xt_option_entry bpf_opts_v1[] = {
>  	XTOPT_TABLEEND,
>  };
>  
> -static int bpf_obj_get(const char *filepath)
> +static int bpf_obj_get_readonly(const char *filepath)
>  {
>  #if defined HAVE_LINUX_BPF_H && defined __NR_bpf && defined BPF_FS_MAGIC
>  	union bpf_attr attr;
> +	// file_flags && BPF_F_RDONLY requires Linux 4.15+ uapi kernel headers
> +#ifdef BPF_F_RDONLY

FWIW the BPF subsystem is about to break uAPI backward-compat and
replace the defines with enums. See commit 1aae4bdd7879 ("bpf: Switch
BPF UAPI #define constants used from BPF program side to enums").

> +	int fd;
>  
> +	memset(&attr, 0, sizeof(attr));
> +	attr.pathname = (__u64) filepath;
> +	attr.file_flags = BPF_F_RDONLY;
> +	fd = syscall(__NR_bpf, BPF_OBJ_GET, &attr, sizeof(attr));
> +	if (fd >= 0) return fd;
> +
> +	// on any error fallback to default R/W access for pre-4.15-rc1 kernels
> +#endif

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] iptables: open eBPF programs in read only mode
  2020-03-26 18:30             ` Jakub Kicinski
@ 2020-03-26 18:34               ` Maciej Żenczykowski
  2020-03-26 19:22                 ` Alexei Starovoitov
  0 siblings, 1 reply; 12+ messages in thread
From: Maciej Żenczykowski @ 2020-03-26 18:34 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Pablo Neira Ayuso, Florian Westphal,
	Linux Network Development Mailing List,
	Netfilter Development Mailing List, Chenbo Feng,
	Alexei Starovoitov, Willem de Bruijn

> FWIW the BPF subsystem is about to break uAPI backward-compat and
> replace the defines with enums. See commit 1aae4bdd7879 ("bpf: Switch
> BPF UAPI #define constants used from BPF program side to enums").

Shouldn't it do what is normally done in such a case?
#define BPF_F_RDONLY BPF_F_RDONLY

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] iptables: open eBPF programs in read only mode
  2020-03-26 18:34               ` Maciej Żenczykowski
@ 2020-03-26 19:22                 ` Alexei Starovoitov
  0 siblings, 0 replies; 12+ messages in thread
From: Alexei Starovoitov @ 2020-03-26 19:22 UTC (permalink / raw)
  To: Maciej Żenczykowski
  Cc: Jakub Kicinski, Pablo Neira Ayuso, Florian Westphal,
	Linux Network Development Mailing List,
	Netfilter Development Mailing List, Chenbo Feng,
	Alexei Starovoitov, Willem de Bruijn

On Thu, Mar 26, 2020 at 11:34 AM Maciej Żenczykowski
<zenczykowski@gmail.com> wrote:
>
> > FWIW the BPF subsystem is about to break uAPI backward-compat and
> > replace the defines with enums. See commit 1aae4bdd7879 ("bpf: Switch
> > BPF UAPI #define constants used from BPF program side to enums").
>
> Shouldn't it do what is normally done in such a case?
> #define BPF_F_RDONLY BPF_F_RDONLY

No. just update the headers.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [PATCH v3] iptables: open eBPF programs in read only mode
  2020-03-20  3:00 [PATCH] iptables: open eBPF programs in read only mode Maciej Żenczykowski
  2020-03-26 13:59 ` Pablo Neira Ayuso
@ 2020-03-31 16:07 ` " Maciej Żenczykowski
  1 sibling, 0 replies; 12+ messages in thread
From: Maciej Żenczykowski @ 2020-03-31 16:07 UTC (permalink / raw)
  To: Maciej Żenczykowski, Pablo Neira Ayuso, Florian Westphal
  Cc: Linux Network Development Mailing List,
	Netfilter Development Mailing List, Chenbo Feng,
	Alexei Starovoitov, Willem de Bruijn

From: Maciej Żenczykowski <maze@google.com>

Adjust the mode eBPF programs are opened in so 0400 pinned bpf programs
work without requiring CAP_DAC_OVERRIDE.

This matches Linux 5.2's:
  commit e547ff3f803e779a3898f1f48447b29f43c54085
  Author: Chenbo Feng <fengc@google.com>
  Date:   Tue May 14 19:42:57 2019 -0700

    bpf: relax inode permission check for retrieving bpf program

    For iptable module to load a bpf program from a pinned location, it
    only retrieve a loaded program and cannot change the program content so
    requiring a write permission for it might not be necessary.
    Also when adding or removing an unrelated iptable rule, it might need to
    flush and reload the xt_bpf related rules as well and triggers the inode
    permission check. It might be better to remove the write premission
    check for the inode so we won't need to grant write access to all the
    processes that flush and restore iptables rules.

  kernel/bpf/inode.c:
  - int ret = inode_permission(inode, MAY_READ | MAY_WRITE);
  + int ret = inode_permission(inode, MAY_READ);

In practice, AFAICT, the xt_bpf match .fd field isn't even used by new
kernels, but I believe it might be needed for compatibility with old ones
(though I'm pretty sure table modifications on them will outright fail).

Test: builds, passes Android test suite (albeit on an older iptables base),
  git grep bpf_obj_get - finds no other users
Cc: Chenbo Feng <fengc@google.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Willem de Bruijn <willemb@google.com>
Signed-off-by: Maciej Żenczykowski <maze@google.com>
---
 extensions/libxt_bpf.c | 25 ++++++++++++++++++-------
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/extensions/libxt_bpf.c b/extensions/libxt_bpf.c
index 92958247..4aea477a 100644
--- a/extensions/libxt_bpf.c
+++ b/extensions/libxt_bpf.c
@@ -61,14 +61,25 @@ static const struct xt_option_entry bpf_opts_v1[] = {
 	XTOPT_TABLEEND,
 };
 
-static int bpf_obj_get(const char *filepath)
+static int bpf_obj_get_readonly(const char *filepath)
 {
 #if defined HAVE_LINUX_BPF_H && defined __NR_bpf && defined BPF_FS_MAGIC
-	union bpf_attr attr;
-
-	memset(&attr, 0, sizeof(attr));
-	attr.pathname = (__u64) filepath;
-
+	// union bpf_attr includes this in an anonymous struct, but the
+	// file_flags field and the BPF_F_RDONLY constant are only present
+	// in Linux 4.15+ kernel headers (include/uapi/linux/bpf.h)
+	struct {   // this part of union bpf_attr is for BPF_OBJ_* commands
+		__aligned_u64	pathname;
+		__u32		bpf_fd;
+		__u32		file_flags;
+	} attr = {
+		.pathname = (__u64)filepath,
+		.file_flags = (1U << 3),   // BPF_F_RDONLY
+	};
+	int fd = syscall(__NR_bpf, BPF_OBJ_GET, &attr, sizeof(attr));
+	if (fd >= 0) return fd;
+
+	// on any error fallback to default R/W access for pre-4.15-rc1 kernels
+	attr.file_flags = 0;
 	return syscall(__NR_bpf, BPF_OBJ_GET, &attr, sizeof(attr));
 #else
 	xtables_error(OTHER_PROBLEM,
@@ -125,7 +136,7 @@ static void bpf_parse_string(struct sock_filter *pc, __u16 *lenp, __u16 len_max,
 static void bpf_parse_obj_pinned(struct xt_bpf_info_v1 *bi,
 				 const char *filepath)
 {
-	bi->fd = bpf_obj_get(filepath);
+	bi->fd = bpf_obj_get_readonly(filepath);
 	if (bi->fd < 0)
 		xtables_error(PARAMETER_PROBLEM,
 			      "bpf: failed to get bpf object");
-- 
2.26.0.rc2.310.g2932bb562d-goog


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, back to index

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-20  3:00 [PATCH] iptables: open eBPF programs in read only mode Maciej Żenczykowski
2020-03-26 13:59 ` Pablo Neira Ayuso
2020-03-26 14:08   ` Maciej Żenczykowski
2020-03-26 14:13     ` Maciej Żenczykowski
2020-03-26 14:16       ` Maciej Żenczykowski
2020-03-26 14:19         ` Maciej Żenczykowski
2020-03-26 14:28           ` [PATCH v2] " Maciej Żenczykowski
2020-03-26 18:30             ` Jakub Kicinski
2020-03-26 18:34               ` Maciej Żenczykowski
2020-03-26 19:22                 ` Alexei Starovoitov
2020-03-26 14:22         ` [PATCH] " Pablo Neira Ayuso
2020-03-31 16:07 ` [PATCH v3] " Maciej Żenczykowski

Netfilter-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/netfilter-devel/0 netfilter-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 netfilter-devel netfilter-devel/ https://lore.kernel.org/netfilter-devel \
		netfilter-devel@vger.kernel.org
	public-inbox-index netfilter-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.netfilter-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git