public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Samuel Ortiz <sameo@rivosinc.com>
To: Conor Dooley <conor@kernel.org>
Cc: "Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	linux-riscv@lists.infradead.org, linux@rivosinc.com,
	"Conor Dooley" <conor.dooley@microchip.com>,
	"Andrew Jones" <ajones@ventanamicro.com>,
	"Heiko Stuebner" <heiko.stuebner@vrull.eu>,
	"Anup Patel" <apatel@ventanamicro.com>,
	linux-kernel@vger.kernel.org,
	"Hongren (Zenithal) Zheng" <i@zenithal.me>,
	"Guo Ren" <guoren@kernel.org>,
	"Atish Patra" <atishp@rivosinc.com>,
	"Björn Töpel" <bjorn@rivosinc.com>,
	"Evan Green" <evan@rivosinc.com>
Subject: Re: [PATCH 3/3] RISC-V: Implement archrandom when Zkr is available
Date: Wed, 28 Jun 2023 14:28:41 +0200	[thread overview]
Message-ID: <ZJwneby7cyBYFRZW@vermeer> (raw)
In-Reply-To: <20230627-grinning-droop-bfbb327f6164@spud>

Hi Conor,

On Tue, Jun 27, 2023 at 08:09:08PM +0100, Conor Dooley wrote:
> On Tue, Jun 27, 2023 at 04:37:44PM +0200, Samuel Ortiz wrote:
> > The Zkr extension is ratified and provides 16 bits of entropy seed when
> > reading the SEED CSR.
> > 
> > We can implement arch_get_random_seed_longs() by doing multiple csrrw to
> > that CSR and filling an unsigned long with valid entropy bits.
> > 
> > Signed-off-by: Samuel Ortiz <sameo@rivosinc.com>
> > ---
> >  arch/riscv/include/asm/archrandom.h | 66 +++++++++++++++++++++++++++++
> >  arch/riscv/include/asm/csr.h        |  9 ++++
> >  2 files changed, 75 insertions(+)
> >  create mode 100644 arch/riscv/include/asm/archrandom.h
> > 
> > diff --git a/arch/riscv/include/asm/archrandom.h b/arch/riscv/include/asm/archrandom.h
> > new file mode 100644
> > index 000000000000..3d01aab2800a
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/archrandom.h
> > @@ -0,0 +1,66 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Kernel interface for the RISCV arch_random_* functions
> > + *
> > + * Copyright (c) 2022 by Rivos Inc.
> > + *
> > + */
> > +
> > +#ifndef ASM_RISCV_ARCHRANDOM_H
> > +#define ASM_RISCV_ARCHRANDOM_H
> > +
> > +#include <asm/csr.h>
> > +
> > +#define PR_PREFIX "Zkr Extension: "
> 
> Does pr_fmt() not work for you?

It would, but since this is a header that e.g. gets included in
random.h, I would have to ifndef it first.
My v2 is less verbose and gets rid of this prefix anyways.

> Also, "Zkr Extension" doesn't really seem super helpful to a punter if
> they saw it in a log. Why not s/Zkr Extension/archrandom/, or similar?
> 
> > +#define SEED_RETRY_LOOPS 10
> > +
> > +static inline bool __must_check csr_seed_long(unsigned long *v)
> > +{
> > +	unsigned int retry = SEED_RETRY_LOOPS;
> > +	unsigned int needed_seeds = sizeof(unsigned long) / 2, valid_seeds = 0;
> > +	u16 *entropy = (u16 *)v;
> > +
> > +	do {
> > +		/*
> > +		 * The SEED CSR (0x015) must be accessed with a read-write
> > +		 * instruction. Moreover, implementations must ignore the write
> > +		 * value, its purpose is to signal polling for new seed.
> > +		 */
> 
> What relevance does the second half of this comment have to the kernel?

Not much, I will remove it with v2.

> > +		unsigned long csr_seed = csr_swap(CSR_SEED, 0);
> > +
> > +		switch (csr_seed & SEED_OPST_MASK) {
> > +		case SEED_OPST_ES16:
> > +			entropy[valid_seeds++] = csr_seed & SEED_ENTROPY_MASK;
> > +			if (valid_seeds == needed_seeds)
> > +				return true;
> > +			break;
> > +
> > +		case SEED_OPST_DEAD:
> > +			pr_err_once(PR_PREFIX "Unrecoverable error\n");
> > +			return false;
> > +
> > +		case SEED_OPST_BIST:
> > +			pr_info(PR_PREFIX "On going Built-in Self Test\n");
> 
> tiny nit, "On-going"? My OCD is bother by the capitalisation otherwise.

I removed that one with v2, as it may be a little too chatty.

> > +			fallthrough;
> > +
> > +		case SEED_OPST_WAIT:
> > +		default:
> > +			continue;
> > +		}
> > +
> > +	} while (--retry);
> > +
> > +	return false;
> > +}
> > +
> > +static inline size_t __must_check arch_get_random_longs(unsigned long *v, size_t max_longs)
> > +{
> > +	return 0;
> > +}
> > +
> > +static inline size_t __must_check arch_get_random_seed_longs(unsigned long *v, size_t max_longs)
> > +{
> > +	return max_longs && riscv_isa_extension_available(NULL, ZKR) && csr_seed_long(v) ? 1 : 0;
> 
> Could you please write this in a more readable way, even if that is
> going to be a lot more verbose? I know you copied it from x86, but
> that's not really an excuse ;)

Agreed :)
Fixed as well with v2.

> Also, is there a reason that you opted not to use the alternative-backed
> riscv_has_extension_[un]likely() here?

I did not know about them, I switched to it with v2 (Made it a likely
case).

Cheers,
Samuel.


  reply	other threads:[~2023-06-28 12:29 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-27 14:37 [PATCH 0/3] RISC-V: archrandom support Samuel Ortiz
2023-06-27 14:37 ` [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT Samuel Ortiz
2023-06-27 18:14   ` Evan Green
2023-06-27 18:44     ` Hongren (Zenithal) Zheng
2023-06-27 18:48     ` Conor Dooley
2023-06-27 19:03       ` Hongren (Zenithal) Zheng
2023-06-27 19:18         ` Conor Dooley
2023-06-28  9:59         ` Samuel Ortiz
2023-06-28 10:01       ` Samuel Ortiz
2023-06-28 11:10         ` Conor Dooley
2023-06-28 12:30           ` Samuel Ortiz
2023-06-28 16:49           ` Conor Dooley
2023-06-28 17:18           ` Evan Green
2023-06-28 17:24             ` Conor Dooley
2023-07-03 17:39               ` Conor Dooley
     [not found]   ` <97a7d701-3b48-252e-6d78-ef3d0e7f8f03@web.de>
2023-06-28 12:29     ` Samuel Ortiz
2023-06-27 14:37 ` [PATCH 2/3] RISC-V: hwprobe: Expose Zbc and the scalar crypto extensions Samuel Ortiz
2023-06-27 18:13   ` Evan Green
2023-06-28  0:34   ` Stefan O'Rear
2023-06-28 10:04     ` Samuel Ortiz
2023-06-28 13:25       ` Stefan O'Rear
2023-07-10  7:59         ` Samuel Ortiz
2023-07-12  5:54           ` Stefan O'Rear
2023-06-27 14:37 ` [PATCH 3/3] RISC-V: Implement archrandom when Zkr is available Samuel Ortiz
2023-06-27 19:09   ` Conor Dooley
2023-06-28 12:28     ` Samuel Ortiz [this message]
2023-06-28  1:00   ` Stefan O'Rear

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZJwneby7cyBYFRZW@vermeer \
    --to=sameo@rivosinc.com \
    --cc=ajones@ventanamicro.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=apatel@ventanamicro.com \
    --cc=atishp@rivosinc.com \
    --cc=bjorn@rivosinc.com \
    --cc=conor.dooley@microchip.com \
    --cc=conor@kernel.org \
    --cc=evan@rivosinc.com \
    --cc=guoren@kernel.org \
    --cc=heiko.stuebner@vrull.eu \
    --cc=i@zenithal.me \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux@rivosinc.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox