netdev - Re: [RPC PATCH bpf-next] bpf: implement new BPF_CGROUP_INET_SOCK_POST

lists.openwall.net		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 linux-hardening linux-cve-announce 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]

Message-ID: <CAKH8qBuZ0iLAiuqi=65RBiQ=Vhi3qkitPzj0b7U=XuiH_4TuLA@mail.gmail.com>
Date:   Fri, 15 Jan 2021 08:39:00 -0800
From:   Stanislav Fomichev <sdf@...gle.com>
To:     Yonghong Song <yhs@...com>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>
Subject: Re: [RPC PATCH bpf-next] bpf: implement new BPF_CGROUP_INET_SOCK_POST_CONNECT

On Thu, Jan 14, 2021 at 8:27 PM Yonghong Song <yhs@...com> wrote:
>
>
>
> On 1/14/21 7:59 PM, Alexei Starovoitov wrote:
> > On Thu, Jan 14, 2021 at 7:51 PM Stanislav Fomichev <sdf@...gle.com> wrote:
> >>>>
> >>>>          lock_sock(sock->sk);
> >>>>          err = __inet_stream_connect(sock, uaddr, addr_len, flags, 0);
> >>>
> >>> Similarly here, attaching fexit to __inet_stream_connect would execute
> >>> your BPF program at exactly the same time (and then you can check for
> >>> err value).
> >>>
> >>> Or the point here is to have a more "stable" BPF program type?
> >> Good suggestion, I can try to play with it, I think it should give me
> >> all the info I need (I only need sock).
> >> But yeah, I'd rather prefer a stable interface against stable
> >> __sk_buff, but maybe fexit will also work.
> >
> > Maybe we can add an extension to fentry/fexit that are cgroup scoped?
> > I think this will solve many such cases.
>
> Currently, google is pushing LTO build of the kernel. If this happens,
> it is possible one global function in one file (say a.c) might be
> inlined into another file (say b.c). So in this particular case,
> if the global function is inlined, fentry/fexit approach might be
> missing some cases? We could mark certain *special purpose* function
> as non-inline, but not sure whether this is scalable or not.
For this particular case I don't think it matters, right?
I'd like to fexit ip4_datagram_connect which is exported symbol,
it's accessed via proto->connect and there is no way it's
gonna be inlined. Unless our indirect call macros give clang
a hint :-/

I'm in general a bit concerned about using tracing calls for stuff
like that and depending on the non-uapi, but it's probably
time to give it a try and see how co-re works :-)