linux-kernel - Re: [PATCH] KVM: s390: Implement CHECK_STOP support and fix GET_MP

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20251211105412.207458-1-hi@josie.lol>
Date: Thu, 11 Dec 2025 11:54:12 +0100
From: Josephine Pfeiffer <hi@...ie.lol>
To: frankja@...ux.ibm.com
Cc: agordeev@...ux.ibm.com,
	borntraeger@...ux.ibm.com,
	david@...nel.org,
	gor@...ux.ibm.com,
	hca@...ux.ibm.com,
	imbrenda@...ux.ibm.com,
	kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-s390@...r.kernel.org,
	svens@...ux.ibm.com
Subject: Re: [PATCH] KVM: s390: Implement CHECK_STOP support and fix GET_MP_STATE

On Tue, 25 Nov 2025 19:10:43 +0100, Janosch Frank wrote:
> On 11/20/25 19:28, Josephine Pfeiffer wrote:
> > The use cases I see are:
> >
> > 1. API completeness: The state was added to the UAPI 11 years ago but never
> >     implemented. Userspace cannot use a documented API feature.
>
> I'd rather have stubs which properly fence than code that's never tested
> since we don't use it.
>
> Since this never worked it might make sense to remove it since future
> users will need to check for this "feature" anyway before using it.

That's a fair point. If you think there's no real use case, removing the dead 
API is cleaner than implementing unused code.

> > 2. Fault injection testing: Administrators testing failover/monitoring for
> >     hardware failures could programmatically put a CPU into CHECK_STOP to
> >     verify their procedures work.
>
> How would that work?
> What can we gain from putting a CPU into checkstop?
> How would QEMU would use this?
>
> Checkstop is not an error communication medium, that's the machine check
> interrupt. If you want to inject faults then use the machine check
> interface.
>
> If you want to crash the guest, then panic it or just stop cpus.

You're right - machine check interrupts are the correct mechanism for fault
injection. I was conflating the error state with error signaling.

I'll withdraw this patch and can send a cleanup patch instead to remove
KVM_MP_STATE_CHECK_STOP from the documentation. Would that be useful?

If so, should I also remove KVM_MP_STATE_LOAD from the docs while I'm at it? It has
the same "not supported yet" comment from the original 2014 commit [1].

Thanks,
Josephine

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6352e4d2dd9a