[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y9OaF/p6PszOCydn@8bytes.org>
Date: Fri, 27 Jan 2023 10:32:07 +0100
From: Jörg Rödel <joro@...tes.org>
To: Leon Romanovsky <leon@...nel.org>
Cc: "Reshetova, Elena" <elena.reshetova@...el.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Shishkin, Alexander" <alexander.shishkin@...el.com>,
"Shutemov, Kirill" <kirill.shutemov@...el.com>,
"Kuppuswamy, Sathyanarayanan" <sathyanarayanan.kuppuswamy@...el.com>,
"Kleen, Andi" <andi.kleen@...el.com>,
"Hansen, Dave" <dave.hansen@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
"Wunner, Lukas" <lukas.wunner@...el.com>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
"Michael S. Tsirkin" <mst@...hat.com>,
Jason Wang <jasowang@...hat.com>,
"Poimboe, Josh" <jpoimboe@...hat.com>,
"aarcange@...hat.com" <aarcange@...hat.com>,
Cfir Cohen <cfir@...gle.com>, Marc Orr <marcorr@...gle.com>,
"jbachmann@...gle.com" <jbachmann@...gle.com>,
"pgonda@...gle.com" <pgonda@...gle.com>,
"keescook@...omium.org" <keescook@...omium.org>,
James Morris <jmorris@...ei.org>,
Michael Kelley <mikelley@...rosoft.com>,
"Lange, Jon" <jlange@...rosoft.com>,
"linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: Linux guest kernel threat model for Confidential Computing
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
