All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@suse.de>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH v4 3/8] [PATCH v4 3/8] Linux Patch #3
Date: Wed, 27 Jun 2018 18:08:42 +0200	[thread overview]
Message-ID: <20180627160842.GG24227@zn.tnic> (raw)
In-Reply-To: <20180623135445.641656585@localhost.localdomain>

On Sat, Jun 23, 2018 at 09:54:17AM -0400, speck for konrad.wilk_at_oracle.com wrote:
> x86/KVM: Use L1 cache flush before VMENTER if available.
> 
> 336996-Speculative-Execution-Side-Channel-Mitigations.pdf defines
> a new MSR (IA32_FLUSH_CMD aka 0x10B) which has similar write-only
> semantics to other MSRs defined in the document.
> 
> The semantics of this MSR is to allow "finer granularity invalidation
> of caching structures than existing mechanisms like WBINVD. It will
> writeback and invalidate the L1 data cache, including all cachelines
> brought in by preceding instructions, without invalidating all caches
> (eg. L2 or LLC). Some processors may also invalidate the first level level
> instruction cache on a L1D_FLUSH command. The L1 data and
> instruction caches may be shared across the logical processors of a core."
> 
> Hence right before we do an VMENTER we need to flush the L1 data cache
> to thwart against untrusted guests reading the host memory that
> is cached in L1 data cache.
> 
> A copy of this document is available at
>    https://bugzilla.kernel.org/show_bug.cgi?id=199511
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

As before, fix From: or fixup when committing.

...

> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 4d2e4975f91d..f0f25d31e5e2 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -6551,11 +6551,17 @@ static void *__read_mostly empty_zero_pages;
>  
>  void kvm_l1d_flush(void)
>  {
> -	/* FIXME: could this be boot_cpu_data.x86_cache_size * 2?  */
> -	int size = PAGE_SIZE << L1D_CACHE_ORDER;
> +	int size;
>  
>  	ASSERT(boot_cpu_has(X86_BUG_L1TF));
>  
> +	if (static_cpu_has(X86_FEATURE_FLUSH_L1D)) {
> +		wrmsrl(MSR_IA32_FLUSH_CMD, L1D_FLUSH);

alternative_msr_write(...

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

      parent reply	other threads:[~2018-06-27 16:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-23 13:54 [MODERATED] [PATCH v4 3/8] [PATCH v4 3/8] Linux Patch #3 konrad.wilk
2018-06-25 14:26 ` [MODERATED] " Paolo Bonzini
2018-06-25 16:32   ` Dave Hansen
2018-06-25 16:46     ` Paolo Bonzini
2018-06-25 17:26       ` Dave Hansen
2018-06-25 23:33       ` Andi Kleen
2018-06-26  6:41         ` Thomas Gleixner
2018-06-27 10:21 ` Thomas Gleixner
2018-06-27 16:08 ` Borislav Petkov [this message]

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=20180627160842.GG24227@zn.tnic \
    --to=bp@suse.de \
    --cc=speck@linutronix.de \
    /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.