From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1EFFC74A4B for ; Sun, 14 Jul 2019 15:06:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CB06B20C01 for ; Sun, 14 Jul 2019 15:06:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563116791; bh=9v0TSmLCn8TjvoXn1mqXdhjjoJsiEcxlv4LvLVZbR0I=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=0rkVx4NCmrEmIcclt4tjfSVy0xVgmShrxfRls4RqO6N91Lh2LbpGNxWrLgj1YYD51 Po28xHOIavOd/Ct550Bf98vPms3kgenLwjHw7m/hcHqpHcLZWTrYaSVVepUbggnzR5 iMjuBTgCE64R8s+rweGS12+B+QoEW0d/Y6LaYQ58= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728562AbfGNPGa (ORCPT ); Sun, 14 Jul 2019 11:06:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:56566 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728396AbfGNPG3 (ORCPT ); Sun, 14 Jul 2019 11:06:29 -0400 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (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 45C612183E for ; Sun, 14 Jul 2019 15:06:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563116788; bh=9v0TSmLCn8TjvoXn1mqXdhjjoJsiEcxlv4LvLVZbR0I=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=v0TmOJxy83Vs7zwskqPZknhJBHliByWQ9slt88eUlJmFucrdhem7QgBNJjIHsEncL 7r1MjLILZtAzjraM7v/6sOCnRImcX93hQrOaGfUCyDDn0RQY7log3hDh3/ibKrYXJj SPkMGaiBSRrNaF/5iAD/xywYdZdj9CsvNJiGqkvg= Received: by mail-wm1-f52.google.com with SMTP id g67so8673576wme.1 for ; Sun, 14 Jul 2019 08:06:28 -0700 (PDT) X-Gm-Message-State: APjAAAWzsBCzG7S/NHOMVcLQqmuVk1+O7BnBeGQq7ZTd8cOThHobnWGO TVTbE5cmQZZ8R2tk6Gvmpy3ORgtzrTtB/XcLMIH8ZQ== X-Google-Smtp-Source: APXvYqxduSTS2xAezjNhiFs/zv4vEOdtjl3od0VTpH2E1vVYA88Q+UFag4kZUKep/WXl0oYayxVpidWQx6QWYEWJtLo= X-Received: by 2002:a1c:9a53:: with SMTP id c80mr18654369wme.173.1563116786554; Sun, 14 Jul 2019 08:06:26 -0700 (PDT) MIME-Version: 1.0 References: <1562855138-19507-1-git-send-email-alexandre.chartre@oracle.com> <5cab2a0e-1034-8748-fcbe-a17cf4fa2cd4@intel.com> <61d5851e-a8bf-e25c-e673-b71c8b83042c@oracle.com> <20190712125059.GP3419@hirez.programming.kicks-ass.net> <3ca70237-bf8e-57d9-bed5-bc2329d17177@oracle.com> <20190712190620.GX3419@hirez.programming.kicks-ass.net> In-Reply-To: <20190712190620.GX3419@hirez.programming.kicks-ass.net> From: Andy Lutomirski Date: Sun, 14 Jul 2019 08:06:12 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC v2 00/27] Kernel Address Space Isolation To: Peter Zijlstra Cc: Alexandre Chartre , Thomas Gleixner , Dave Hansen , Paolo Bonzini , Radim Krcmar , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Dave Hansen , Andrew Lutomirski , kvm list , X86 ML , Linux-MM , LKML , Konrad Rzeszutek Wilk , jan.setjeeilers@oracle.com, Liran Alon , Jonathan Adams , Alexander Graf , Mike Rapoport , Paul Turner Content-Type: text/plain; charset="UTF-8" Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Fri, Jul 12, 2019 at 12:06 PM Peter Zijlstra wrote: > > On Fri, Jul 12, 2019 at 06:37:47PM +0200, Alexandre Chartre wrote: > > On 7/12/19 5:16 PM, Thomas Gleixner wrote: > > > > Right. If we decide to expose more parts of the kernel mappings then that's > > > just adding more stuff to the existing user (PTI) map mechanics. > > > > If we expose more parts of the kernel mapping by adding them to the existing > > user (PTI) map, then we only control the mapping of kernel sensitive data but > > we don't control user mapping (with ASI, we exclude all user mappings). > > > > How would you control the mapping of userland sensitive data and exclude them > > from the user map? Would you have the application explicitly identify sensitive > > data (like Andy suggested with a /dev/xpfo device)? > > To what purpose do you want to exclude userspace from the kernel > mapping; that is, what are you mitigating against with that? Mutually distrusting user/guest tenants. Imagine an attack against a VM hosting provider (GCE, for example). If the overall system is well-designed, the host kernel won't possess secrets that are important to the overall hosting network. The interesting secrets are in the memory of other tenants running under the same host. So, if we can mostly or completely avoid mapping one tenant's memory in the host, we reduce the amount of valuable information that could leak via a speculation (or wild read) attack to another tenant. The practicality of such a scheme is obviously an open question.