Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp7298232ybp; Wed, 16 Oct 2019 06:48:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqwqlhvkynlI2GMMq3z4fAmmWg4byx7jFLmBHawFcQ0Im3ZixgW5o70TjBxH4s6vgY09Sr03 X-Received: by 2002:a50:fe0f:: with SMTP id f15mr38463051edt.89.1571233730247; Wed, 16 Oct 2019 06:48:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571233730; cv=none; d=google.com; s=arc-20160816; b=sxdttEur+dtDhQ93RzRwnsHYJsm9g6Xg0h7/hUhBj9xRCSndz81lF7exMsYlGNhAPB MDXOtLBFzCrRHnKeOT/zPwhuNraWoTffRHtjW/nOVurHbEa+Y5rl22n1UAKqmc9B+1Ot tz0743D8e8U06fV7TBs05anRgWc+xYqnPDjaoc3QbMG5+8ARMujadGFLR7JjU04FMRC/ 4gOdN6nkumEzRhnUM4up0Ree0ZSYr0fd3XRgzwmDUUfW9ntKmTsmv9SENfiuAkzt6/8i 0XW4GSL+mJdptoY8iP7zHyf44q4LCHuYxJou8cz8wzvOD1+kw46yZfqtMLfzMzREBKYZ FyEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=zvV0bnlM2vCIqOGUefrC6uhQyWPSmW/1Z5G4aqBdEuo=; b=e4iBm7yeqaEtkwj7NU0ngBpYrFJqBf0vYgSYyASAJl11PovPYsWJA5Gh819jzf31AJ yVXx8jEh8iPm+Juc5tNQoXLw1C9GdzLFDr4jQX7iHiBtuJ0UCrMIw0+0HH1Y/vi7yv5G flm/0O6lEWg8k0sadhLljZR4mECazydufIwSTmQvFOP4+i4jeU8UDtglrM6wxfJh0A6l hiysIiOcb3/6On19DMXLsGnyADpXzr2/f9F9yBP8KU5WD+YQGTRoBkDyypS97DeQEmxC Lv1gjGFpCXhpcYIyIpgkOUsPF70Ao3+Dzv3yHgWf9kDqMhjuoEVnd6v9m85I0AM/0X1L 5qHQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v6si14860110edw.51.2019.10.16.06.48.27; Wed, 16 Oct 2019 06:48:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392060AbfJPJrP (ORCPT + 99 others); Wed, 16 Oct 2019 05:47:15 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:49480 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389173AbfJPJrP (ORCPT ); Wed, 16 Oct 2019 05:47:15 -0400 Received: from [5.158.153.52] (helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iKftX-0001qC-R8; Wed, 16 Oct 2019 11:47:03 +0200 Date: Wed, 16 Oct 2019 11:47:03 +0200 (CEST) From: Thomas Gleixner To: Paolo Bonzini cc: Sean Christopherson , Fenghua Yu , Ingo Molnar , Borislav Petkov , H Peter Anvin , Peter Zijlstra , Andrew Morton , Dave Hansen , Radim Krcmar , Ashok Raj , Tony Luck , Dan Williams , Xiaoyao Li , Sai Praneeth Prakhya , Ravi V Shankar , linux-kernel , x86 , kvm@vger.kernel.org Subject: Re: [PATCH v9 09/17] x86/split_lock: Handle #AC exception for split lock In-Reply-To: <3ec328dc-2763-9da5-28d6-e28970262c58@redhat.com> Message-ID: References: <1560897679-228028-1-git-send-email-fenghua.yu@intel.com> <1560897679-228028-10-git-send-email-fenghua.yu@intel.com> <20190626203637.GC245468@romley-ivt3.sc.intel.com> <20190925180931.GG31852@linux.intel.com> <3ec328dc-2763-9da5-28d6-e28970262c58@redhat.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 16 Oct 2019, Paolo Bonzini wrote: > On 25/09/19 20:09, Sean Christopherson wrote: > > - Remove KVM loading of MSR_TEST_CTRL, i.e. KVM *never* writes the CPU's > > actual MSR_TEST_CTRL. KVM still emulates MSR_TEST_CTRL so that the > > guest can do WRMSR and handle its own #AC faults, but KVM doesn't > > change the value in hardware. > > > > * Allowing guest to enable split-lock detection can induce #AC on > > the host after it has been explicitly turned off, e.g. the sibling > > hyperthread hits an #AC in the host kernel, or worse, causes a > > different process in the host to SIGBUS. > > > > * Allowing guest to disable split-lock detection opens up the host > > to DoS attacks. > > > > - KVM advertises split-lock detection to guest/userspace if and only if > > split_lock_detect_disabled is zero. > > > > - Add a pr_warn_once() in KVM that triggers if split locks are disabled > > after support has been advertised to a guest. > > > > Does this sound sane? > > Not really, unfortunately. Just never advertise split-lock detection to > guests. If the host has enabled split-lock detection, trap #AC and > forward it to the host handler---which would disable split lock > detection globally and reenter the guest. Which completely defeats the purpose. 1) Sane guest Guest kernel has #AC handler and you basically prevent it from detecting malicious user space and killing it. You also prevent #AC detection in the guest kernel which limits debugability. 2) Malicious guest Trigger #AC to disable the host detection and then carry out the DoS attack. Try again. Thanks, tglx