From: Kees Cook <keescook@chromium.org>
To: Tiezhu Yang <yangtiezhu@loongson.cn>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
Xuefeng Li <lixuefeng@loongson.cn>,
Juxin Gao <gaojuxin@loongson.cn>
Subject: Re: [PATCH] MIPS: Prevent READ_IMPLIES_EXEC propagation
Date: Wed, 8 Jul 2020 16:26:09 -0700 [thread overview]
Message-ID: <202007081624.82FA0CC1EA@keescook> (raw)
In-Reply-To: <1594114741-26852-1-git-send-email-yangtiezhu@loongson.cn>
On Tue, Jul 07, 2020 at 05:39:01PM +0800, Tiezhu Yang wrote:
> In the MIPS architecture, we should clear the security-relevant
> flag READ_IMPLIES_EXEC in the function SET_PERSONALITY2() of the
> file arch/mips/include/asm/elf.h.
>
> Otherwise, with this flag set, PROT_READ implies PROT_EXEC for
> mmap to make memory executable that is not safe, because this
> condition allows an attacker to simply jump to and execute bytes
> that are considered to be just data [1].
>
> In mm/mmap.c:
> unsigned long do_mmap(struct file *file, unsigned long addr,
> unsigned long len, unsigned long prot,
> unsigned long flags, vm_flags_t vm_flags,
> unsigned long pgoff, unsigned long *populate,
> struct list_head *uf)
> {
> [...]
> if ((prot & PROT_READ) && (current->personality & READ_IMPLIES_EXEC))
> if (!(file && path_noexec(&file->f_path)))
> prot |= PROT_EXEC;
> [...]
> }
>
> By the way, x86 and ARM64 have done the similar thing.
>
> After commit 250c22777fe1 ("x86_64: move kernel"), in the file
> arch/x86/kernel/process_64.c:
> void set_personality_64bit(void)
> {
> [...]
> current->personality &= ~READ_IMPLIES_EXEC;
> }
>
> After commit 48f99c8ec0b2 ("arm64: Preventing READ_IMPLIES_EXEC
> propagation"), in the file arch/arm64/include/asm/elf.h:
> #define SET_PERSONALITY(ex) \
> ({ \
> clear_thread_flag(TIF_32BIT); \
> current->personality &= ~READ_IMPLIES_EXEC; \
> })
>
> [1] https://insights.sei.cmu.edu/cert/2014/02/feeling-insecure-blame-your-parent.html
>
> Reported-by: Juxin Gao <gaojuxin@loongson.cn>
> Co-developed-by: Juxin Gao <gaojuxin@loongson.cn>
> Signed-off-by: Juxin Gao <gaojuxin@loongson.cn>
> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
This seems correct to me.
Reviewed-by: Kees Cook <keescook@chromium.org>
BTW, does MIPS also need similar changes to this series:
https://lore.kernel.org/lkml/20200327064820.12602-1-keescook@chromium.org/
Quoting from there "MIPS may need adjusting but the history of CPU
features and toolchain behavior is very unclear to me."
--
Kees Cook
next prev parent reply other threads:[~2020-07-08 23:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-07 9:39 [PATCH] MIPS: Prevent READ_IMPLIES_EXEC propagation Tiezhu Yang
2020-07-07 19:45 ` Maciej W. Rozycki
2020-07-08 7:51 ` Tiezhu Yang
2020-07-17 10:00 ` Maciej W. Rozycki
2020-07-18 0:04 ` YunQiang Su
2020-07-18 3:59 ` Tiezhu Yang
2020-07-18 4:45 ` YunQiang Su
2020-07-08 23:26 ` Kees Cook [this message]
2020-07-16 11:59 ` Thomas Bogendoerfer
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=202007081624.82FA0CC1EA@keescook \
--to=keescook@chromium.org \
--cc=gaojuxin@loongson.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=lixuefeng@loongson.cn \
--cc=tsbogend@alpha.franken.de \
--cc=yangtiezhu@loongson.cn \
/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.