From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x226XSI4a+BNGO/bAwnhGtOYxLSEZYGGWlNMeydagXV7OlxlwhmczbtRQsbyHWXOlNfWRdaBn ARC-Seal: i=1; a=rsa-sha256; t=1517356103; cv=none; d=google.com; s=arc-20160816; b=aT6JA5oFLQ6bLAKB+2dq/nHVksBKeAs+AscJvk/mYGVEoN1VC9k0o8EeHjHEofz5Ld KKPoOVVVL+Qgr/5GRkBAMgqaLlW9WmXuFh35R37AxhU/akSAGyUZym+NexLCyo+LbDFd PhiZHPF3L51bBMFwa4GanQQM1kdmVRNa/IrZJDaETH6ZItnqUfUKSm38e4CYnWTN7qwe lLTgzoN7y3DKgqLW5vH9WAnIQiQlwT5XxYUBnMwemj1D0fr7od29gZ6CLXfFtTb3tbAh iSYrcaf7lH4ScJcuiLJDXpQjvHCnoepErhYEgpWTDrrPaQwbMSm1QnGi1hZ7uYSQTeuR J9vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:arc-authentication-results; bh=5Pj/XpMu7zTFEF/ZBGnRtEUpMxPpSHi1Oz/rOY+HYnU=; b=uZpG1FoL87F9+WEd5FwnUz4AA0h3Sc1NT6PXo7QHAfxUNYpfNSPN1w5AawDRW8tzB6 I5EpYskVi4AyZnRV6XIXBuEnt0YdEOo11FDWgV3DD52qzb5mTVCXNI3iILnRXxK697iY l9EP7FXlAMhffV3wLOotHHQxOD5ab7BKGzovjbPT60nBmB1cgs8IehxE6EhVe1IUu5mT 4aiHLU8arEE01e6GEntWAL0tsSPiVmR49T3Xcd5RMNIEdtyZa05S0UcQTUD1dioiZQ8B gCr/QxQOwBBfhqkV2He1aSbzOlf8pf3TitXQIS1lTZs2EvLCcKSr4tS++I6rMaA9PFHQ +RsA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of ashok.raj@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=ashok.raj@intel.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of ashok.raj@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=ashok.raj@intel.com X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,437,1511856000"; d="scan'208";a="14280263" Date: Tue, 30 Jan 2018 15:48:22 -0800 From: "Raj, Ashok" To: Paolo Bonzini Cc: David Woodhouse , KarimAllah Ahmed , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, Andi Kleen , Andrea Arcangeli , Andy Lutomirski , Arjan van de Ven , Asit Mallick , Borislav Petkov , Dan Williams , Dave Hansen , Greg Kroah-Hartman , "H . Peter Anvin" , Ingo Molnar , Janakarajan Natarajan , Joerg Roedel , Jun Nakajima , Laura Abbott , Linus Torvalds , Masami Hiramatsu , Peter Zijlstra , Radim =?utf-8?B?S3LEjW3DocWZ?= , Thomas Gleixner , Tim Chen , Tom Lendacky , Ashok Raj Subject: Re: [PATCH v3 0/4] KVM: Expose speculation control feature to guests Message-ID: <20180130234822.GA62797@otc-nc-03> References: <1517271028-15916-1-git-send-email-karahmed@amazon.de> <1517302830.18619.78.camel@infradead.org> <6b7db789-9cc1-1b4d-9209-8d082e0d8def@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6b7db789-9cc1-1b4d-9209-8d082e0d8def@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590974343910960333?= X-GMAIL-MSGID: =?utf-8?q?1591063193366961220?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Tue, Jan 30, 2018 at 06:36:20PM -0500, Paolo Bonzini wrote: > On 30/01/2018 04:00, David Woodhouse wrote: > > I believe Ashok sent you a change which made us do IBPB on *every* > > vmexit; I don't think we need that. It's currently done in vcpu_load() > > which means we'll definitely have done it between running one vCPU and > > the next, and when vCPUs are pinned we basically never need to do it. > > > > We know that VMM (e.g. qemu) userspace could be vulnerable to attacks > > from guest ring 3, because there is no flush between the vmexit and the > > host kernel "returning" to the userspace thread. Doing a full IBPB on > > *every* vmexit would protect from that, but it's overkill. If that's > > the reason, let's come up with something better. > > Certainly not every vmexit! But doing it on every userspace vmexit and > every sched_out would not be *that* bad. Right.. agreed. We discussed the different scenarios that doing IBPB on VMexit would help, and decided its really not required on every exit. One obvious case is when there is a VMexit and return back to Qemu process (witout a real context switch) do we need that to be protected from any poisoned BTB from guest? If Qemu is protected by !dumpable/retpoline that should give that gaurantee. We do VM->VM IBPB at vmload() time that should provide that gaurantee. Cheers, Ashok > > We try really hard to avoid userspace vmexits for everything remotely > critical to performance (the main exception that's left is the PMTIMER > I/O port, that Windows likes to access quite a lot), so they shouldn't > happen that often.