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 02B0EC38142 for ; Fri, 27 Jan 2023 09:32:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232611AbjA0JcU (ORCPT ); Fri, 27 Jan 2023 04:32:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232251AbjA0JcP (ORCPT ); Fri, 27 Jan 2023 04:32:15 -0500 Received: from mail.8bytes.org (mail.8bytes.org [85.214.250.239]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4EDE329438 for ; Fri, 27 Jan 2023 01:32:09 -0800 (PST) Received: from 8bytes.org (p5b006afb.dip0.t-ipconnect.de [91.0.106.251]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.8bytes.org (Postfix) with ESMTPSA id 2857126300B; Fri, 27 Jan 2023 10:32:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=8bytes.org; s=default; t=1674811928; bh=67bxT685tOMCKAuJAdCEHl033uhA9K3HKNmu6VQru0o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Xy2SiDytMo1wuCsna2qB+MFrsDdSUGfO4h3fBDUHGer8n9OqFrq+zLxIRp+wKeAYo WCVqiNKU6o1RRx1foLikfKWDJwZt7NwWDdp61ni8YITCQDLrxwK/xKJY/7Kh6jld2J 6gI6pHCgNx0DKaD83QIW6gJiQ2Y4LoPLOeMlEm7ubDS/7+HWcWp54nRFCZIFGQDAv/ ORUp7me4GZTaXozH+WunuCriokj9YOcsnT7+ArGFYptfdBY0d8JECpKDgq7crBUyRr Ik/dGWmFIoQkkpqiK+D4tjKbjmmfELjWZ/PRIXbcu+2Vpg45hCdyLBDTz0L/+3ucai 46QWyEJ19LB8A== Date: Fri, 27 Jan 2023 10:32:07 +0100 From: =?iso-8859-1?Q?J=F6rg_R=F6del?= To: Leon Romanovsky Cc: "Reshetova, Elena" , Greg Kroah-Hartman , "Shishkin, Alexander" , "Shutemov, Kirill" , "Kuppuswamy, Sathyanarayanan" , "Kleen, Andi" , "Hansen, Dave" , Thomas Gleixner , Peter Zijlstra , "Wunner, Lukas" , Mika Westerberg , "Michael S. Tsirkin" , Jason Wang , "Poimboe, Josh" , "aarcange@redhat.com" , Cfir Cohen , Marc Orr , "jbachmann@google.com" , "pgonda@google.com" , "keescook@chromium.org" , James Morris , Michael Kelley , "Lange, Jon" , "linux-coco@lists.linux.dev" , Linux Kernel Mailing List , Kernel Hardening Subject: Re: Linux guest kernel threat model for Confidential Computing Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 26, 2023 at 02:30:19PM +0200, Leon Romanovsky wrote: > This is exactly what I said. You presented me the cases which exist in > your invented world. Mentioned unhandled page fault doesn't exist in real > world. If PCI device doesn't work, it needs to be replaced/blocked and not > left to be operable and accessible from the kernel/user. Believe it or not, this "invented" world is already part of the real world, and will become even more in the future. So this has been stated elsewhere in the thread already, but I also like to stress that hiding misbehavior of devices (real or emulated) is not the goal of this work. In fact, the best action for a CoCo guest in case it detects a (possible) attack is to stop whatever it is doing and crash. And a misbehaving device in a CoCo guest is a possible attack. But what needs to be prevented at all costs is undefined behavior in the CoCo guest that is triggerable by the HV, e.g. by letting an emulated device misbehave. That undefined behavior can lead to information leak, which is a way bigger problem for a guest owner than a crashed VM. Regards, Joerg