All of lore.kernel.org
 help / color / mirror / Atom feed
From: Deepak Gupta <debug@rivosinc.com>
To: Conor Dooley <conor@kernel.org>
Cc: "Alexandre Ghiti" <alex@ghiti.fr>,
	"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>,
	"Björn Töpel" <bjorn@rivosinc.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Nathan Chancellor" <nathan@kernel.org>,
	"Nick Desaulniers" <ndesaulniers@google.com>,
	"Masahiro Yamada" <masahiroy@kernel.org>,
	"Clément Léger" <cleger@rivosinc.com>,
	"Atish Patra" <atishp@rivosinc.com>
Subject: Re: [PATCH v0] RISC-V: Use Zkr to seed KASLR base address
Date: Fri, 7 Jun 2024 11:51:07 -0700	[thread overview]
Message-ID: <ZmNWmxak9Rc80Kpb@debug.ba.rivosinc.com> (raw)
In-Reply-To: <20240603-stinking-roster-cfad46696ae5@spud>

On Mon, Jun 03, 2024 at 01:47:40PM +0100, Conor Dooley wrote:
>On Mon, Jun 03, 2024 at 11:14:49AM +0200, Alexandre Ghiti wrote:
>> Hi Conor,
>>
>> On 31/05/2024 19:31, 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.
>>
>>
>> FYI, this patch is my idea, so I'm the one to blame here :)
>>
>>
>> >
>> > 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.
>>
>>
>> I took a look at how to access ACPI tables this early when implementing the
>> Zabha/Zacas patches, but it seems not possible.
>>
>> But I'll look into this more, this is not the first time we need the
>> extensions list very early and since we have no way to detect the presence
>> of an extension at runtime, something needs to be done.
>
>Aye, having remembered that reading CSR_SEED could have side-effects on a
>system with non-conforming extensions, it'd be good to see if we can
>actually do this via detection on ACPI - especially for some other
>extensions that we may need to turn on very early (I forget which ones we
>talked about this before for). I didn't arm64 do anything with ACPI in the
>pi code, is the code arch/x86/boot/compressed run at an equivilent-ish point
>in boot?

cc: +Clement and Atish

I don't know all the details but on first glance it seems like instead of ACPI,
may be FWFT is a better place for discovery ?
https://lists.riscv.org/g/tech-prs/topic/patch_v12_add_firmware/106479571

Supervisor could query if Sstrict is implemented and then it can check for
lack of trap on CSR_SEED or straight-away check for presence of Zkr.



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

WARNING: multiple messages have this Message-ID (diff)
From: Deepak Gupta <debug@rivosinc.com>
To: Conor Dooley <conor@kernel.org>
Cc: "Alexandre Ghiti" <alex@ghiti.fr>,
	"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>,
	"Björn Töpel" <bjorn@rivosinc.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Nathan Chancellor" <nathan@kernel.org>,
	"Nick Desaulniers" <ndesaulniers@google.com>,
	"Masahiro Yamada" <masahiroy@kernel.org>,
	"Clément Léger" <cleger@rivosinc.com>,
	"Atish Patra" <atishp@rivosinc.com>
Subject: Re: [PATCH v0] RISC-V: Use Zkr to seed KASLR base address
Date: Fri, 7 Jun 2024 11:51:07 -0700	[thread overview]
Message-ID: <ZmNWmxak9Rc80Kpb@debug.ba.rivosinc.com> (raw)
In-Reply-To: <20240603-stinking-roster-cfad46696ae5@spud>

On Mon, Jun 03, 2024 at 01:47:40PM +0100, Conor Dooley wrote:
>On Mon, Jun 03, 2024 at 11:14:49AM +0200, Alexandre Ghiti wrote:
>> Hi Conor,
>>
>> On 31/05/2024 19:31, 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.
>>
>>
>> FYI, this patch is my idea, so I'm the one to blame here :)
>>
>>
>> >
>> > 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.
>>
>>
>> I took a look at how to access ACPI tables this early when implementing the
>> Zabha/Zacas patches, but it seems not possible.
>>
>> But I'll look into this more, this is not the first time we need the
>> extensions list very early and since we have no way to detect the presence
>> of an extension at runtime, something needs to be done.
>
>Aye, having remembered that reading CSR_SEED could have side-effects on a
>system with non-conforming extensions, it'd be good to see if we can
>actually do this via detection on ACPI - especially for some other
>extensions that we may need to turn on very early (I forget which ones we
>talked about this before for). I didn't arm64 do anything with ACPI in the
>pi code, is the code arch/x86/boot/compressed run at an equivilent-ish point
>in boot?

cc: +Clement and Atish

I don't know all the details but on first glance it seems like instead of ACPI,
may be FWFT is a better place for discovery ?
https://lists.riscv.org/g/tech-prs/topic/patch_v12_add_firmware/106479571

Supervisor could query if Sstrict is implemented and then it can check for
lack of trap on CSR_SEED or straight-away check for presence of Zkr.



  reply	other threads:[~2024-06-07 18:51 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-31 16:23 [PATCH v0] RISC-V: Use Zkr to seed KASLR base address Jesse Taube
2024-05-31 16:23 ` Jesse Taube
2024-05-31 17:31 ` Conor Dooley
2024-05-31 17:31   ` Conor Dooley
2024-05-31 20:19   ` Charlie Jenkins
2024-05-31 20:19     ` Charlie Jenkins
2024-05-31 21:36     ` Conor Dooley
2024-05-31 21:36       ` Conor Dooley
2024-05-31 21:40       ` Charlie Jenkins
2024-05-31 21:40         ` Charlie Jenkins
2024-06-01 13:22         ` Conor Dooley
2024-06-01 13:22           ` Conor Dooley
2024-06-03  9:14   ` Alexandre Ghiti
2024-06-03  9:14     ` Alexandre Ghiti
2024-06-03 12:47     ` Conor Dooley
2024-06-03 12:47       ` Conor Dooley
2024-06-07 18:51       ` Deepak Gupta [this message]
2024-06-07 18:51         ` Deepak Gupta
2024-06-10  8:33         ` Clément Léger
2024-06-10  8:33           ` Clément Léger
2024-06-10  9:02           ` Conor Dooley
2024-06-10  9:02             ` Conor Dooley
2024-06-10  9:16             ` Clément Léger
2024-06-10  9:16               ` Clément Léger
2024-06-10 21:06               ` Deepak Gupta
2024-06-10 21:06                 ` Deepak Gupta
2024-06-10 21:56                 ` Conor Dooley
2024-06-10 21:56                   ` Conor Dooley
2024-06-11 15:32                   ` Deepak Gupta
2024-06-11 15:32                     ` Deepak Gupta
2024-06-12  7:15                     ` Clément Léger
2024-06-12  7:15                       ` Clément Léger
2024-06-12  7:48                       ` Atish Kumar Patra
2024-06-12  7:48                         ` Atish Kumar Patra
2024-06-12 14:58                       ` Palmer Dabbelt
2024-06-12 14:58                         ` Palmer Dabbelt
2024-05-31 18:34 ` kernel test robot
2024-05-31 18:34   ` kernel test robot
2024-05-31 18:55 ` kernel test robot
2024-05-31 18:55   ` kernel test robot
2024-05-31 22:44 ` kernel test robot
2024-05-31 22:44   ` kernel test robot
2024-06-05  4:51 ` Zong Li
2024-06-05  4:51   ` Zong Li
2024-06-06 15:50   ` Jesse Taube
2024-06-06 15:50     ` Jesse Taube

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=ZmNWmxak9Rc80Kpb@debug.ba.rivosinc.com \
    --to=debug@rivosinc.com \
    --cc=alex@ghiti.fr \
    --cc=alexghiti@rivosinc.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=atishp@rivosinc.com \
    --cc=bjorn@rivosinc.com \
    --cc=cleger@rivosinc.com \
    --cc=conor@kernel.org \
    --cc=jesse@rivosinc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=llvm@lists.linux.dev \
    --cc=masahiroy@kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.