| Message ID | 20220809150331.84296-2-Jason@zx2c4.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v7,1/2] target/s390x: support SHA-512 extensions | expand |
On 09/08/2022 17.03, Jason A. Donenfeld wrote: > In order for hosts running inside of TCG to initialize the kernel's > random number generator, we should support the PRNO_TRNG instruction, > backed in the usual way with the qemu_guest_getrandom helper. This is > confirmed working on Linux 5.19. > > Cc: Thomas Huth <thuth@redhat.com> > Cc: David Hildenbrand <david@redhat.com> > Cc: Christian Borntraeger <borntraeger@linux.ibm.com> > Cc: Richard Henderson <richard.henderson@linaro.org> > Cc: Cornelia Huck <cohuck@redhat.com> > Cc: Harald Freudenberger <freude@linux.ibm.com> > Cc: Holger Dengler <dengler@linux.ibm.com> > Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> > --- > target/s390x/gen-features.c | 1 + > target/s390x/tcg/crypto_helper.c | 30 ++++++++++++++++++++++++++++++ > 2 files changed, 31 insertions(+) Also here: If you've got some spare time, a test in tests/tcg/s390x/ would be very welcome! > diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c > index 85ab69d04e..423ae44315 100644 > --- a/target/s390x/gen-features.c > +++ b/target/s390x/gen-features.c > @@ -752,6 +752,7 @@ static uint16_t qemu_MAX[] = { > S390_FEAT_MSA_EXT_5, > S390_FEAT_KIMD_SHA_512, > S390_FEAT_KLMD_SHA_512, > + S390_FEAT_PRNO_TRNG, > }; (this will need some fencing for old machine types, too, just like in patch 1/2) > /****** END FEATURE DEFS ******/ > diff --git a/target/s390x/tcg/crypto_helper.c b/target/s390x/tcg/crypto_helper.c > index 4d45de8faa..e155ae1f54 100644 > --- a/target/s390x/tcg/crypto_helper.c > +++ b/target/s390x/tcg/crypto_helper.c > @@ -14,6 +14,7 @@ > > #include "qemu/osdep.h" > #include "qemu/main-loop.h" > +#include "qemu/guest-random.h" > #include "s390x-internal.h" > #include "tcg_s390x.h" > #include "exec/helper-proto.h" > @@ -167,6 +168,31 @@ static int klmd_sha512(CPUS390XState *env, uintptr_t ra, uint64_t parameter_bloc > return 0; > } > > +static void fill_buf_random(CPUS390XState *env, uintptr_t ra, > + uint64_t *buf_reg, uint64_t *len_reg) > +{ > + uint8_t tmp[256]; > + uint64_t len = *len_reg; > + int message_reg_len = 64; > + > + if (!(env->psw.mask & PSW_MASK_64)) { > + len = (uint32_t)len; > + message_reg_len = (env->psw.mask & PSW_MASK_32) ? 32 : 24; > + } > + > + while (len) { > + size_t block = MIN(len, sizeof(tmp)); > + > + qemu_guest_getrandom_nofail(tmp, block); > + for (size_t i = 0; i < block; ++i) { > + cpu_stb_data_ra(env, wrap_address(env, *buf_reg), tmp[i], ra); > + *buf_reg = deposit64(*buf_reg, 0, message_reg_len, *buf_reg + 1); > + --*len_reg; I know it's annoying, but technically, you must not touch the upper bits of the len_reg if running in 31- or 24-bit addressing mode. The Principles of Operations say: "In either the 24- or 31-bit addressing mode, bits 32-63 of the odd-numbered register are decremented by the number of bytes processed for the respective operand, and bits 0-31 of the register remain unchanged." > + } > + len -= block; > + } > +} > + > uint32_t HELPER(msa)(CPUS390XState *env, uint32_t r1, uint32_t r2, uint32_t r3, > uint32_t type) > { Don't you also need to modify the "query" part to signal the availability of the function? Doesn't Linux in the guest check the availability first before using it? > @@ -209,6 +235,10 @@ uint32_t HELPER(msa)(CPUS390XState *env, uint32_t r1, uint32_t r2, uint32_t r3, > return klmd_sha512(env, ra, env->regs[1], &env->regs[r2], &env->regs[r2 + 1]); > } > break; > + case 114: /* CPACF_PRNO_TRNG */ > + fill_buf_random(env, ra, &env->regs[r1], &env->regs[r1 + 1]); > + fill_buf_random(env, ra, &env->regs[r2], &env->regs[r2 + 1]); > + break; > default: > /* we don't implement any other subfunction yet */ > g_assert_not_reached(); Maybe one more thing to check (according the "Special Conditions" section in the Principles of Operation): "A specification exception is recognized and no other action is taken if any of the following conditions exist: ... 2. The R1 or R2 fields designate an odd-numbered register or general register 0. This exception is recognized regardless of the function code. " Thomas
On Fri, Aug 26, 2022 at 01:28:11PM +0200, Thomas Huth wrote: > > + qemu_guest_getrandom_nofail(tmp, block); > > + for (size_t i = 0; i < block; ++i) { > > + cpu_stb_data_ra(env, wrap_address(env, *buf_reg), tmp[i], ra); > > + *buf_reg = deposit64(*buf_reg, 0, message_reg_len, *buf_reg + 1); > > + --*len_reg; > > I know it's annoying, but technically, you must not touch the upper bits of > the len_reg if running in 31- or 24-bit addressing mode. The Principles of > Operations say: > > "In either the 24- or 31-bit addressing mode, bits 32-63 of the odd-numbered > register are decremented by the number > of bytes processed for the respective operand, and > bits 0-31 of the register remain unchanged." > This is what I was trying to do with the use of deposit64, following David's guidance. Did I mess something up? > > + } > > + len -= block; > > + } > > +} > > + > > uint32_t HELPER(msa)(CPUS390XState *env, uint32_t r1, uint32_t r2, uint32_t r3, > > uint32_t type) > > { > > Don't you also need to modify the "query" part to signal the availability of > the function? Doesn't Linux in the guest check the availability first before > using it? I think this is already handled at the upper layers. Linux detects it fine. > > > @@ -209,6 +235,10 @@ uint32_t HELPER(msa)(CPUS390XState *env, uint32_t r1, uint32_t r2, uint32_t r3, > > return klmd_sha512(env, ra, env->regs[1], &env->regs[r2], &env->regs[r2 + 1]); > > } > > break; > > + case 114: /* CPACF_PRNO_TRNG */ > > + fill_buf_random(env, ra, &env->regs[r1], &env->regs[r1 + 1]); > > + fill_buf_random(env, ra, &env->regs[r2], &env->regs[r2 + 1]); > > + break; > > default: > > /* we don't implement any other subfunction yet */ > > g_assert_not_reached(); > > Maybe one more thing to check (according the "Special Conditions" section in > the Principles of Operation): > > "A specification exception is recognized and no other > action is taken if any of the following conditions exist: > > ... > > 2. The R1 or R2 fields designate an odd-numbered > register or general register 0. This exception is > recognized regardless of the function code. > " This is taken care of already by the function that calls into this function. Jason
On 29/08/2022 18.29, Jason A. Donenfeld wrote: > On Fri, Aug 26, 2022 at 01:28:11PM +0200, Thomas Huth wrote: >>> + qemu_guest_getrandom_nofail(tmp, block); >>> + for (size_t i = 0; i < block; ++i) { >>> + cpu_stb_data_ra(env, wrap_address(env, *buf_reg), tmp[i], ra); >>> + *buf_reg = deposit64(*buf_reg, 0, message_reg_len, *buf_reg + 1); >>> + --*len_reg; >> >> I know it's annoying, but technically, you must not touch the upper bits of >> the len_reg if running in 31- or 24-bit addressing mode. The Principles of >> Operations say: >> >> "In either the 24- or 31-bit addressing mode, bits 32-63 of the odd-numbered >> register are decremented by the number >> of bytes processed for the respective operand, and >> bits 0-31 of the register remain unchanged." >> > > This is what I was trying to do with the use of deposit64, following > David's guidance. Did I mess something up? Sorry for not following up earlier - I've been away from keyboard for a couple of weeks... Anyway, that was likely a wrong comment from my side anyway - I thought that "--*len_reg" might alter the upper bits, too, when there is no masking here. But since "len" has been constrained earlier in the function already, I think this cannot happen, so please never mind. I just saw that you also sent a v8 now, so I'll follow up on that version. Thomas
diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c index 85ab69d04e..423ae44315 100644 --- a/target/s390x/gen-features.c +++ b/target/s390x/gen-features.c @@ -752,6 +752,7 @@ static uint16_t qemu_MAX[] = { S390_FEAT_MSA_EXT_5, S390_FEAT_KIMD_SHA_512, S390_FEAT_KLMD_SHA_512, + S390_FEAT_PRNO_TRNG, }; /****** END FEATURE DEFS ******/ diff --git a/target/s390x/tcg/crypto_helper.c b/target/s390x/tcg/crypto_helper.c index 4d45de8faa..e155ae1f54 100644 --- a/target/s390x/tcg/crypto_helper.c +++ b/target/s390x/tcg/crypto_helper.c @@ -14,6 +14,7 @@ #include "qemu/osdep.h" #include "qemu/main-loop.h" +#include "qemu/guest-random.h" #include "s390x-internal.h" #include "tcg_s390x.h" #include "exec/helper-proto.h" @@ -167,6 +168,31 @@ static int klmd_sha512(CPUS390XState *env, uintptr_t ra, uint64_t parameter_bloc return 0; } +static void fill_buf_random(CPUS390XState *env, uintptr_t ra, + uint64_t *buf_reg, uint64_t *len_reg) +{ + uint8_t tmp[256]; + uint64_t len = *len_reg; + int message_reg_len = 64; + + if (!(env->psw.mask & PSW_MASK_64)) { + len = (uint32_t)len; + message_reg_len = (env->psw.mask & PSW_MASK_32) ? 32 : 24; + } + + while (len) { + size_t block = MIN(len, sizeof(tmp)); + + qemu_guest_getrandom_nofail(tmp, block); + for (size_t i = 0; i < block; ++i) { + cpu_stb_data_ra(env, wrap_address(env, *buf_reg), tmp[i], ra); + *buf_reg = deposit64(*buf_reg, 0, message_reg_len, *buf_reg + 1); + --*len_reg; + } + len -= block; + } +} + uint32_t HELPER(msa)(CPUS390XState *env, uint32_t r1, uint32_t r2, uint32_t r3, uint32_t type) { @@ -209,6 +235,10 @@ uint32_t HELPER(msa)(CPUS390XState *env, uint32_t r1, uint32_t r2, uint32_t r3, return klmd_sha512(env, ra, env->regs[1], &env->regs[r2], &env->regs[r2 + 1]); } break; + case 114: /* CPACF_PRNO_TRNG */ + fill_buf_random(env, ra, &env->regs[r1], &env->regs[r1 + 1]); + fill_buf_random(env, ra, &env->regs[r2], &env->regs[r2 + 1]); + break; default: /* we don't implement any other subfunction yet */ g_assert_not_reached();
In order for hosts running inside of TCG to initialize the kernel's random number generator, we should support the PRNO_TRNG instruction, backed in the usual way with the qemu_guest_getrandom helper. This is confirmed working on Linux 5.19. Cc: Thomas Huth <thuth@redhat.com> Cc: David Hildenbrand <david@redhat.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Cornelia Huck <cohuck@redhat.com> Cc: Harald Freudenberger <freude@linux.ibm.com> Cc: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> --- target/s390x/gen-features.c | 1 + target/s390x/tcg/crypto_helper.c | 30 ++++++++++++++++++++++++++++++ 2 files changed, 31 insertions(+)