netdev - Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf

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: <91C99EC0-C441-410E-A96F-D990045E4987@fb.com>
Date:   Fri, 28 Jun 2019 19:10:50 +0000
From:   Song Liu <songliubraving@...com>
To:     Lorenz Bauer <lmb@...udflare.com>
CC:     Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        "Alexei Starovoitov" <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        "Kernel Team" <Kernel-team@...com>, Jann Horn <jannh@...gle.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf



> On Jun 28, 2019, at 2:01 AM, Lorenz Bauer <lmb@...udflare.com> wrote:
> 
> On Thu, 27 Jun 2019 at 21:19, Song Liu <songliubraving@...com> wrote:
>> 
>> This patch introduce unprivileged BPF access. The access control is
>> achieved via device /dev/bpf. Users with write access to /dev/bpf are able
>> to call sys_bpf().
>> 
>> Two ioctl command are added to /dev/bpf:
>> 
>> The two commands enable/disable permission to call sys_bpf() for current
>> task. This permission is noted by bpf_permitted in task_struct. This
>> permission is inherited during clone(CLONE_THREAD).
> 
> If I understand it correctly, a process would have to open /dev/bpf before
> spawning other threads for this to work?
> 
> That still wouldn't work for Go I'm afraid. The runtime creates and destroys
> threads on an ad-hoc basis, and there is no way to "initialize" in the
> first thread.

There should be a master thread, no? Can we do that from the master thread at
the beginning of the execution?

> With the API as is, any Go wrapper wishing to use this would have to do the
> following _for every BPF syscall_:
> 
> 1. Use runtime.LockOSThread() to prevent the scheduler from moving the
>    goroutine.
> 2. Open /dev/bpf to set the bit in current_task
> 3. Execute the syscall
> 4. Call runtime.UnlockOSThread()
> 
> Note that calling into C code via CGo doesn't change this. Is it not possible to
> set the bit on all processes in the current thread group?

I think that's possible, with some extra work. And there will be overhead, as 
we need to atomic operation for all these processes. I would rather not to this
path unless it is really necessary. 

Thanks,
Song