All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Robert Święcki" <robert@swiecki.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Hurley <peter@hurleysoftware.com>,
	Jiri Slaby <jslaby@suse.cz>, Greg KH <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	stable <stable@vger.kernel.org>,
	lwn@lwn.net, Steven Rostedt <rostedt@goodmis.org>
Subject: Re: BUG: unable to handle kernel paging request from pty_write [was: Linux 4.4.2]
Date: Fri, 26 Feb 2016 20:59:59 +0100	[thread overview]
Message-ID: <CAP145phdemqK0hCSw9m5E2TZbrBojnzqAVZ97O5APtLA6Abr7g@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFzSeY35WB7GNPf6POW1vSqCVBdMQiJgy4OcgPXSdsmYrw@mail.gmail.com>

2016-02-26 20:44 GMT+01:00 Linus Torvalds <torvalds@linux-foundation.org>:

>> I've contacted Robert Święcki (who found the microcode problem) in
>> case he wants to weigh in in this thread.. He was talking to some AMD
>> people, but I don't know the exactly who.
>
> And since it's looking increasingly likely that it's the same issue,
> I'm adding Robert here explicitly to the cc so that he sees the
> thread...

Thx,

Some data I was able to gather:

It happens only with 0x6000832 ucode, and Piledriver-based CPUs: i.e.
newer AMD FX, and Opteron 300 series (4300, 6300 etc.).

The visible effects are in ~80% of cases incorrect RSP leading to bad
'rets' into kernel data/bss or stack-protector faults. But there are
also more elusive ones, like registers being cleared before use in
indirect memory fetches or so.

I can trigger it from within qemu guest (non-root), causing bad RIP in
the host kernel. When testing, a couple of times (maybe 2) out of
maybe 30 seen oopses, I was able to set it to user-space addresses
mapped in the guest. It greatly depends on timing, but I think with
some more effort and populating kernel stack with guest addresses it'd
be possible to create a more reliable qemu-guest to host ring0 escape.

I CC'd some AMD engineers from this list, and on of them replied with
"We are working on the final testing of a new microcode patch to
replace 0x06000832."
but without specifying any errata no, or ETA for the new ucode.

I can only now suggest not using 0x06000832 is possible (i.e. if it's
not embedded in BIOS), I tested a few from
http://www.amd64.org/microcode.html and only this version seemed
vulnerable.

PS. There's a bug on vmware pages -
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2061211
- which looks very similar to this problem (affects Opteron 6300 which
is Piledriver-based), and it was "somehow" patched by vmware in their
kernel. It points to AMD errata #815 -
http://support.amd.com/TechDocs/48063_15h_Mod_00h-0Fh_Rev_Guide.pdf -
but I cannot tell whether it's really the same problem, or whether it
can be somehow by-passed on the kernel side.

-- 
Robert Święcki

  reply	other threads:[~2016-02-26 20:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-26 18:05 BUG: unable to handle kernel paging request from pty_write [was: Linux 4.4.2] Linus Torvalds
2016-02-26 18:17 ` Borislav Petkov
2016-02-26 18:18 ` Peter Hurley
2016-02-26 19:44 ` Linus Torvalds
2016-02-26 19:59   ` Robert Święcki [this message]
2016-02-29  7:39     ` Jiri Slaby
2016-02-29 12:43       ` Henrique de Moraes Holschuh
  -- strict thread matches above, loose matches on Subject: below --
2016-02-17 20:37 Linux 4.4.2 Greg KH
2016-02-25 10:12 ` BUG: unable to handle kernel paging request from pty_write [was: Linux 4.4.2] Jiri Slaby
2016-02-25 18:40   ` Peter Hurley
2016-02-25 19:09     ` Linus Torvalds
2016-02-25 19:23       ` Steven Rostedt
2016-02-26  8:25         ` Jiri Slaby
2016-02-25 20:32       ` Peter Hurley
2016-02-25 20:51         ` Linus Torvalds
2016-02-25 21:32           ` Jiri Slaby
2016-02-25 22:33             ` Peter Hurley
2016-02-26  0:38               ` Peter Hurley
2016-02-26  8:45                 ` Jiri Slaby
2016-02-26  0:38             ` Linus Torvalds
2016-02-26  8:56               ` Jiri Slaby
2016-02-26  9:23                 ` Jiri Slaby
2016-02-26  9:50                   ` Jiri Slaby
2016-02-26 16:34                     ` Greg KH
2016-02-26 17:12                 ` Linus Torvalds
2016-02-29 15:45                   ` Paolo Bonzini
2016-02-26 17:52                 ` Peter Hurley
2016-02-25 21:43           ` Peter Hurley
2016-02-25 22:00           ` Jiri Kosina
2016-02-26  8:31             ` Jiri Slaby
2016-02-26  8:15     ` Jiri Slaby

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=CAP145phdemqK0hCSw9m5E2TZbrBojnzqAVZ97O5APtLA6Abr7g@mail.gmail.com \
    --to=robert@swiecki.net \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lwn@lwn.net \
    --cc=peter@hurleysoftware.com \
    --cc=rostedt@goodmis.org \
    --cc=stable@vger.kernel.org \
    --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.