[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM8PR11MB5750797D0B9B8EB32740F55DE77D2@DM8PR11MB5750.namprd11.prod.outlook.com>
Date: Tue, 30 Jan 2024 19:06:17 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: "Jason A. Donenfeld" <Jason@...c4.com>
CC: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, Thomas Gleixner
<tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov
<bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin"
<hpa@...or.com>, "x86@...nel.org" <x86@...nel.org>, Theodore Ts'o
<tytso@....edu>, Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@...ux.intel.com>, "Nakajima, Jun"
<jun.nakajima@...el.com>, Tom Lendacky <thomas.lendacky@....com>, "Kalra,
Ashish" <ashish.kalra@....com>, Sean Christopherson <seanjc@...gle.com>,
"linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/2] x86/random: Retry on RDSEED failure
> Elena,
>
> On Tue, Jan 30, 2024 at 3:06 PM Jason A. Donenfeld <Jason@...c4.com> wrote:
> > 2) Can a malicious host *actually* create a fully deterministic
> > environment? One that'll produce the same timing for the jitter
> > entropy creation, and all the other timers and interrupts and things?
>
> I'd like to re-up this question. It seems like assessing the reality
> of the concern would be worthwhile.
Yes, sorry, I am just behind answering this thread and it is getting late here.
This is exactly what I would like to have an open discussion about
with inputs from everyone.
We have to remember that it is not only about host 'producing'
a fully deterministic environment, but also about host being able to
*observe* the entropy input. So the more precise question to ask is
how much can a host observe? My personal understanding is that host can
observe all guest interrupts and their timings, including APIC timer interrupts
(and IPIs), so what is actually left for the guest as unobservable entropy
input?
And let's also please remember that this is by no means Intel-specific,
we have other confidential computing vendors, so we need a common
agreement on what is the superset of attacker powers that we can
assume.
> > I imagine the attestation part of CoCo means these VMs need to run on
> > real Intel silicon and so it can't be single stepped in TCG or
> > something, right?
Yes, there is an attestation of a confidential VM and some protections in place
that helps against single-stepping attacks. But I am not sure how this is relevant
for this, could you please clarify?
Best Regards,
Elena.
Powered by blists - more mailing lists