mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nadav Amit <nadav.amit@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	kvm list <kvm@vger.kernel.org>,
	Nadav Amit <namit@cs.technion.ac.il>,
	stable@vger.kernel.org
Subject: Re: [PATCH 05/14] KVM: x86: Emulator fixes for eip canonical checks on near branches
Date: Sat, 25 Oct 2014 22:57:55 +0300	[thread overview]
Message-ID: <4C1F2620-8DFD-4F62-B9D3-4B241459AEE0@gmail.com> (raw)
In-Reply-To: <544A922B.5070505@amacapital.net>


> On Oct 24, 2014, at 20:53, Andy Lutomirski <luto@amacapital.net> wrote:
> 
> On 10/24/2014 08:07 AM, Paolo Bonzini wrote:
>> From: Nadav Amit <namit@cs.technion.ac.il>
>> 
>> Before changing rip (during jmp, call, ret, etc.) the target should be asserted
>> to be canonical one, as real CPUs do.  During sysret, both target rsp and rip
>> should be canonical. If any of these values is noncanonical, a #GP exception
>> should occur.  The exception to this rule are syscall and sysenter instructions
>> in which the assigned rip is checked during the assignment to the relevant
>> MSRs.
> 
> Careful here.  AMD CPUs (IIUC) send #PF (or maybe #GP) from CPL3 instead
> of #GP from CPL0 on sysret to a non-canonical address.  That behavior is
> *far* better than the Intel behavior, and it may be important.
I wasn’t aware of this discrepancy, and it is really not written clearly in AMD manual (I have to take your word). It is possible AMD decided to inject #GP from CPL3 (#PF makes no sense).

Anyhow, I think it is much harder to emulate AMD’s behaviour on Intel. Theoretically, the easy way would be for the host to set a non-canonical guest RIP/RSP and inject #GP, but Intel CPUs don’t allow the host to do so. Instead, the host needs to emulate the entire exception injection. This is very hard and error-prone process due to the variety of scenarios (interrupt/task-gate on the IDT, #DF, nested-exceptions, etc.)


> 
> If an OS relies on that behavior on AMD CPUs, and guest ring 3 can force
> guest ring 0 to do an emulated sysret to a non-canonical address, than
> the guest ring3 code can own the guest ring0 code.
> 
> —Andy

Sysexit (I mistakenly wrote sysret on the description), out of all the control transfer instructions, seems the hardest to exploit, since it must be executed in CPL0.
Remember that this bug does not result in host crashing, but in guest crashing: If guest userspace is able to cause KVM to emulate a jump instruction to a non-canonical address, it can crash the entire guest (by preventing VM-entry from succeeding). To use sysexit for such exploit, the guest userspace needs also to somehow fool the guest kernel into returning into non-canonical RIP.

Nadav

  reply	other threads:[~2014-10-25 19:58 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-24 15:07 [PATCH 00/14] KVM changes for 3.18-rc2 Paolo Bonzini
2014-10-24 15:07 ` [PATCH 01/14] KVM: x86: Check non-canonical addresses upon WRMSR Paolo Bonzini
2014-10-24 15:07 ` [PATCH 02/14] KVM: x86: Prevent host from panicking on shared MSR writes Paolo Bonzini
2014-10-24 15:07 ` [PATCH 03/14] KVM: x86: Improve thread safety in pit Paolo Bonzini
2014-10-24 15:07 ` [PATCH 04/14] KVM: x86: Fix wrong masking on relative jump/call Paolo Bonzini
2014-10-24 15:07 ` [PATCH 05/14] KVM: x86: Emulator fixes for eip canonical checks on near branches Paolo Bonzini
2014-10-24 17:53   ` Andy Lutomirski
2014-10-25 19:57     ` Nadav Amit [this message]
2014-10-25 23:51       ` Andy Lutomirski
2014-10-24 15:07 ` [PATCH 06/14] KVM: x86: Handle errors when RIP is set during far jumps Paolo Bonzini
2014-10-24 15:07 ` [PATCH 07/14] kvm: vmx: handle invvpid vm exit gracefully Paolo Bonzini
2014-10-24 15:07 ` [PATCH 08/14] kvm: x86: don't kill guest on unknown exit reason Paolo Bonzini
2014-10-24 17:57   ` Andy Lutomirski
2014-10-24 21:54     ` Paolo Bonzini
2014-10-24 22:26       ` Andy Lutomirski
2014-10-24 15:07 ` [PATCH 09/14] KVM: x86: Decoding guest instructions which cross page boundary may fail Paolo Bonzini
2014-10-24 15:07 ` [PATCH 10/14] KVM: emulate: avoid accessing NULL ctxt->memopp Paolo Bonzini
2014-10-24 15:07 ` [PATCH 11/14] KVM: x86: Emulator does not decode clflush well Paolo Bonzini
2014-10-24 15:07 ` [PATCH 12/14] KVM: x86: PREFETCH and HINT_NOP should have SrcMem flag Paolo Bonzini
2014-10-24 15:07 ` [PATCH 13/14] kvm: fix excessive pages un-pinning in kvm_iommu_map error path Paolo Bonzini
2014-10-24 15:58   ` Quentin Casasnovas
2014-10-24 15:07 ` [PATCH 14/14] KVM: x86: Wrong assertion on paging_tmpl.h Paolo Bonzini

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=4C1F2620-8DFD-4F62-B9D3-4B241459AEE0@gmail.com \
    --to=nadav.amit@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=namit@cs.technion.ac.il \
    --cc=pbonzini@redhat.com \
    --cc=stable@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®