On Wed, May 29, 2024 at 9:50 AM Gregory Nutt wrote:
> On 5/29/2024 6:10 AM, Nathan Hartman wrote:
> > That's a security hole in the *hardware*, not in software, right? How can
> > that be fixed (unless a new chip is made)?
>
> No, software.
>
> Disclaimer: I don't do RISC-V but I do understand A
I'll provide a bit of background on our configuration, as I've
understandably caused some confusion.
We configure NuttX with CONFIG_BUILD_KERNEL, so we have a kernel with
device drivers, and a set of userspace applications. The MMU for Litex is
configured so kernel pages are only accessible while
On Tue, May 28, 2024 at 10:07 AM Gregory Nutt wrote:
> On 5/26/2024 5:03 PM, Stuart Ianna wrote:
> > With the riscv/litex port, we're able to access the TIME and TIMEH CSRs
> in
> > usermode. I would like to take advantage of this feature to replace the
> > proxies for syscalls, such as timer_get
On 5/26/2024 5:03 PM, Stuart Ianna wrote:
With the riscv/litex port, we're able to access the TIME and TIMEH CSRs in
usermode. I would like to take advantage of this feature to replace the
proxies for syscalls, such as timer_gettime with an equivalent
implementation that avoids a context switch,
On 5/26/2024 8:10 PM, Stuart Ianna wrote:
Some of the integration at this level is going to be tricky, as Litex
customisations may not be risc-v generic.
The only guideline with this is that all RISC-V-and-Litex-specificlogic
needs to be constrained to reside in arch/risc-v/src or
boards/ris
Hi Gregory,
Apologies, possibly I wasn't clear with my description. I was referring to
having a method to *replace* a syscall with an architecture specific proxy.
For example, I should be able to use the usermode CSRs for providing
clock_gettime functionality.
Potentially, what you're suggesting
Adding non-standard APIs would be not be a good decision for the
future of a standards compliant OS.
Sorry to respond again. Perhaps I am not understanding properly. Are
you proposing another set of APIs or instead proposing to replace the
standard APIs with a different implementation.
On 5/26/2024 5:03 PM, Stuart Ianna wrote:
With the riscv/litex port, we're able to access the TIME and TIMEH CSRs in
usermode. I would like to take advantage of this feature to replace the
proxies for syscalls, such as timer_gettime with an equivalent
implementation that avoids a context switch
With the riscv/litex port, we're able to access the TIME and TIMEH CSRs in
usermode. I would like to take advantage of this feature to replace the
proxies for syscalls, such as timer_gettime with an equivalent
implementation that avoids a context switch, where appropriate.
I understand that th sys
