[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250102092512.GDZ3ZbeGsxuPjXwc_K@fat_crate.local>
Date: Thu, 2 Jan 2025 10:25:12 +0100
From: Borislav Petkov <bp@...en8.de>
To: "Nikunj A. Dadhania" <nikunj@....com>
Cc: linux-kernel@...r.kernel.org, thomas.lendacky@....com, x86@...nel.org,
kvm@...r.kernel.org, mingo@...hat.com, tglx@...utronix.de,
dave.hansen@...ux.intel.com, pgonda@...gle.com, seanjc@...gle.com,
pbonzini@...hat.com
Subject: Re: [PATCH v15 12/13] x86/kvmclock: Abort SecureTSC enabled guest
when kvmclock is selected
On Thu, Jan 02, 2025 at 11:04:21AM +0530, Nikunj A. Dadhania wrote:
>
>
> On 1/1/2025 9:49 PM, Borislav Petkov wrote:
> > On Wed, Jan 01, 2025 at 03:14:12PM +0530, Nikunj A. Dadhania wrote:
> >> I can drop this patch, and if the admin wants to change the clock
> >> source to kvm-clock from Secure TSC, that will be permitted.
> >
> > Why would the admin want that and why would we even support that?
>
> I am not saying that admin will do that, I am saying that it is a possibility.
>
> Changing clocksource is supported via sysfs interface:
>
> echo "kvm-clock" > /sys/devices/system/clocksource/clocksource0/current_clocksource
You can do that in the guest, right?
Not on the host.
If so, are you basically saying that users will be able to kill their guests
simply by switching the clocksource?
Because this would be dumb of us.
And then the real thing to do should be something along the lines of
"You're running a Secure TSC guest, changing the clocksource is not allowed!"
or even better we warn when the user changes it but allow the change and taint
the kernel.
...
Yeah, stuff like that comes out only when I scratch the surface and ask about
it. And then people complain about it taking too long.
Well, tough luck.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists