linux-kernel - Re: [PATCH bpf-next] bpf: Make trampolines W^X

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-next>] [day] [month] [year] [list]

Message-ID: <20200106221317.wpwut2rgw23tdaoo@ast-mbp>
Date:   Mon, 6 Jan 2020 14:13:18 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Andy Lutomirski <luto@...capital.net>
Cc:     Justin Capella <justincapella@...il.com>,
        KP Singh <kpsingh@...omium.org>,
        Rick Edgecombe <rick.p.edgecombe@...el.com>,
        linux-kernel@...r.kernel.org, bpf@...r.kernel.org, x86@...nel.org,
        linux-security-module@...r.kernel.org,
        Kees Cook <keescook@...omium.org>,
        "David S. Miller" <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andriin@...com>,
        Thomas Garnier <thgarnie@...omium.org>,
        Florent Revest <revest@...omium.org>,
        Brendan Jackman <jackmanb@...omium.org>,
        Jann Horn <jannh@...gle.com>,
        Matthew Garrett <mjg59@...gle.com>,
        Michael Halcrow <mhalcrow@...gle.com>
Subject: Re: [PATCH bpf-next] bpf: Make trampolines W^X

On Sun, Jan 05, 2020 at 10:33:54AM +0900, Andy Lutomirski wrote:
> 
> >> On Jan 4, 2020, at 8:03 PM, Justin Capella <justincapella@...il.com> wrote:
> > 
> > I'm rather ignorant about this topic but it would make sense to check prior to making executable from a security standpoint wouldn't it? (In support of the (set_memory_ro + set_memory_x)
> > 
> 
> Maybe, depends if it’s structured in a way that’s actually helpful from a security perspective.
> 
> It doesn’t help that set_memory_x and friends are not optimized at all. These functions are very, very, very slow and adversely affect all CPUs.

That was one of the reason it wasn't done in the first.
Also ftrace trampoline break w^x as well.
Not sure what is the plan for ftrace, but for bpf trampoline I'm going to switch
to text_poke (without _bp) once tip bits get merged during next merge window.
Then bpf trampoline will be allocated as ro+x and text_poke will be used instead of memcpy.