Received-SPF: pass (google.com: domain of linux-kernel+bounces-197439-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Fri, 31 May 2024 13:19:14 -0700
From: Charlie Jenkins <charlie@rivosinc.com>
To: Conor Dooley <conor@kernel.org>
Cc: Jesse Taube <jesse@rivosinc.com>, linux-riscv@lists.infradead.org,
	linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
	Alexandre Ghiti <alexghiti@rivosinc.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	=?iso-8859-1?Q?Bj=F6rn_T=F6pel?= <bjorn@rivosinc.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Masahiro Yamada <masahiroy@kernel.org>
Subject: Re: [PATCH v0] RISC-V: Use Zkr to seed KASLR base address
Message-ID: <ZlowwohstpT0sJVl@ghost>
References: <20240531162327.2436962-1-jesse@rivosinc.com>
 <20240531-uselessly-spied-262ecf44e694@spud>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240531-uselessly-spied-262ecf44e694@spud>

On Fri, May 31, 2024 at 06:31:09PM +0100, Conor Dooley wrote:
> On Fri, May 31, 2024 at 12:23:27PM -0400, Jesse Taube wrote:
> > Dectect the Zkr extension and use it to seed the kernel base address.
> > 
> > Detection of the extension can not be done in the typical fashion, as
> > this is very early in the boot process. Instead, add a trap handler
> > and run it to see if the extension is present.
> 
> You can't rely on the lack of a trap meaning that Zkr is present unless
> you know that the platform implements Ssstrict. The CSR with that number
> could do anything if not Ssstrict compliant, so this approach gets a
> nak from me. Unfortunately, Ssstrict doesn't provide a way to detect
> it, so you're stuck with getting that information from firmware.

The Scalar Cryptography v1.0.1 spec says "If Zkr is not implemented, the
[s,u]seed bits must be hardwired to zero". It also says "Without the
corresponding access control bit set to 1, any attempted access to seed
from U, S, or HS modes will raise an illegal instruction exception."

There is a slight nuance here as the definition of Ssstrict is:

"No non-conforming extensions are present. Attempts to execute
unimplemented opcodes or access unimplemented CSRs in the standard or
reserved encoding spaces raises an illegal instruction exception that
results in a contained trap to the supervisor-mode trap handler."

The trap that Jesse is relying on in the code here is related to access
bits and not related to the CSR being unimplemented. Since the access
bits are required to be 0 on an implementation without Zkr, it is
required to trap if seed is accessed, regardless of Ssstrict.

The situation here is slightly odd because the spec is defining behavior
for what to do if the extension is not supported, and requires
implementations to follow this aspect of the Scalar Cryptography spec
even though they may not implement any of the instructions in the spec.

> 
> For DT systems, you can actually parse the DT in the pi, we do it to get
> the kaslr seed if present, so you can actually check for Zkr. With ACPI
> I have no idea how you can get that information, I amn't an ACPI-ist.

It is feasible to check if Zkr is present in the device tree at this
stage in boot, but at first glance does not seem feasible to read the
ACPI tables this early.

The CSR being read is just for entropy so even if the seed CSR doesn't
trap and provides an arbitrary value on an implementation that does not
support Zkr, it can still be used as a source of entropy. If the
implementation does trap, the entropy will be set to 0 which is just a
different hard-coded arbitrary value. 

- Charlie

> 
> Thanks,
> Conor.
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv