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 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C0EE0C4332F for ; Fri, 16 Dec 2022 11:59:02 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.464524.722943 (Exim 4.92) (envelope-from ) id 1p69MP-00032N-2g; Fri, 16 Dec 2022 11:58:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 464524.722943; Fri, 16 Dec 2022 11:58:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1p69MO-00032G-WD; Fri, 16 Dec 2022 11:58:41 +0000 Received: by outflank-mailman (input) for mailman id 464524; Fri, 16 Dec 2022 11:58:39 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1p69MN-000329-DY for xen-devel@lists.xenproject.org; Fri, 16 Dec 2022 11:58:39 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1p69ML-0002Sn-Gp; Fri, 16 Dec 2022 11:58:37 +0000 Received: from 54-240-197-233.amazon.com ([54.240.197.233] helo=[192.168.4.243]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1p69ML-0005M9-AB; Fri, 16 Dec 2022 11:58:37 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=ffeG7YpB3DegaNbNub/9ODCz5ESjbn6mDee0awUYju0=; b=TiKdTzzEGT2kie6jqiZewyWgzZ EIL2Ksdsx/AhKWlTVMWEicCS0rXt0MpCXRzDcc+afAhib5legQ8CEqQxNeu/KFUFxBIzdPFfnFAv/ LnS2NFMCKlH3wbybUZ2KNgdeogFDeYXbgghALVnc81tgwS15ohzFNy7RZmNoESOyLAtM=; Message-ID: <3328f716-8550-60f5-b12c-489bb51dde4d@xen.org> Date: Fri, 16 Dec 2022 11:58:34 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [RFC 0/4] Adding Virtual Memory Fuses to Xen Content-Language: en-US To: Demi Marie Obenour , "Smith, Jackson" Cc: "Brookes, Scott" , Xen-devel , Stefano Stabellini , "bertrand.marquis@arm.com" , "jbeulich@suse.com" , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , George Dunlap , "Daniel P. Smith" , "christopher.w.clark@gmail.com" References: From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Demi, On 13/12/2022 22:22, Demi Marie Obenour wrote: > On Tue, Dec 13, 2022 at 08:55:28PM +0000, Julien Grall wrote: >> On 13/12/2022 19:48, Smith, Jackson wrote: >>> Hi Xen Developers, >> >> Hi Jackson, >> >> Thanks for sharing the prototype with the community. Some questions/remarks >> below. > > [snip] > >>> With this technique, we protect the integrity and confidentiality of >>> guest memory. However, a compromised hypervisor can still read/write >>> register state during traps, or refuse to schedule a guest, denying >>> service. We also recognize that because this technique precludes >>> modifying Xen's page tables after startup, it may not be compatible >>> with all of Xen's potential use cases. On the other hand, there are >>> some uses cases (in particular statically defined embedded systems) >>> where our technique could be adopted with minimal friction. >> >> From what you wrote, this sounds very much like the project Citrix and >> Amazon worked on called "Secret-free hypervisor" with a twist. In your case, >> you want to prevent the hypervisor to map/unmap the guest memory. >> >> You can find some details in [1]. The code is x86 only, but I don't see any >> major blocker to port it on arm64. > > Is there any way the secret-free hypervisor code could be upstreamed? I have posted a new version with also a PoC for arm64: https://lore.kernel.org/xen-devel/20221216114853.8227-1-julien@xen.org/T/#t For convenience, I have also pushed a branch to my personal git: https://xenbits.xen.org/gitweb/?p=people/julieng/xen-unstable.git;a=summary branch no-directmap-v1 Cheers, -- Julien Grall