The length of the facility list accessed when interpretively executing
STFLE is the same as the hosts facility list (in case of format-0)
When shadowing, copy only those bytes.
The memory following the facility list need not be accessible, in which
case we'd wrongly inject a validity intercept.
Fixes: 66b630d5b7f2 ("KVM: s390: vsie: support STFLE interpretation")
Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
---
arch/s390/include/asm/facility.h | 6 ++++++
arch/s390/kernel/Makefile | 2 +-
arch/s390/kernel/facility.c | 18 ++++++++++++++++++
arch/s390/kvm/vsie.c | 12 +++++++++++-
4 files changed, 36 insertions(+), 2 deletions(-)
create mode 100644 arch/s390/kernel/facility.c
diff --git a/arch/s390/include/asm/facility.h b/arch/s390/include/asm/facility.h
index 94b6919026df..796007125dff 100644
--- a/arch/s390/include/asm/facility.h
+++ b/arch/s390/include/asm/facility.h
@@ -111,4 +111,10 @@ static inline void stfle(u64 *stfle_fac_list, int size)
preempt_enable();
}
+/**
+ * stfle_size - Actual size of the facility list as specified by stfle
+ * (number of double words)
+ */
+unsigned int stfle_size(void);
+
#endif /* __ASM_FACILITY_H */
diff --git a/arch/s390/kernel/Makefile b/arch/s390/kernel/Makefile
index 0df2b88cc0da..0daa81439478 100644
--- a/arch/s390/kernel/Makefile
+++ b/arch/s390/kernel/Makefile
@@ -41,7 +41,7 @@ obj-y += sysinfo.o lgr.o os_info.o
obj-y += runtime_instr.o cache.o fpu.o dumpstack.o guarded_storage.o sthyi.o
obj-y += entry.o reipl.o kdebugfs.o alternative.o
obj-y += nospec-branch.o ipl_vmparm.o machine_kexec_reloc.o unwind_bc.o
-obj-y += smp.o text_amode31.o stacktrace.o abs_lowcore.o
+obj-y += smp.o text_amode31.o stacktrace.o abs_lowcore.o facility.o
extra-y += vmlinux.lds
diff --git a/arch/s390/kernel/facility.c b/arch/s390/kernel/facility.c
new file mode 100644
index 000000000000..c33a95a562da
--- /dev/null
+++ b/arch/s390/kernel/facility.c
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright IBM Corp. 2023
+ */
+
+#include <asm/facility.h>
+
+unsigned int stfle_size(void)
+{
+ static unsigned int size = 0;
+ u64 dummy;
+
+ if (!size) {
+ size = __stfle_asm(&dummy, 1) + 1;
+ }
+ return size;
+}
+EXPORT_SYMBOL(stfle_size);
diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
index d989772fe211..c168e88c64da 100644
--- a/arch/s390/kvm/vsie.c
+++ b/arch/s390/kvm/vsie.c
@@ -19,6 +19,7 @@
#include <asm/nmi.h>
#include <asm/dis.h>
#include <asm/fpu/api.h>
+#include <asm/facility.h>
#include "kvm-s390.h"
#include "gaccess.h"
@@ -990,11 +991,20 @@ static int handle_stfle(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
struct kvm_s390_sie_block *scb_s = &vsie_page->scb_s;
__u32 fac = READ_ONCE(vsie_page->scb_o->fac);
+ /*
+ * Alternate-STFLE-Interpretive-Execution facilities are not supported
+ * -> format-0 flcb
+ */
if (fac && test_kvm_facility(vcpu->kvm, 7)) {
fac = fac & 0x7ffffff8U;
retry_vsie_icpt(vsie_page);
+ /*
+ * format-0 -> size of nested guest's facility list == guest's size
+ * guest's size == host's size, since STFLE is interpretatively executed
+ * using a format-0 for the guest, too.
+ */
if (read_guest_real(vcpu, fac, &vsie_page->fac,
- sizeof(vsie_page->fac)))
+ stfle_size() * sizeof(u64)))
return set_validity_icpt(scb_s, 0x1090U);
scb_s->fac = (__u32)(__u64) &vsie_page->fac;
}
--
2.39.2On 03.11.23 18:30, Nina Schoetterl-Glausch wrote:
> The length of the facility list accessed when interpretively executing
> STFLE is the same as the hosts facility list (in case of format-0)
> When shadowing, copy only those bytes.
> The memory following the facility list need not be accessible, in which
> case we'd wrongly inject a validity intercept.
>
> Fixes: 66b630d5b7f2 ("KVM: s390: vsie: support STFLE interpretation")
> Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
> ---
> arch/s390/include/asm/facility.h | 6 ++++++
> arch/s390/kernel/Makefile | 2 +-
> arch/s390/kernel/facility.c | 18 ++++++++++++++++++
> arch/s390/kvm/vsie.c | 12 +++++++++++-
> 4 files changed, 36 insertions(+), 2 deletions(-)
> create mode 100644 arch/s390/kernel/facility.c
>
> diff --git a/arch/s390/include/asm/facility.h b/arch/s390/include/asm/facility.h
> index 94b6919026df..796007125dff 100644
> --- a/arch/s390/include/asm/facility.h
> +++ b/arch/s390/include/asm/facility.h
> @@ -111,4 +111,10 @@ static inline void stfle(u64 *stfle_fac_list, int size)
> preempt_enable();
> }
>
> +/**
> + * stfle_size - Actual size of the facility list as specified by stfle
> + * (number of double words)
> + */
> +unsigned int stfle_size(void);
> +
> #endif /* __ASM_FACILITY_H */
> diff --git a/arch/s390/kernel/Makefile b/arch/s390/kernel/Makefile
> index 0df2b88cc0da..0daa81439478 100644
> --- a/arch/s390/kernel/Makefile
> +++ b/arch/s390/kernel/Makefile
> @@ -41,7 +41,7 @@ obj-y += sysinfo.o lgr.o os_info.o
> obj-y += runtime_instr.o cache.o fpu.o dumpstack.o guarded_storage.o sthyi.o
> obj-y += entry.o reipl.o kdebugfs.o alternative.o
> obj-y += nospec-branch.o ipl_vmparm.o machine_kexec_reloc.o unwind_bc.o
> -obj-y += smp.o text_amode31.o stacktrace.o abs_lowcore.o
> +obj-y += smp.o text_amode31.o stacktrace.o abs_lowcore.o facility.o
>
> extra-y += vmlinux.lds
>
> diff --git a/arch/s390/kernel/facility.c b/arch/s390/kernel/facility.c
> new file mode 100644
> index 000000000000..c33a95a562da
> --- /dev/null
> +++ b/arch/s390/kernel/facility.c
> @@ -0,0 +1,18 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright IBM Corp. 2023
> + */
> +
> +#include <asm/facility.h>
> +
> +unsigned int stfle_size(void)
> +{
> + static unsigned int size = 0;
> + u64 dummy;
> +
> + if (!size) {
> + size = __stfle_asm(&dummy, 1) + 1;
> + }
> + return size;
> +}
> +EXPORT_SYMBOL(stfle_size);
Possible races? Should have to use an atomic?
No access to documentation, but sounds plausible.
Acked-by: David Hildenbrand <david@redhat.com>
--
Cheers,
David / dhildenb
On Fri, 2023-11-03 at 19:34 +0100, David Hildenbrand wrote:
> On 03.11.23 18:30, Nina Schoetterl-Glausch wrote:
> > The length of the facility list accessed when interpretively executing
> > STFLE is the same as the hosts facility list (in case of format-0)
> > When shadowing, copy only those bytes.
> > The memory following the facility list need not be accessible, in which
> > case we'd wrongly inject a validity intercept.
> >
> > Fixes: 66b630d5b7f2 ("KVM: s390: vsie: support STFLE interpretation")
> > Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
> > ---
> > arch/s390/include/asm/facility.h | 6 ++++++
> > arch/s390/kernel/Makefile | 2 +-
> > arch/s390/kernel/facility.c | 18 ++++++++++++++++++
> > arch/s390/kvm/vsie.c | 12 +++++++++++-
> > 4 files changed, 36 insertions(+), 2 deletions(-)
> > create mode 100644 arch/s390/kernel/facility.c
[...]
> > diff --git a/arch/s390/kernel/facility.c b/arch/s390/kernel/facility.c
[...]
> > +#include <asm/facility.h>
> > +
> > +unsigned int stfle_size(void)
> > +{
> > + static unsigned int size = 0;
> > + u64 dummy;
> > +
> > + if (!size) {
> > + size = __stfle_asm(&dummy, 1) + 1;
> > + }
> > + return size;
> > +}
> > +EXPORT_SYMBOL(stfle_size);
>
> Possible races? Should have to use an atomic?
Good point. Calling __stfle_asm multiple times is fine
and AFAIK torn reads/writes aren't possible. I don't see a way
for the compiler to break things either.
But it might indeed be nicer to use an atomic, without
any downsides.
>
> No access to documentation, but sounds plausible.
>
> Acked-by: David Hildenbrand <david@redhat.com>
Thanks!
On Mon, Nov 06, 2023 at 02:06:22PM +0100, Nina Schoetterl-Glausch wrote:
> > > +unsigned int stfle_size(void)
> > > +{
> > > + static unsigned int size = 0;
> > > + u64 dummy;
> > > +
> > > + if (!size) {
> > > + size = __stfle_asm(&dummy, 1) + 1;
> > > + }
Please get rid of the braces here. checkpatch.pl with "--strict" should
complain too, I guess.
> > Possible races? Should have to use an atomic?
>
> Good point. Calling __stfle_asm multiple times is fine
> and AFAIK torn reads/writes aren't possible. I don't see a way
> for the compiler to break things either.
> But it might indeed be nicer to use an atomic, without
> any downsides.
Please use WRITE_ONCE() and READ_ONCE(); that's more than sufficient here.
© 2016 - 2025 Red Hat, Inc.