From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Reshetova, Elena" <elena.reshetova@intel.com>
Cc: Nikolay Borisov <nik.borisov@suse.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"x86@kernel.org" <x86@kernel.org>, Theodore Ts'o <tytso@mit.edu>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
"Kalra, Ashish" <ashish.kalra@amd.com>,
Sean Christopherson <seanjc@google.com>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Randomness on confidential computing platforms
Date: Fri, 26 Jan 2024 15:57:58 +0000 [thread overview]
Message-ID: <ZbPWht37uWZGhp4m@redhat.com> (raw)
In-Reply-To: <DM8PR11MB5750C6641F0951928E95439BE7792@DM8PR11MB5750.namprd11.prod.outlook.com>
On Fri, Jan 26, 2024 at 03:42:12PM +0000, Reshetova, Elena wrote:
> >
> > On 26.01.24 г. 15:42 ч., Kirill A. Shutemov wrote:
> > > 4. Exit to the host/VMM with an error indication after a Confidential
> > > Computing Guest failed to obtain random input from RDRAND/RDSEED
> > > instructions after reasonable number of retries. This option allows
> > > host/VMM to take some correction action for cases when the load on
> > > RDRAND/RDSEED instructions has been put by another actor, i.e. the
> > > other guest VM. The exit to host/VMM in such cases can be made
> > > transparent for the Confidential Computing Guest in the TDX case with
> > > the assistance of the TDX module component.
> >
> > But is this really a viable solution in the face of malicious VMM? It
> > assumes that if the VMM is signaled that randomness has been exhausted
> > it will try to rectify it, what if such a signal can instead be
> > repurposed for malicious purposes? Could it perhaps be used as some sort
> > of a side channel attack ?
>
> The idea here is that it is not necessary VMM that is the cause why the
> RDRAND/RDSEED fails, so if this is the case, VMM can in theory do smth
> about the situation.
>
> We have been thinking about if it can create an additional attack vector,
> but were not able to come with one. Do you have any in mind?
A guest might exit claiming failed RDRAND when in fact no such problem
occurred, as a way to mislead the host admin into taking action against
other guests.
If the CPU performance counters could report RDRAND exhaustion directly,
then the host admin could trust that information and monitor it, but the
host shouldn't rely on the (hostile) guest software to tell it about
exhaustion.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2024-01-26 15:58 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-26 13:42 [RFC] Randomness on confidential computing platforms Kirill A. Shutemov
2024-01-26 14:46 ` Nikolay Borisov
2024-01-26 15:42 ` Reshetova, Elena
2024-01-26 15:57 ` Daniel P. Berrangé [this message]
2024-01-26 16:35 ` Nikolay Borisov
2024-01-29 7:15 ` Reshetova, Elena
2024-01-26 15:23 ` Sean Christopherson
2024-01-29 10:27 ` Kirill A. Shutemov
2024-01-29 16:30 ` Dave Hansen
2024-01-29 16:37 ` H. Peter Anvin
2024-01-29 16:41 ` Kirill A. Shutemov
2024-01-29 17:07 ` H. Peter Anvin
2024-01-29 18:55 ` Dave Hansen
2024-01-29 20:26 ` Kirill A. Shutemov
2024-01-29 21:04 ` Dave Hansen
2024-01-29 21:17 ` H. Peter Anvin
2024-01-29 21:38 ` H. Peter Anvin
2024-01-29 22:12 ` H. Peter Anvin
2024-01-29 21:33 ` Kirill A. Shutemov
2024-01-29 22:18 ` Dave Hansen
2024-01-29 23:32 ` H. Peter Anvin
2024-01-30 8:19 ` Reshetova, Elena
2024-01-30 8:01 ` Reshetova, Elena
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZbPWht37uWZGhp4m@redhat.com \
--to=berrange@redhat.com \
--cc=Jason@zx2c4.com \
--cc=ashish.kalra@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=elena.reshetova@intel.com \
--cc=hpa@zytor.com \
--cc=jun.nakajima@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nik.borisov@suse.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tytso@mit.edu \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox