Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752642AbdFOVpH (ORCPT ); Thu, 15 Jun 2017 17:45:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:35946 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751641AbdFOVpF (ORCPT ); Thu, 15 Jun 2017 17:45:05 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A8408239CC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org MIME-Version: 1.0 In-Reply-To: References: From: Andy Lutomirski Date: Thu, 15 Jun 2017 14:44:38 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] KVM: SVM: do not drop VMCB CPL to 0 if SS is not present To: Paolo Bonzini Cc: Roman Penyaev , Mikhail Sennikovskii , Gleb Natapov , kvm list , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1888 Lines: 43 On Tue, May 30, 2017 at 9:05 AM, Paolo Bonzini wrote: > > > On 30/05/2017 17:58, Roman Penyaev wrote: >> Indeed, what is left is eventually take it from SS.RPL. J. > > Ahah! :) But I only suggested that in specific cases. > >> But jokes aside, with your last patch you seems fixed a race problem >> when "CS.RPL is not equal to the CPL in the few instructions between >> setting CR0.PE and reloading CS". > > Yes, exactly. The symptom was a crash (triple fault) when you kept > interrupting with "info cpus" a guest that repeatedly went to protected > mode and back to real mode. > >> We will have CPL in var->dpl, and it seems ok. All we need is not >> to lose it on the way kernel->userspace->kernel. > > You're right. So what do you think of the other suggestion (svm.c > doesn't clear attributes for unusable registers, QEMU only clears P for > unusable registers)? AMD CPUs really allow setting RPL in MSR_*STAR to something other than 3 and then blindly copy the result to SS.DPL when SYSRET happens? Ugh! I wonder if we can sweep that particular problem under the rug by saying that, as a KVM guest, you can't program STAR.RPL != 3? Or would that require us to set an intercept that we don't want to set? Alternatively, is there ever a case where CPL == 3, SS.DPL != 3 and non-root code can observe the fact that SS.DPL != 3? If not, maybe KVM could just change SS.DPL to 3 whenever it reads out SS if CPL == 3. Then CPL really could live in the SS state even on SVM. In other words, if a weird guest forces SS.RPL ! = 3 by programming garbage into *STAR and doing SYSRET, could that guest tell the difference if we non-deterministically changed SS.DPL back to 3 out from under it? Or is there some nasty case in which SS.DPL == 0, CPL == 3, SS is valid and you're in compat mode, and you expect stack access to fail because SS.DPL < CPL? --Andy