From: Borislav Petkov <bp@alien8.de>
To: Andy Lutomirski <luto@kernel.org>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
Kees Cook <keescook@chromium.org>,
Brian Gerst <brgerst@gmail.com>
Subject: Re: [PATCH 5/7] x86/uaccess: Warn on uaccess faults other than #PF
Date: Wed, 25 May 2016 11:49:07 +0200 [thread overview]
Message-ID: <20160525094906.GA4420@pd.tnic> (raw)
In-Reply-To: <5bcff14f574b1a9852d1334a9fa8886c70c928c4.1464129798.git.luto@kernel.org>
On Tue, May 24, 2016 at 03:48:42PM -0700, Andy Lutomirski wrote:
> If a uaccess instruction fails due to an8 error other than #PF,
> warn. If the fault is #GP, it most likely indicates access to a
> non-canonical address, which means that an access_ok check is
> missing, and that's bad. If the fault is something else (#UD?),
> then something is very wrong and we should diagnose it rather
> than ignoring it.
>
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> ---
> arch/x86/mm/extable.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
> index 658292fdee5e..c1933471fce7 100644
> --- a/arch/x86/mm/extable.c
> +++ b/arch/x86/mm/extable.c
> @@ -29,6 +29,19 @@ EXPORT_SYMBOL(ex_handler_default);
> static bool uaccess_fault_okay(int trapnr, unsigned long error_code,
> unsigned long extra)
> {
> + /*
> + * For uaccess, only page faults should be fixed up. I can't see
> + * any exploit mitigation value in OOPSing on other types of faults,
> + * so just warn and continue if that happens. This means that
> + * uaccess faults to non-canonical addresses will warn. That's okay
> + * -- this will only happen if an access_ok is missing, and we want to
> + * detect that error if it happens.
> + */
> + if (WARN_ONCE(trapnr != X86_TRAP_PF,
> + "unexpected uaccess trap %d (may indicate a missing access_ok on a non-canonical address)\n",
> + trapnr))
Perhaps dump also regs->ip and make the warn message more helpful...
> + return true; /* no good reason to OOPS. */
You love those side comments, don'tcha? :-)
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
next prev parent reply other threads:[~2016-05-25 9:49 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-24 22:48 [PATCH 0/7] x86: uaccess hardening, easy part Andy Lutomirski
2016-05-24 22:48 ` [PATCH 1/7] x86/xen: Simplify set_aliased_prot Andy Lutomirski
2016-05-24 22:48 ` Andy Lutomirski
2016-05-25 9:38 ` Andrew Cooper
2016-05-25 9:38 ` Andrew Cooper
2016-05-25 9:50 ` David Vrabel
2016-05-25 9:50 ` [Xen-devel] " David Vrabel
2016-06-10 22:12 ` Andy Lutomirski
2016-06-11 9:29 ` Ingo Molnar
2016-06-11 9:29 ` Ingo Molnar
2016-06-10 22:12 ` Andy Lutomirski
2016-06-11 9:34 ` [tip:x86/asm] x86/xen: Simplify set_aliased_prot() tip-bot for Andy Lutomirski
2016-06-11 9:34 ` tip-bot for Andy Lutomirski
2016-05-24 22:48 ` [PATCH 2/7] x86/extable: Pass error_code and an extra unsigned long to exhandlers Andy Lutomirski
2016-05-24 22:48 ` [PATCH 3/7] x86/uaccess: Give uaccess faults their own handler Andy Lutomirski
2016-05-24 22:48 ` [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it Andy Lutomirski
2016-05-25 11:32 ` Borislav Petkov
2016-05-29 16:44 ` Andy Lutomirski
2016-05-25 11:39 ` Borislav Petkov
2016-05-29 16:47 ` Andy Lutomirski
2016-05-29 18:42 ` Boris Petkov
2016-05-29 19:08 ` Andy Lutomirski
2016-05-30 7:40 ` Borislav Petkov
2016-05-24 22:48 ` [PATCH 5/7] x86/uaccess: Warn on uaccess faults other than #PF Andy Lutomirski
2016-05-25 9:49 ` Borislav Petkov [this message]
2016-05-29 16:42 ` Andy Lutomirski
2016-05-24 22:48 ` [PATCH 6/7] x86/uaccess: Don't fix up USER_DS uaccess faults to kernel addresses Andy Lutomirski
2016-05-24 22:48 ` [PATCH 7/7] x86/uaccess: OOPS or warn on a fault with KERNEL_DS and !pagefault_disabled() Andy Lutomirski
2016-05-25 15:33 ` Borislav Petkov
2016-05-29 16:52 ` Andy Lutomirski
2016-05-25 3:55 ` [PATCH 0/7] x86: uaccess hardening, easy part Brian Gerst
2016-05-25 17:19 ` Kees Cook
2016-05-25 17:31 ` Kees Cook
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=20160525094906.GA4420@pd.tnic \
--to=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=x86@kernel.org \
/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.