public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Daney <ddaney.cavm@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: "Leonid Yegoshin" <Leonid.Yegoshin@imgtec.com>,
	"Linux MIPS Mailing List" <linux-mips@linux-mips.org>,
	Zubair.Kakakhel@imgtec.com, geert+renesas@glider.be,
	david.daney@cavium.com, "Peter Zijlstra" <peterz@infradead.org>,
	"Paul Gortmaker" <paul.gortmaker@windriver.com>,
	davidlohr@hp.com, "Maciej W. Rozycki" <macro@linux-mips.org>,
	chenhc@lemote.com, cl@linux.com, "Ingo Molnar" <mingo@kernel.org>,
	"Richard Weinberger" <richard@nod.at>,
	"Rafał Miłecki" <zajec5@gmail.com>,
	"James Hogan" <james.hogan@imgtec.com>,
	"Tejun Heo" <tj@kernel.org>,
	alex@alex-smith.me.uk, "Paolo Bonzini" <pbonzini@redhat.com>,
	"John Crispin" <blogic@openwrt.org>,
	"Paul Burton" <paul.burton@imgtec.com>,
	qais.yousef@imgtec.com, LKML <linux-kernel@vger.kernel.org>,
	"Ralf Baechle" <ralf@linux-mips.org>,
	"Markos Chandras" <markos.chandras@imgtec.com>,
	dengcheng.zhu@imgtec.com, manuel.lauss@gmail.com,
	lars.persson@axis.com
Subject: Re: [PATCH v3 3/3] MIPS: set stack/data protection as non-executable
Date: Fri, 05 Dec 2014 11:06:44 -0800	[thread overview]
Message-ID: <54820244.5010304@gmail.com> (raw)
In-Reply-To: <CAGXu5jJJx0O7GhHghy+sC4fJL2O=RsO+Zgm78r9SNt-aTbhqcw@mail.gmail.com>

On 12/05/2014 10:51 AM, Kees Cook wrote:
> On Fri, Dec 5, 2014 at 9:28 AM, David Daney <ddaney.cavm@gmail.com> wrote:
>> On 12/02/2014 05:58 PM, Leonid Yegoshin wrote:
>>>
>>> This is a last step of 3 patches which shift FPU emulation out of
>>> stack into protected area. So, it disables a default executable stack.
>>>
>>> Additionally, it sets a default data area non-executable protection.
>>>
>>> Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
>>
>>
>> NAK!
>>
>> Some programs require an executable stack, this patch will break them.
>
> Have you tested this?

Do you require empirical evidence that the patch is incorrect, or is it 
enough to just to trust me when I say that it is incorrect?  Typically 
the burden of proof is with those proposing the patches.

>
>> You can only select a non-executable stack in response to PT_GNU_STACK
>> program headers in the ELF file of the executable program.
>
> This is already handled by fs/binfmt_elf.c. It does the parsing of the
> PT_GNU_STACK needs, and sets up the stack flags appropriately. All the
> change to VM_DATA_DEFAULT_FLAGS does is make sure that EXSTACK_DEFAULT
> now means no VM_EXEC by default. If PT_GNU_STACK requires it, it gets
> added back in.
>

The problem is not with "modern" executables that are properly annotated 
with PT_GNU_STACK.

My objection is to the intentional breaking of old executables that have 
no PT_GNU_STACK annotation, but require an executable stack.  Since we 
usually try not to break userspace, we cannot merge a patch like this one.

David Daney.


> -Kees
>
>>
>> David Daney
>>
>>
>>
>>> ---
>>>    arch/mips/include/asm/page.h |    2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h
>>> index 3be81803595d..d49ba81cb4ed 100644
>>> --- a/arch/mips/include/asm/page.h
>>> +++ b/arch/mips/include/asm/page.h
>>> @@ -230,7 +230,7 @@ extern int __virt_addr_valid(const volatile void
>>> *kaddr);
>>>    #define virt_addr_valid(kaddr)
>>> \
>>>          __virt_addr_valid((const volatile void *) (kaddr))
>>>
>>> -#define VM_DATA_DEFAULT_FLAGS  (VM_READ | VM_WRITE | VM_EXEC | \
>>> +#define VM_DATA_DEFAULT_FLAGS  (VM_READ | VM_WRITE | \
>>>                                   VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
>>>
>>>    #define UNCAC_ADDR(addr)      ((addr) - PAGE_OFFSET + UNCAC_BASE)
>>>
>>>
>>>
>>>
>>
>
>
>


  reply	other threads:[~2014-12-05 19:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-03  1:57 [PATCH v3 0/3] Series short description Leonid Yegoshin
2014-12-03  1:58 ` [PATCH v3 1/3] MIPS: mips_flush_cache_range is added Leonid Yegoshin
2014-12-03  1:58 ` [PATCH v3 2/3] MIPS: Setup an instruction emulation in VDSO protected page instead of user stack Leonid Yegoshin
2014-12-03  1:58 ` [PATCH v3 3/3] MIPS: set stack/data protection as non-executable Leonid Yegoshin
2014-12-05 17:28   ` David Daney
2014-12-05 18:51     ` Kees Cook
2014-12-05 19:06       ` David Daney [this message]
2014-12-05 19:41         ` Leonid Yegoshin
2014-12-05 19:41         ` Kees Cook
2014-12-05 19:44         ` Christoph Lameter
2014-12-05 21:41           ` David Daney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54820244.5010304@gmail.com \
    --to=ddaney.cavm@gmail.com \
    --cc=Leonid.Yegoshin@imgtec.com \
    --cc=Zubair.Kakakhel@imgtec.com \
    --cc=alex@alex-smith.me.uk \
    --cc=blogic@openwrt.org \
    --cc=chenhc@lemote.com \
    --cc=cl@linux.com \
    --cc=david.daney@cavium.com \
    --cc=davidlohr@hp.com \
    --cc=dengcheng.zhu@imgtec.com \
    --cc=geert+renesas@glider.be \
    --cc=james.hogan@imgtec.com \
    --cc=keescook@chromium.org \
    --cc=lars.persson@axis.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@linux-mips.org \
    --cc=manuel.lauss@gmail.com \
    --cc=markos.chandras@imgtec.com \
    --cc=mingo@kernel.org \
    --cc=paul.burton@imgtec.com \
    --cc=paul.gortmaker@windriver.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=qais.yousef@imgtec.com \
    --cc=ralf@linux-mips.org \
    --cc=richard@nod.at \
    --cc=tj@kernel.org \
    --cc=zajec5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox