Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5545472yba; Mon, 13 May 2019 12:47:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqx3sbkcWxE/GrNrCCCXb0nP81FXws4WY2lI3eSaIDeRFllzKWk9TpzT2Po3cFUefDX2d3t0 X-Received: by 2002:a63:8a4a:: with SMTP id y71mr33654542pgd.270.1557776831839; Mon, 13 May 2019 12:47:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557776831; cv=none; d=google.com; s=arc-20160816; b=cQ9XdysHzFHxOqwN++kHjvdnzNegU21kSEPGCtPPfU5lCiqFIOfDGX/oyVJzmNCCbL YbXfDESmnfbaXXFG/iTCvE1aN/QDDgWHaccKzAh17sVU2w5wi8XtVxVpcznubVYx7IY4 i/KiV3obYZcHtFb4ACOuDxJJyaa2kMNpn1vzHIc33RMcMB5upsh2aorqgyyrgRFvUwvN DPNcRmqV89mBhAFoQyQ8xyrQyzcxBEOGn8+M4Mr3OCTAl3vn+qz/2APeI0JZzDbcsLVN keDNqyesIb/0tBgqML4RKjlkdz6cp/SAfflHi2yDPDILQUcdqj8AEv4PQG5tq6RSJrKp pAow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=RXmaEukWCV36ZGd13nL2HHyXvZXbzVLzc6CzdUvQtq0=; b=J9Wn9A7F4Zf6TFoiDevTt3gGTGSZ8albAfCt/A/VWOHljPWXOw6HjHEsvCF0CeajAS +hBMixVZwQ6OoDlEfV9DN4sKAFBtsJ3tInPmN2nLZZTMsOjPUSydTUDLC+alPD8PQeca d5J2YzUzd4XcrpU6RMdynsusBR2RItb1JqyW2uxp93Ct4vbnQfzKQJ7KMkVKgxr4eRhB PbitJ4SIAujh/LPttAMykX5YCWP2zUFFYN8QoyqI1Gbfnk5NCuRn6fWNRoiKE7yJnR8d BM8urETxOrFFvC7P0TxVcU4Fi7M62GfPVrNqJrHnrFgH/OvH7j/ihmsaI21o3CAWnmQE yWzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=M73groKW; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q4si16702738plr.376.2019.05.13.12.46.55; Mon, 13 May 2019 12:47:11 -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; dkim=pass header.i=@kernel.org header.s=default header.b=M73groKW; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726494AbfEMSR2 (ORCPT + 99 others); Mon, 13 May 2019 14:17:28 -0400 Received: from mail.kernel.org ([198.145.29.99]:53336 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726142AbfEMSR1 (ORCPT ); Mon, 13 May 2019 14:17:27 -0400 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E2FB42168B for ; Mon, 13 May 2019 18:17:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557771447; bh=lPPXPrlCXnec9ArL5Smn4WZ7XgjTRPHq0b2cg72c7do=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=M73groKWN7tiM88HUylA0BevMADMrkXxMAX5GrLV+GI8cDdt8upEqFbWjtmTbBtWf B1fbMLLC4Ig6Ha6q/7u8EsjeSgkgTLTRZg/th8dDdkCQSgF5F8U6hLZj14iprJmgc3 c3GN5DwMXPdaJcryEnpckEV58wfnaOyIRu/KMP3g= Received: by mail-wm1-f47.google.com with SMTP id x64so291169wmb.5 for ; Mon, 13 May 2019 11:17:26 -0700 (PDT) X-Gm-Message-State: APjAAAVN6Twft0DwaB/tm4RowrYa/wz11i6F2QtRFbTo2YY585CHlvgy Ntk/Ydm7Ugxy65kKVaXIJNNP9CXH5pqAR4I7rj+ERg== X-Received: by 2002:a1c:eb18:: with SMTP id j24mr17403247wmh.32.1557771445393; Mon, 13 May 2019 11:17:25 -0700 (PDT) MIME-Version: 1.0 References: <1557758315-12667-1-git-send-email-alexandre.chartre@oracle.com> In-Reply-To: <1557758315-12667-1-git-send-email-alexandre.chartre@oracle.com> From: Andy Lutomirski Date: Mon, 13 May 2019 11:17:14 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC KVM 00/27] KVM Address Space Isolation To: Alexandre Chartre Cc: Paolo Bonzini , Radim Krcmar , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Dave Hansen , Andrew Lutomirski , Peter Zijlstra , kvm list , X86 ML , Linux-MM , LKML , Konrad Rzeszutek Wilk , jan.setjeeilers@oracle.com, Liran Alon , Jonathan Adams Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > I expect that the KVM address space can eventually be expanded to include > the ioctl syscall entries. By doing so, and also adding the KVM page table > to the process userland page table (which should be safe to do because the > KVM address space doesn't have any secret), we could potentially handle the > KVM ioctl without having to switch to the kernel pagetable (thus effectively > eliminating KPTI for KVM). Then the only overhead would be if a VM-Exit has > to be handled using the full kernel address space. > In the hopefully common case where a VM exits and then gets re-entered without needing to load full page tables, what code actually runs? I'm trying to understand when the optimization of not switching is actually useful. Allowing ioctl() without switching to kernel tables sounds... extremely complicated. It also makes the dubious assumption that user memory contains no secrets.