[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b999a736-8ad6-824f-36aa-e7c4cb7e467d@caviumnetworks.com>
Date: Fri, 1 Dec 2017 09:38:20 -0800
From: David Daney <ddaney@...iumnetworks.com>
To: Miodrag Dinic <Miodrag.Dinic@...s.com>,
James Hogan <James.Hogan@...s.com>
Cc: Aleksandar Markovic <aleksandar.markovic@...rk.com>,
"linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>,
Aleksandar Markovic <Aleksandar.Markovic@...s.com>,
Andrew Morton <akpm@...ux-foundation.org>,
DengCheng Zhu <DengCheng.Zhu@...s.com>,
Ding Tianhong <dingtianhong@...wei.com>,
Douglas Leung <Douglas.Leung@...s.com>,
Frederic Weisbecker <frederic@...nel.org>,
Goran Ferenc <Goran.Ferenc@...s.com>,
Ingo Molnar <mingo@...nel.org>,
James Cowgill <James.Cowgill@...tec.com>,
Jonathan Corbet <corbet@....net>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Marc Zyngier <marc.zyngier@....com>,
Matt Redfearn <Matt.Redfearn@...s.com>,
Mimi Zohar <zohar@...ux.vnet.ibm.com>,
Paul Burton <Paul.Burton@...s.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Petar Jovanovic <Petar.Jovanovic@...s.com>,
Raghu Gandham <Raghu.Gandham@...s.com>,
Ralf Baechle <ralf@...ux-mips.org>,
Thomas Gleixner <tglx@...utronix.de>,
Tom Saeger <tom.saeger@...cle.com>
Subject: Re: [PATCH v2] MIPS: Add nonxstack=on|off kernel parameter
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@...tec.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@...tec.com>
> Cc: Leonid Yegoshin <leonid.yegoshin@...tec.com>
> Cc: Maciej Rozycki <maciej.rozycki@...tec.com>
> Cc: Faraz Shahbazker <faraz.shahbazker@...tec.com>
> Cc: Raghu Gandham <raghu.gandham@...tec.com>
> Cc: Matthew Fortune <matthew.fortune@...tec.com>
> Cc: linux-mips@...ux-mips.org
> Patchwork: https://patchwork.linux-mips.org/patch/13765/
> Signed-off-by: Ralf Baechle <ralf@...ux-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.
Powered by blists - more mailing lists