lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 9 Mar 2020 11:50:43 -0700
From:   Jakub Kicinski <>
To:     Toke Høiland-Jørgensen <>
Cc:     Alexei Starovoitov <>,
        Alexei Starovoitov <>,
        Daniel Borkmann <>,
        Andrii Nakryiko <>,
        Andrii Nakryiko <>, bpf <>,
        Networking <>,
        Kernel Team <>
Subject: Re: [PATCH bpf-next 0/3] Introduce pinnable bpf_link kernel

On Mon, 09 Mar 2020 12:41:14 +0100 Toke Høiland-Jørgensen wrote:
> > You said that like the library doesn't arbitrate access and manage
> > resources.. It does exactly the same work the daemon would do.  
> Sure, the logic is in the library, but the state (which programs are
> loaded) and synchronisation primitives (atomic replace of attached
> program) are provided by the kernel. 

I see your point of view. The state in the kernel which the library has
to read out every time is what I was thinking of as deserialization.

The library has to take some lock, and then read the state from the
kernel, and then construct its internal state based on that. I think
you have some cleverness there to stuff everything in BTF so far, but
I'd expect if the library grows that may become cumbersome and
wasteful (it's pinned memory after all). 

Parsing the packet once could be an example of something that could be
managed by the library to avoid wasted cycles. Then programs would have
to describe their requirements, and library may need to do rewrites of
the bytecode. 

I guess everything can be stuffed into BTF, but I'm not 100% sure
kernel is supposed to be a database either.

Note that the atomic replace may not sufficient for safe operation, 
as reading the state from the kernel is also not atomic.

> > Daemon just trades off the complexity of making calls for the
> > complexity of the system and serializing/de-serializing the state.  
> What state are we serialising? I'm not sure I would consider just
> pinning things in bpffs as "state serialisation"?

At a quick glance at your code, e.g. what xdp_parse_run_order() does ;)

Powered by blists - more mailing lists