All of lore.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: 15+ 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:57 ` 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   ` 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   ` Leonid Yegoshin
2014-12-03  1:58 ` [PATCH v3 3/3] MIPS: set stack/data protection as non-executable Leonid Yegoshin
2014-12-03  1:58   ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.