Index | Thread | Search

From:
Jeremie Courreges-Anglas <jca@wxcvbn.org>
Subject:
Re: [PATCH] riscv64: make isa size bigger and terminate
To:
Mark Kettenis <mark.kettenis@xs4all.nl>
Cc:
Miod Vallat <miod@online.fr>, mischief@offblast.org, tech@openbsd.org
Date:
Tue, 17 Jun 2025 17:58:22 +0200

Download raw body.

Thread
On Sun, Jun 15, 2025 at 09:16:20PM +0200, Mark Kettenis wrote:
> > Date: Sun, 15 Jun 2025 18:27:50 +0000
> > From: Miod Vallat <miod@online.fr>
> > Cc: tech@openbsd.org
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > 
> > > i have swapped to using sizeof to terminate the buffer, instead of
> > > trusting OF_getprop's return value.
> > 
> > What about invoking OF_getproplen() first, allocating the proper size
> > with malloc(), and free()ing afterwards, so that this hardcoded 512
> > doesn't need to become larger in a few years as more and extensions get
> > designed and qemu pretends to support all of them?

IMHO the main issue here is that the overflow makes the kernel
unusable.  Given this, I think a good first step is fixing the
overflow.

Dynamically allocating the string can't work right now, since
kern_sysctl.c expects an array, not a pointer.  We could add a
workaround, but do we really want to continue storing this isa string
in cpu_model?  It's not actually the CPU model.  I'd rather add a few
human-readable strings to the kernel for the the CPUs we know and run
on.

> The whole riscv,isa "describe all the ISA extensions in a single
> string" thing has been deprecated for a while now.  The code needs to
> be rewritten to use riscv,isa-base and riscv,isa-extensions instead.

Feature detection is probably easier done with riscv,isa-extensions.
I'm not sure feature *printing* in dmesg has to move from riscv,isa to
riscv,isa-extensions now.  AFAIK riscv,isa is still kept up-to-date in
u-boot/Linux.

-- 
jca