From: "H. Peter Anvin" <hpa@zytor.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Randy Dunlap <rdunlap@xenotime.net>,
Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Arjan van de Ven <arjan@linux.intel.com>
Subject: Re: On the correctness of dbe3ed1c078c193be34326728d494c5c4bc115e2
Date: Sun, 01 Sep 2013 09:10:29 -0700 [thread overview]
Message-ID: <522366F5.5080002@zytor.com> (raw)
In-Reply-To: <CA+55aFwUKyJwphC7EFCgQKGLfZq1yrjx+4CrMhJeVmxFr8QNdg@mail.gmail.com>
On 09/01/2013 08:58 AM, Linus Torvalds wrote:
> On Sun, Sep 1, 2013 at 5:20 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> This has the end result that we treat a user space instruction which
>> touches a privileged data structure that then page faults (e.g. a
>> segment load which causes #PF on the GDT) as a user-space fault.
>>
>> This seems very wrong to me, since such a #PF would indicate a serious
>> error in the kernel.
>
> Not necessarily. Don't we basically do exactly that for the F00F bug
> workaround, for example?
>
> Linus
>
Actually, from looking at it, the F00F workaround is broken *exactly*
because of this patch. By forcing PF_USER to set, we go into the
if (error_code & PF_USER) branch of __bad_area_semaphore(), which means
we *don't* do the F00F checking, and will deliver a SIGSEGV with the IDT
address to the user space process instead of SIGILL.
-hpa
prev parent reply other threads:[~2013-09-01 16:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-01 12:20 On the correctness of dbe3ed1c078c193be34326728d494c5c4bc115e2 H. Peter Anvin
2013-09-01 15:58 ` Linus Torvalds
2013-09-01 16:00 ` H. Peter Anvin
2013-09-01 16:12 ` Linus Torvalds
2013-09-01 16:13 ` H. Peter Anvin
2013-09-01 16:10 ` H. Peter Anvin [this message]
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=522366F5.5080002@zytor.com \
--to=hpa@zytor.com \
--cc=arjan@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=rdunlap@xenotime.net \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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.