linux-mips
[Top] [All Lists]

Re: [PATCH v2] MIPS: Add nonxstack=on|off kernel parameter

To: Miodrag Dinic <Miodrag.Dinic@mips.com>, James Hogan <James.Hogan@mips.com>
Subject: Re: [PATCH v2] MIPS: Add nonxstack=on|off kernel parameter
From: David Daney <ddaney@caviumnetworks.com>
Date: Fri, 1 Dec 2017 09:38:20 -0800
Authentication-results: spf=none (sender IP is ) smtp.mailfrom=David.Daney@cavium.com;
Cc: Aleksandar Markovic <aleksandar.markovic@rt-rk.com>, "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>, Aleksandar Markovic <Aleksandar.Markovic@mips.com>, Andrew Morton <akpm@linux-foundation.org>, DengCheng Zhu <DengCheng.Zhu@mips.com>, Ding Tianhong <dingtianhong@huawei.com>, Douglas Leung <Douglas.Leung@mips.com>, Frederic Weisbecker <frederic@kernel.org>, Goran Ferenc <Goran.Ferenc@mips.com>, Ingo Molnar <mingo@kernel.org>, James Cowgill <James.Cowgill@imgtec.com>, Jonathan Corbet <corbet@lwn.net>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Marc Zyngier <marc.zyngier@arm.com>, Matt Redfearn <Matt.Redfearn@mips.com>, Mimi Zohar <zohar@linux.vnet.ibm.com>, Paul Burton <Paul.Burton@mips.com>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, Petar Jovanovic <Petar.Jovanovic@mips.com>, Raghu Gandham <Raghu.Gandham@mips.com>, Ralf Baechle <ralf@linux-mips.org>, Thomas Gleixner <tglx@linutronix.de>, Tom Saeger <tom.saeger@oracle.com>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IGKj7UexG+a5w0+r6nIY6t/6igrPamG6rqz/JAHnqnE=; b=HacDo2fSJ9ozPN6SBOqmCnHS84MQ3sMAeh/Zd1UOF6NDblGSdHgzj35v96ySQliPRyxYc0GZI2EJxtbLxzBL21S+1xz8uQvTwyyooBhFzssQjElPqX81uGe4TbzyAbMe61vs376ESahva6mXk/+ASZlMpsNAcpV6dmNweMVNUtI=
In-reply-to: <48924BBB91ABDE4D9335632A6B179DD6A8D102@MIPSMAIL01.mipstec.com>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <1511272574-10509-1-git-send-email-aleksandar.markovic@rt-rk.com> <dda5572e-0617-3427-7a90-07b3cf43d808@caviumnetworks.com> <48924BBB91ABDE4D9335632A6B179DD6A8CFEA@MIPSMAIL01.mipstec.com> <20171130100957.GG5027@jhogan-linux.mipstec.com> <48924BBB91ABDE4D9335632A6B179DD6A8D102@MIPSMAIL01.mipstec.com>
Sender: linux-mips-bounce@linux-mips.org
Spamdiagnosticmetadata: NSPM
Spamdiagnosticoutput: 1:99
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
On 11/30/2017 05:06 AM, Miodrag Dinic wrote:
Hi James,

We do have PT_GNU_STACK flags set correctly, this feature is required to
workaround CPU revisions which do not have RIXI support.

RIXI support can be discovered programatically from CP0_Config3.RXI
(cpu_has_rixi in asm/cpu-features.h), so I don't follow why CPUs without
RIXI would require a kernel parameter.

The following patch introduced change in behavior with regards to
stack & heap execute-ability :
commit 1a770b85c1f1c1ee37afd7cef5237ffc4c970f04
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Fri Jul 8 11:06:20 2016 +0100

     MIPS: non-exec stack & heap when non-exec PT_GNU_STACK is present
The stack and heap have both been executable by default on MIPS until
     now. This patch changes the default to be non-executable, but only for
     ELF binaries with a non-executable PT_GNU_STACK header present. This
     does apply to both the heap & the stack, despite the name PT_GNU_STACK,
     and this matches the behaviour of other architectures like ARM & x86.
Current MIPS toolchains do not produce the PT_GNU_STACK header, which
     means that we can rely upon this patch not changing the behaviour of
     existing binaries. The new default will only take effect for newly
     compiled binaries once toolchains are updated to support PT_GNU_STACK,
     and since those binaries are newly compiled they can be compiled
     expecting the change in default behaviour. Again this matches the way in
     which the ARM & x86 architectures handled their implementations of
     non-executable memory.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
     Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
     Cc: Maciej Rozycki <maciej.rozycki@imgtec.com>
     Cc: Faraz Shahbazker <faraz.shahbazker@imgtec.com>
     Cc: Raghu Gandham <raghu.gandham@imgtec.com>
     Cc: Matthew Fortune <matthew.fortune@imgtec.com>
     Cc: linux-mips@linux-mips.org
     Patchwork: https://patchwork.linux-mips.org/patch/13765/
     Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

....

When kernel is detecting the type of mapping it should apply :

fs/binfmt_elf.c:
...
        if (elf_read_implies_exec(loc->elf_ex, executable_stack))
                current->personality |= READ_IMPLIES_EXEC;
...

this effectively calls mips_elf_read_implies_exec() which performs a check:
...
        if (!cpu_has_rixi) {
                /* The CPU doesn't support non-executable memory */
                return 1;
        }

        return 0;
}

This will in turn make stack & heap executable on processors without RIXI, which 
are practically all processors with MIPS ISA R < 6.


All Cavium processors since OCTEON Plus (more than ten years ago) support RIXI.

We would like to have an option to override this and force non-executable 
mappings for such systems.

This is what I don't understand. If a system doesn't support XI, then no mapping can possibly be non-executable.

There may be some utility in disabling the use of the RIXI bits on systems that do support them. But no command line can conjure functional RIXI on systems that don't support it.

Also, this does nothing for multi-threaded programs where libc sets the permissions on the thread stacks.

If you really need something, at a minimum, use the same parameter name that x86 uses.



<Prev in Thread] Current Thread [Next in Thread>