* [PATCH] arch/mips/kvm/emulate.c: Don't waste /dev/random emulating TLBWR
@ 2019-03-21 6:04 George Spelvin
2019-03-22 0:00 ` Paul Burton
0 siblings, 1 reply; 3+ messages in thread
From: George Spelvin @ 2019-03-21 6:04 UTC (permalink / raw)
To: jhogan, linux-mips; +Cc: lkml
KVM_MIPS_GUEST_TLB_SIZE is 64, so we only need one random byte,
not 4.
A more complex question is whether we need crypto-grade random
numbers at all. If safe, we could use prandom_u32(). If not,
we could seed a private PRNG and use prandom_u32_state().
Or could we just use asm("mfc0 %0, Random" : "=r" (index))?
Signed-off-by: George Spelvin <lkml@sdf.org>
---
I ran across this whie doing some other cleanups, and thought
I'd pass it on.
get_random_bytes() is quite an expensive function call.
Is it needed at all?
arch/mips/kvm/emulate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/mips/kvm/emulate.c b/arch/mips/kvm/emulate.c
index ec9ed23bca7f..a689f3db3094 100644
--- a/arch/mips/kvm/emulate.c
+++ b/arch/mips/kvm/emulate.c
@@ -1139,8 +1139,9 @@ enum emulation_result kvm_mips_emul_tlbwr(struct kvm_vcpu *vcpu)
struct mips_coproc *cop0 = vcpu->arch.cop0;
struct kvm_mips_tlb *tlb = NULL;
unsigned long pc = vcpu->arch.pc;
- int index;
+ unsigned char index;
+ /* Do we need this quality of random numbers? Would prandom_u32 do? */
get_random_bytes(&index, sizeof(index));
index &= (KVM_MIPS_GUEST_TLB_SIZE - 1);
--
2.20.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] arch/mips/kvm/emulate.c: Don't waste /dev/random emulating TLBWR
2019-03-21 6:04 [PATCH] arch/mips/kvm/emulate.c: Don't waste /dev/random emulating TLBWR George Spelvin
@ 2019-03-22 0:00 ` Paul Burton
2019-03-22 5:22 ` George Spelvin
0 siblings, 1 reply; 3+ messages in thread
From: Paul Burton @ 2019-03-22 0:00 UTC (permalink / raw)
To: George Spelvin; +Cc: jhogan, linux-mips
Hi George,
On Thu, Mar 21, 2019 at 06:04:24AM +0000, George Spelvin wrote:
> KVM_MIPS_GUEST_TLB_SIZE is 64, so we only need one random byte,
> not 4.
>
> A more complex question is whether we need crypto-grade random
> numbers at all. If safe, we could use prandom_u32(). If not,
> we could seed a private PRNG and use prandom_u32_state().
>
> Or could we just use asm("mfc0 %0, Random" : "=r" (index))?
>
> Signed-off-by: George Spelvin <lkml@sdf.org>
> ---
> I ran across this whie doing some other cleanups, and thought
> I'd pass it on.
>
> get_random_bytes() is quite an expensive function call.
> Is it needed at all?
Thanks for the patch. I expect we should be fine with:
index = prandom_u32_max(KVM_MIPS_GUEST_TLB_SIZE);
We certainly don't need crypto-grade randomness here. Using the cp0
Random register would be an option for configurations prior to MIPSr6,
where the Random register was deprecated & we shouldn't rely on its
presence. So we could do:
if (MIPS_ISA_REV < 6)
index = read_c0_random() % KVM_MIPS_GUEST_TLB_SIZE;
else
index = prandom_u32_max(KVM_MIPS_GUEST_TLB_SIZE);
Though whether that micro-optimization is worth the extra code is
questionable.
Thanks,
Paul
> arch/mips/kvm/emulate.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/kvm/emulate.c b/arch/mips/kvm/emulate.c
> index ec9ed23bca7f..a689f3db3094 100644
> --- a/arch/mips/kvm/emulate.c
> +++ b/arch/mips/kvm/emulate.c
> @@ -1139,8 +1139,9 @@ enum emulation_result kvm_mips_emul_tlbwr(struct kvm_vcpu *vcpu)
> struct mips_coproc *cop0 = vcpu->arch.cop0;
> struct kvm_mips_tlb *tlb = NULL;
> unsigned long pc = vcpu->arch.pc;
> - int index;
> + unsigned char index;
>
> + /* Do we need this quality of random numbers? Would prandom_u32 do? */
> get_random_bytes(&index, sizeof(index));
> index &= (KVM_MIPS_GUEST_TLB_SIZE - 1);
>
> --
> 2.20.1
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] arch/mips/kvm/emulate.c: Don't waste /dev/random emulating TLBWR
2019-03-22 0:00 ` Paul Burton
@ 2019-03-22 5:22 ` George Spelvin
0 siblings, 0 replies; 3+ messages in thread
From: George Spelvin @ 2019-03-22 5:22 UTC (permalink / raw)
To: lkml, paul.burton; +Cc: jhogan, linux-mips
On Fri, 22 Mar 2019 at 00:00:45 +0000, Paul Burton wrote:
> On Thu, Mar 21, 2019 at 06:04:24AM +0000, George Spelvin wrote:
>> KVM_MIPS_GUEST_TLB_SIZE is 64, so we only need one random byte,
>> not 4.
>>
>> A more complex question is whether we need crypto-grade random
>> numbers at all. If safe, we could use prandom_u32(). If not,
>> we could seed a private PRNG and use prandom_u32_state().
>>
>> Or could we just use asm("mfc0 %0, Random" : "=r" (index))?
> Thanks for the patch. I expect we should be fine with:
>
> index = prandom_u32_max(KVM_MIPS_GUEST_TLB_SIZE);
>
> We certainly don't need crypto-grade randomness here. Using the cp0
> Random register would be an option for configurations prior to MIPSr6,
> where the Random register was deprecated & we shouldn't rely on its
> presence. So we could do:
>
> if (MIPS_ISA_REV < 6)
> index = read_c0_random() % KVM_MIPS_GUEST_TLB_SIZE;
> else
> index = prandom_u32_max(KVM_MIPS_GUEST_TLB_SIZE);
>
> Though whether that micro-optimization is worth the extra code is
> questionable.
I'm also not sure if you *want* to use the random register, because
that's a source of /dev/random entropy (arch/mips/include/asm/timex.h),
and maybe exposing it to VM guests would be a bad thing.
There's no need to get too fancy; prandom_u32_max is fine. (And
gcc optimizes it to a shift if the argument is a compie-time power
of 2.)
Anyway, thank you for the response, and I'm assuming there's no need
for revised patch from me; as it's less work for you to write your own.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-03-22 5:22 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-21 6:04 [PATCH] arch/mips/kvm/emulate.c: Don't waste /dev/random emulating TLBWR George Spelvin
2019-03-22 0:00 ` Paul Burton
2019-03-22 5:22 ` George Spelvin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).