Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 2 Feb 2023 11:24:51 +0800
From: Jason Wang <jasowang@...hat.com>
To: "Michael S. Tsirkin" <mst@...hat.com>,
 Christophe de Dinechin Dupont de Dinechin <cdupontd@...hat.com>
Cc: Christophe de Dinechin <dinechin@...hat.com>,
 James Bottomley <jejb@...ux.ibm.com>,
 "Reshetova, Elena" <elena.reshetova@...el.com>,
 Leon Romanovsky <leon@...nel.org>,
 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>,
 "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


在 2023/2/1 19:01, Michael S. Tsirkin 写道:
> On Wed, Feb 01, 2023 at 11:52:27AM +0100, Christophe de Dinechin Dupont de Dinechin wrote:
>>
>>> On 31 Jan 2023, at 18:39, Michael S. Tsirkin <mst@...hat.com> wrote:
>>>
>>> On Tue, Jan 31, 2023 at 04:14:29PM +0100, Christophe de Dinechin wrote:
>>>> Finally, security considerations that apply irrespective of whether the
>>>> platform is confidential or not are also outside of the scope of this
>>>> document. This includes topics ranging from timing attacks to social
>>>> engineering.
>>> Why are timing attacks by hypervisor on the guest out of scope?
>> Good point.
>>
>> I was thinking that mitigation against timing attacks is the same
>> irrespective of the source of the attack. However, because the HV
>> controls CPU time allocation, there are presumably attacks that
>> are made much easier through the HV. Those should be listed.
> Not just that, also because it can and does emulate some devices.
> For example, are disk encryption systems protected against timing of
> disk accesses?
> This is why some people keep saying "forget about emulated devices, require
> passthrough, include devices in the trust zone".


One problem is that the device could be yet another emulated one that is 
running in the SmartNIC/DPU itself.

Thanks


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.