From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S967455AbdEZLkt (ORCPT <rfc822;w@1wt.eu>);
        Fri, 26 May 2017 07:40:49 -0400
Received: from ozlabs.org ([103.22.144.67]:47263 "EHLO ozlabs.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753586AbdEZLkr (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 26 May 2017 07:40:47 -0400
From: Michael Ellerman <mpe@ellerman.id.au>
To: Heiko Carstens <heiko.carstens@de.ibm.com>,
        Thomas Gleixner <tglx@linutronix.de>
Cc: Kees Cook <keescook@chromium.org>,
        "Luis R. Rodriguez" <mcgrof@kernel.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        LKML <linux-kernel@vger.kernel.org>,
        "x86\@kernel.org" <x86@kernel.org>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH V2] x86/ftrace: Make sure that ftrace trampolines are not RWX
In-Reply-To: <20170526092716.GA14849@osiris>
References: <alpine.DEB.2.20.1705241459480.2201@nanos> <20170524134728.61a896c9@vmware.local.home> <alpine.DEB.2.20.1705242112210.2283@nanos> <20170524182547.5c085dc7@vmware.local.home> <alpine.DEB.2.20.1705250813190.2329@nanos> <alpine.DEB.2.20.1705251056410.1862@nanos> <20170525174604.GY8951@wotan.suse.de> <CAGXu5j+=-3Po0SoO8N=LMzSTEA1y6sFnMQwq71Nwiw4dAXeABA@mail.gmail.com> <alpine.DEB.2.20.1705260859290.1902@nanos> <20170526092716.GA14849@osiris>
User-Agent: Notmuch/0.21 (https://notmuchmail.org)
Date: Fri, 26 May 2017 21:40:44 +1000
Message-ID: <87bmqf977n.fsf@concordia.ellerman.id.au>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Heiko Carstens <heiko.carstens@de.ibm.com> writes:

> On Fri, May 26, 2017 at 09:03:13AM +0200, Thomas Gleixner wrote:
>> > It seems like it really should. That would put it in a single place
>> > and avoid this mistake again in the future. Does module_memfree() have
>> > access to the allocation size, or does that need to get plumbed?
>> 
>> No, it doesn't. But the number of instances is pretty limited.
>> 
>> Btw, looking at BPF. It allocates memory via module_alloc() which means
>> it's RWX. There is nothing in that BPF code which changes the permissions
>> afterwards ....
>
> For BPF you're probably referring to bpf_jit_binary_alloc()? Permissions
> are changed with bpf_jit_binary_lock_ro() within each architecure backend.
>
> Well, except for powerpc (cc'ed Michael).

[hangs head in shame]

Thanks, we are working on this stuff (stricter RWX perms) at the moment,
so will add this to the list. It's complicated somewhat by the variety
of MMUs we support, but still.

cheers