On 08/11/2019 15:34, Daniel Borkmann wrote:

On 11/8/19 3:08 PM, Mickaël Salaün wrote:

quoted

On 06/11/2019 22:45, KP Singh wrote:

quoted

On 06-Nov 17:55, Mickaël Salaün wrote:

quoted

On 06/11/2019 11:06, KP Singh wrote:

quoted

On 05-Nov 11:34, Alexei Starovoitov wrote:

quoted

On Tue, Nov 05, 2019 at 07:01:41PM +0100, Mickaël Salaün wrote:

quoted

On 05/11/2019 18:18, Alexei Starovoitov wrote:

[...]

quoted

quoted

* Use a single BPF program type; this is necessary for a key requirement
   of KRSI, i.e. runtime instrumentation. The upcoming prototype should
   illustrate how this works for KRSI - note that it’s possible to vary
   the context types exposed by different hooks.

Why a single BPF program type? Do you mean *attach* types? Landlock only
use one program type, but will use multiple attach types.

Why do you think it is necessary for KRSI or for runtime instrumentation?

If it is justified, it could be a dedicated program attach type (e.g.
BPF_LANDLOCK_INTROSPECTION).

What is the advantage to have the possibility to vary the context types
over dedicated *typed* contexts? I don't see any advantages, but at
least one main drawback: to require runtime checks (when helpers use
this generic context) instead of load time checks (thanks to static type
checking of the context).

Lets take security_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
as one specific example here: the running kernel has its own internal
btf_vmlinux and therefore a complete description of itself. From verifier
side we can retrieve & introspect the security_sock_rcv_skb signatue

OK, this is indeed the signature defined by the kernel API. What happen
if this API change (e.g. if struct sock is replaced with a struct
sock_meta)?

and
thus know that the given BPF attachment point has struct sock and struct
sk_buff as input arguments

How does the verifier know a given BPF attachment point for a program
without relying on its type or attach type? How and where is registered
this mapping?

To say it another way, if there is no way to differentiate two program
targeting different hook, I don't understand how the verifier could
check if a given program can legitimately call a helper which could read
the tracer and tracee fields (legitimate for a ptrace hook), whereas
this program may be attached to a sock_rcv_skb hook (and there is no way
to know that).

which can then be accessed generically by the
prog in order to allow sk_filter_trim_cap() to pass or to drop the skb.
The same generic approach can be done for many of the other lsm hooks, so
single program type would be enough there and context is derived
automatically,
no dedicated extra context per attach type would be needed and no runtime
checks as you mentioned above since its still all asserted at verification
time.

I mentioned runtime check because I though a helper should handle the
case when it doesn't make sense for a program attached to a specific
point/hook (e.g. ptrace) to use an input argument (e.g. sk) defined for
another point/hook (e.g. sock_rcv_skb).

Thanks,
Daniel

Thanks for this explanation Daniel.