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 S1426012AbdEZJ2N (ORCPT <rfc822;w@1wt.eu>);
        Fri, 26 May 2017 05:28:13 -0400
Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:55618 "EHLO
        mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1753590AbdEZJ1Y (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 26 May 2017 05:27:24 -0400
Date: Fri, 26 May 2017 11:27:16 +0200
From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: 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>,
        Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [PATCH V2] x86/ftrace: Make sure that ftrace trampolines are not
 RWX
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.20.1705260859290.1902@nanos>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-TM-AS-GCONF: 00
x-cbid: 17052609-0040-0000-0000-000003B79843
X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused
x-cbparentid: 17052609-0041-0000-0000-00002046E214
Message-Id: <20170526092716.GA14849@osiris>
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-26_06:,,
 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0
 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam
 adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000
 definitions=main-1705260173
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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).