From: "Stefan O'Rear" <sorear@fastmail.com>
To: "Samuel Ortiz" <sameo@rivosinc.com>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
linux-riscv@lists.infradead.org
Cc: 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: Tue, 27 Jun 2023 21:00:53 -0400 [thread overview]
Message-ID: <644e7acf-905d-42b2-87d9-81b98ccca25c@app.fastmail.com> (raw)
In-Reply-To: <20230627143747.1599218-4-sameo@rivosinc.com>
On Tue, Jun 27, 2023, at 10:37 AM, 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: "
> +#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.
> + */
> + 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");
> + fallthrough;
> +
> + case SEED_OPST_WAIT:
> + default:
> + continue;
> + }
> +
> + } while (--retry);
> +
> + return false;
> +}
The Entropy Source specification is annoyingly vague about expected retry
counts, only saying that "Without a polling-style mechanism, the entropy
source could hang for thousands of cycles under some circumstances."
Likewise no constraint is placed on the maximum runtime of a BIST or the
maximum number of times SEED_OPST_BIST is repeatedly returned (only that
it be returned at least once if the BIST starts and finishes between seed
reads).
With that, the limit of 10 reads seems suspiciously small. Is there a
specific justification or is it known to work on some hardware?
-s
> +
> +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;
> +}
> +
> +#endif /* ASM_RISCV_ARCHRANDOM_H */
> diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h
> index b98b3b6c9da2..7d0ca9082c66 100644
> --- a/arch/riscv/include/asm/csr.h
> +++ b/arch/riscv/include/asm/csr.h
> @@ -389,6 +389,15 @@
> #define CSR_VTYPE 0xc21
> #define CSR_VLENB 0xc22
>
> +/* Scalar Crypto Extension - Entropy */
> +#define CSR_SEED 0x015
> +#define SEED_OPST_MASK _AC(0xC0000000, UL)
> +#define SEED_OPST_BIST _AC(0x00000000, UL)
> +#define SEED_OPST_WAIT _AC(0x40000000, UL)
> +#define SEED_OPST_ES16 _AC(0x80000000, UL)
> +#define SEED_OPST_DEAD _AC(0xC0000000, UL)
> +#define SEED_ENTROPY_MASK _AC(0xFFFF, UL)
> +
> #ifdef CONFIG_RISCV_M_MODE
> # define CSR_STATUS CSR_MSTATUS
> # define CSR_IE CSR_MIE
> --
> 2.41.0
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
prev parent reply other threads:[~2023-06-28 1:01 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
2023-06-28 1:00 ` Stefan O'Rear [this message]
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=644e7acf-905d-42b2-87d9-81b98ccca25c@app.fastmail.com \
--to=sorear@fastmail.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=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 \
--cc=sameo@rivosinc.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
all inboxes | Powered by JetHome®