Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1505506ybh; Mon, 13 Jul 2020 22:43:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyoC8MFLM0BNikRQkPy/v/KVUkO1fNzFaw/Ceh51JcF6cT8U9cubDPWA6YkbiQ8MjYvOEQD X-Received: by 2002:a50:8fc4:: with SMTP id y62mr2729608edy.170.1594705422142; Mon, 13 Jul 2020 22:43:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594705422; cv=none; d=google.com; s=arc-20160816; b=AlYpelsTLp/hKMp7maf1Rw88CbfY/5y9/DqRLGSpo76bTr/AtUq5CDKQ5AFJnftcPQ cYLJ4+XeXvWroNfSc9d2ZMGpt5MVe2JmCUpAXkK/8e7CB6xuOrTYIbav/OCqzEiwC6k9 W3nYZnxRzZtCQEQb51xQvCd3lCrxYXlDvlMQaTHfppHTRglKoAmbmopJ5Xp4n1IS7yZF GkZ4NBzPYJSp5cVjWge3tBeDZrYk4F0tukM3wl0mqONYGkoxatxxBTvJ1i/bpcO/MIZ6 hYIfOCbI9VMvWYw4viXJFjQ6Fztah4v5b7ALbqpQsNBFM4/iUEs6/Z4eZqCOtpc6DVUp MA2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:ironport-sdr:ironport-sdr; bh=5M6vfYSWprcu4u9AQNUd2QPhojdGZdpbYIwIdfFZ83g=; b=LrDDrSNHCCG6WgjgSdzWGm5YhezF9nVYkdJIyv72UdDl+AK5nHQn+OmTkMI0f7fJlt vlizs2XprT9GgUXx8Jdd9MTF280eo/C/HIzJDCi0LJ9pE1OMq/oSEid8LYR0iJuBDehe T4rASfgRVRawqIihdzXqqEQYGzpP5cPLB5Xx1tGQJBt2ifTPzIc2mN1HI0PaUhXU9v92 a8pJW7/2xQdnI8As0xZ3VqVC97W+9C6kJRDI5FcHoL5il1GCn7vDsC8cqH3rwNZRkLLo Cj1OSJF/lPgcDe4P/DqWkNjxznrNAlRvb4EY+kPr2FQmT6nnZfJLTdJ3E7dL1oedRA+2 sWfQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m16si4158450ejb.364.2020.07.13.22.43.19; Mon, 13 Jul 2020 22:43:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726734AbgGNFnK (ORCPT + 99 others); Tue, 14 Jul 2020 01:43:10 -0400 Received: from mga05.intel.com ([192.55.52.43]:56275 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725306AbgGNFnJ (ORCPT ); Tue, 14 Jul 2020 01:43:09 -0400 IronPort-SDR: uhQTP7KOU/pcJ6TYeJU6keO8b1WHUW8JP6FxH9RNRDrmUhssOiiNxi8J6Lr4lYKOSBtJYu7+sh f3EuN3bqwPlQ== X-IronPort-AV: E=McAfee;i="6000,8403,9681"; a="233665963" X-IronPort-AV: E=Sophos;i="5.75,350,1589266800"; d="scan'208";a="233665963" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jul 2020 22:43:08 -0700 IronPort-SDR: MizPN2CBTzimOsR+xSUT+e+4WVuCCDUceoaUG09wR/Om3zkkAzUomzdwbif514QuCYev3LbEyA G70hNQxP+5QQ== X-IronPort-AV: E=Sophos;i="5.75,350,1589266800"; d="scan'208";a="316281009" Received: from otcsectest.jf.intel.com (HELO 760745902f30) ([10.54.30.81]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jul 2020 22:43:08 -0700 Date: Tue, 14 Jul 2020 05:39:30 +0000 From: "Andersen, John" To: Andy Lutomirski , Arvind Sankar Cc: Dave Hansen , Paolo Bonzini , Sean Christopherson , Jonathan Corbet , Thomas Gleixner , Ingo Molnar , Borislav Petkov , X86 ML , "H. Peter Anvin" , Shuah Khan , Liran Alon , Andrew Jones , Rick Edgecombe , Kristen Carlson Accardi , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Mauro Carvalho Chehab , Greg KH , "Paul E. McKenney" , Pawan Gupta , Juergen Gross , Mike Kravetz , Oliver Neukum , Peter Zijlstra , Fenghua Yu , reinette.chatre@intel.com, vineela.tummalapalli@intel.com, Dave Hansen , Arjan van de Ven , caoj.fnst@cn.fujitsu.com, Baoquan He , Kees Cook , Dan Williams , eric.auger@redhat.com, aaronlewis@google.com, Peter Xu , makarandsonare@google.com, "open list:DOCUMENTATION" , LKML , kvm list , "open list:KERNEL SELFTEST FRAMEWORK" , Kernel Hardening Subject: Re: [PATCH 2/4] KVM: x86: Introduce paravirt feature CR0/CR4 pinning Message-ID: <20200714053930.GC25@760745902f30> References: <20200618144314.GB23@258ff54ff3c0> <124a59a3-a603-701b-e3bb-61e83d70b20d@intel.com> <20200707211244.GN20096@linux.intel.com> <19b97891-bbb0-1061-5971-549a386f7cfb@intel.com> <31eb5b00-9e2a-aa10-0f20-4abc3cd35112@redhat.com> <20200709154412.GA25@64c96d3be97b> <6040c3b3-cac9-cc0e-f0de-baaa274920a2@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 09, 2020 at 09:27:43AM -0700, Andy Lutomirski wrote: > On Thu, Jul 9, 2020 at 9:22 AM Dave Hansen wrote: > > > > On 7/9/20 9:07 AM, Andy Lutomirski wrote: > > > On Thu, Jul 9, 2020 at 8:56 AM Dave Hansen wrote: > > >> On 7/9/20 8:44 AM, Andersen, John wrote: > > >>> Bits which are allowed to be pinned default to WP for CR0 and SMEP, > > >>> SMAP, and UMIP for CR4. > > >> I think it also makes sense to have FSGSBASE in this set. > > >> > > >> I know it hasn't been tested, but I think we should do the legwork to > > >> test it. If not in this set, can we agree that it's a logical next step? > > > I have no objection to pinning FSGSBASE, but is there a clear > > > description of the threat model that this whole series is meant to > > > address? The idea is to provide a degree of protection against an > > > attacker who is able to convince a guest kernel to write something > > > inappropriate to CR4, right? How realistic is this? > > > > If a quick search can find this: > > > > > https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-packet.html > > > > I'd pretty confident that the guys doing actual bad things have it in > > their toolbox too. > > > > True, but we have the existing software CR4 pinning. I suppose the > virtualization version is stronger. > Yes, as Kees said this will be stronger because it stops ROP and other gadget based techniques which avoid the use of native_write_cr0/4(). With regards to what should be done in this patchset and what in other patchsets. I have a fix for kexec thanks to Arvind's note about TRAMPOLINE_32BIT_CODE_SIZE. The physical host boots fine now and the virtual one can kexec fine. What remains to be done on that front is to add some identifying information to the kernel image to declare that it supports paravirtualized control register pinning or not. Liran suggested adding a section to the built image acting as a flag to signify support for being kexec'd by a kernel with pinning enabled. If anyone has any opinions on how they'd like to see this implemented please let me know. Otherwise I'll just take a stab at it and you'll all see it hopefully in the next version. With regards to FSGSBASE, are we open to validating and adding that to the DEFAULT set as a part of a separate patchset? This patchset is focused on replicating the functionality we already have natively. (If anyone got this email twice, sorry I messed up the From: field the first time around)