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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9813CC433F5 for ; Mon, 25 Apr 2022 07:59:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231488AbiDYICI (ORCPT ); Mon, 25 Apr 2022 04:02:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231339AbiDYIBn (ORCPT ); Mon, 25 Apr 2022 04:01:43 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 275D027CE8 for ; Mon, 25 Apr 2022 00:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=bk7N8VtSWAvLQd3yMexQM6sFuFonXwjn/dFWlACLuw4=; b=KrNUg6E9jRh6S9p23phIwDD+A9 2yjbvoiMW3hXguiVED3XGeLI5RAp9z3c3rmBxo0F++ml3YQ8tcOKSZOhMELY6kv+Bo4zE7qjAcWtU 4e1Lurbi4qCxDhsiGkas5y6uhLAsCknOpNVtA8OPhC29Rp4ibbQQWk7Dx2gUkzdJLCazkHqGz7Izp 3JA0+CRtthmVp/yKRShz0BN0MuqCJ6vXAbzrTgeGDRw/XkPuzBc6ZO2k7jO4uF8Mglc5aF6PsTyYT WrTKukboCsRrzIBFPXxbH/jQ1NFzu8tuncjK13ASp0sXfOTrrMx8nRWkxEyq52l9iDKiiOEFi2QRD o9WfNkjA==; Received: from hch by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nitc6-008hbI-PT; Mon, 25 Apr 2022 07:58:30 +0000 Date: Mon, 25 Apr 2022 00:58:30 -0700 From: Christoph Hellwig To: Juergen Gross Cc: Oleksandr , Christoph Hellwig , xen-devel@lists.xenproject.org, x86@kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Boris Ostrovsky , Stefano Stabellini , Julien Grall , Oleksandr Tyshchenko , "Michael S. Tsirkin" , Tom Lendacky Subject: Re: [PATCH V1 3/6] xen/virtio: Add option to restrict memory access under Xen Message-ID: References: <1650646263-22047-1-git-send-email-olekstysh@gmail.com> <1650646263-22047-4-git-send-email-olekstysh@gmail.com> <6c5042fe-dafc-eb4f-c1fa-03b0faf252de@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 25, 2022 at 09:47:49AM +0200, Juergen Gross wrote: > > Would the Xen specific bits fit into Confidential Computing Platform > > checks? I will let Juergen/Boris comment on this. > > I don't think cc_platform_has would be correct here. Xen certainly > provides more isolation between guests and dom0, but "Confidential > Computing" is basically orthogonal to that feature. The point of cc_platform_has is to remove all these open code checks. If a Xen hypervisor / dom0 can't access arbitrary guest memory for virtual I/O and we need special APIs for that it certainly false into the scope of cc_platform_has, even if the confientiality is rather limited.