linux-kernel - RE: [PATCH 1/2] x86/random: Retry on RDSEED failure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DM8PR11MB5750B861F7A105886AA5FCE4E77C2@DM8PR11MB5750.namprd11.prod.outlook.com>
Date: Wed, 31 Jan 2024 07:56:49 +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

> Hi Elena,
> 
> On Tue, Jan 30, 2024 at 8:06 PM Reshetova, Elena
> <elena.reshetova@...el.com> wrote:
> > 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?
> 
> Right, observation is just as relevant.
> 
> > 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?
> 
> Check out try_to_generate_entropy() and random_get_entropy(), for
> example. How observable is RDTSC? Other HPTs?

Ok, here imo it gets arch-specific and so please treat my answers only 
with Intel TDX arch in mind. I do know that for example AMD behavior
for TSC is different, albeit I am not sure of details. Other archs might also
have different behavior.

For Intel TDX, when a guest executes RDTSC, it gets a virtual TSC value that
is calculated deterministically based on a bunch of inputs that are either
platform HW specific or VMM/host configured. The physical TSC value is taken 
into account also in calculations.  The guest itself is not able to
use usual controls (such as IA32_TSC_ADJUST and such). For details (albeit not
exact calculations) please see [1]. If you are interested in exact calculations, 
the public source code of TDX module is a better reference [2], check
calculate_virt_tsc() or just grep with "tsc" it would show you both comments
explaining what is happening and calculations.
So given this, I would personally consider the virtual guest TSC value
observable by host/VMM. 

 [1] TDX module spec, section 11.13 Time Stamp Counter (TSC)
https://cdrdv2.intel.com/v1/dl/getContent/733575 
[2] TDX module source code:
https://www.intel.com/content/www/us/en/download/738875/782152/intel-trust-domain-extension-intel-tdx-module.html

For the high resolution timers, host controls guest apic timers and interrupts fully. 
So, it has the power to see and even affect when a certain interrupt happens
or doesnt happen in the guest. It can delay guest timers at its will on pretty
extensive time periods. This seems powerful enough for me. 
Things like HPET are also fully under host control. 

> > > > 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?
> 
> I was just thinking that if this didn't require genuine Intel hardware
> with prebaked keys in it that you could emulate a CPU and all its
> peripherals and ram with defined latencies and such, and run the VM in
> a very straightforwardly deterministic environment, because nothing
> would be real. But if this does have to hit metal somewhere, then
> there's some possibility you at least interact with some hard-to-model
> physical hardware.

Yes, in practice there will be physical hw underneath, but the problem imo is
that the host is in between and still very powerful when it comes to interrupts and
timers at the moment. So, I want to make sure people understand the potential
implications overall, and in this case the potential implications on such a
critical security component as Linux RNG. 

Best Regards,
Elena.