public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Joerg Roedel <joerg.roedel@amd.com>,
	kvm@vger.kernel.org, yoshikawa.takuya@oss.ntt.co.jp,
	avi@redhat.com, mtosatti@redhat.com
Subject: Re: [PATCH 1/3] KVM: x86 emulator: Fix task switch privilege checks
Date: Tue, 24 Jan 2012 18:23:50 +0200	[thread overview]
Message-ID: <20120124162350.GD538@redhat.com> (raw)
In-Reply-To: <4F1EBF32.6020904@redhat.com>

On Tue, Jan 24, 2012 at 03:24:50PM +0100, Kevin Wolf wrote:
> Am 24.01.2012 15:16, schrieb Gleb Natapov:
> > On Tue, Jan 24, 2012 at 03:15:13PM +0100, Kevin Wolf wrote:
> >> Am 24.01.2012 15:03, schrieb Joerg Roedel:
> >>> On Mon, Jan 23, 2012 at 05:10:46PM +0100, Kevin Wolf wrote:
> >>>> This patch fixes the problem for VMX. For SVM, the logic used to
> >>>> determine the source of the task switch is buggy, so we can't pass
> >>>> useful information to the emulator there and just disable the check in
> >>>> all cases.
> >>>
> >>> Actually, SVM isn't buggy :) For SVM you do not need to do any
> >>> priviledge checks in software because the hardware already takes care of
> >>> that.
> >>> In other words, KVM only gets a task-switch intercept if the priviledges
> >>> are all checked and correct.
> >>
> >> Okay, that's good to hear. The current code is still buggy because as
> >> Gleb noted it checks against the TSS DPL. We need to disable that check
> >> for SVM then. Also all checks for TASK_SWITCH_GATE indicate that
> >> something is wrong because it will never happen.
> >>
> > Not necessary. Currently all checks for TASK_SWITCH_GATE also check for
> > TASK_SWITCH_CALL, so I think you can fix SVM case in your patch by
> > passing TASK_SWITCH_GATE instead of TASK_SWITCH_CALL to
> > kvm_task_switch().
> 
> Yes, the emulator itself would be fixed by passing TASK_SWITCH_GATE and
> idt_index = -1 (although it looks a bit brittle).
> 
I think it is OK. Emulator should emulate the spec and if workaround is
needed it should be in platform code. By passing TASK_SWITCH_GATE and
idt_index = -1 we do exactly that.

> However, task_switch_interception() itself does some more based on the
> value of reason, for example it decides whether or not to call
> skip_emulated_instruction().
> 
Joerg need to help us here. If intercept of task switch happens before
rip is advanced past instruction that cause it we have to know somehow
that task switch was caused by instruction. It is not enough that HW
checks permission, we still lack essential info.

--
			Gleb.

  reply	other threads:[~2012-01-24 16:23 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-23 16:10 [PATCH 0/3] Fix task switches into/out of VM86 Kevin Wolf
2012-01-23 16:10 ` [PATCH 1/3] KVM: x86 emulator: Fix task switch privilege checks Kevin Wolf
2012-01-24  9:52   ` Gleb Natapov
2012-01-24 10:09     ` Kevin Wolf
2012-01-24 10:17       ` Gleb Natapov
2012-01-24 10:38         ` Kevin Wolf
2012-01-24 10:52           ` Gleb Natapov
2012-01-24 11:23             ` Kevin Wolf
2012-01-24 11:25               ` Gleb Natapov
2012-01-24 14:03   ` Joerg Roedel
2012-01-24 14:15     ` Kevin Wolf
2012-01-24 14:16       ` Gleb Natapov
2012-01-24 14:24         ` Kevin Wolf
2012-01-24 16:23           ` Gleb Natapov [this message]
2012-01-25 16:00             ` Joerg Roedel
2012-01-25 18:29               ` Gleb Natapov
2012-01-27 12:58               ` Kevin Wolf
2012-01-27 13:34                 ` Joerg Roedel
2012-01-27 13:55                   ` Kevin Wolf
2012-01-27 14:17                     ` Joerg Roedel
2012-01-27 15:02                       ` Kevin Wolf
2012-01-27 15:45                         ` Gleb Natapov
2012-01-23 16:10 ` [PATCH 2/3] KVM: x86 emulator: VM86 segments must have DPL 3 Kevin Wolf
2012-01-23 16:10 ` [PATCH 3/3] KVM: x86 emulator: Allow PM/VM86 switch during task switch Kevin Wolf
2012-01-24 10:57   ` Gleb Natapov
2012-01-24 11:31     ` Kevin Wolf
2012-01-24 11:37       ` Gleb Natapov
2012-01-24 11:44         ` Kevin Wolf

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=20120124162350.GD538@redhat.com \
    --to=gleb@redhat.com \
    --cc=avi@redhat.com \
    --cc=joerg.roedel@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwolf@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=yoshikawa.takuya@oss.ntt.co.jp \
    /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