Re: Integrating port specific syscall proxies

[Nathan Hartman]

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 ARM and MIPS MMUs
> well.  I have never looked at the RISC-V MMU management code.
>
>   * If the MMU is enabled then in order to access any memory region, it
> must be mapped by the MMU.  Otherwise, you will get a segmentation
> fault.
>   * When the memory region is mapped, access to the memory region is
> then controlled by settings in the MMU mapping for that region.
> This includes things like protections, cacheability, etc.
>   * The MMU must be set up by software as part of the power-on
> initialization and process initialization (and perhaps later after a
> page fault or sbrk).  This includes setting of the memory region
> protections.
>   * In order to permit user access to a memory region, the MMU must be
> programmed to allow user space access to a memory region.  Otherwise
> attempts to access that region results in a segmentation fault.
>
> So it is software that determines what applications can access in user
> mode code.
>
> In a secure system, all kernel resources must be setup to allow only
> supervisor mode access.  User code must be isolated; it must be
> restricted so that it can only access memory in its process sandbox.
> This prevents many types of attacks on system from any hostile code.
>
> The fix is relatively simple (if the description of the issue is
> correct). In all places where kernel-only accessible memory is mapped by
> the MMU, the protection bits must be set so that user space access is
> prohibited. This might have side effects on any existing applications
> that access kernel memory resources.
>
>
In that case, I think we should ask the OP why they would like to access
the TIME and TIMEH CSRs from userland.

If I'm reading the original question correctly, it's to achieve a speed
optimization.

The relevant questions then are:

(1) Why is an optimization needed here?

(2) If code is calling timer_gettime() in a tight loop, causing a problem
where the execution time is too long, then can the OP's software be
re-architected to avoid doing this?

Nathan

Re: Integrating port specific syscall proxies

[Stuart Ianna]

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 the core is in
supervisor mode, user pages are accessible when the core is in usermode.

It is not my intention to access, modify or read memory which belongs to,
or is managed by the kernel. The CSRs I'm referring to are available in
usermode, see section 2.2 of
https://riscv.org/wp-content/uploads/2017/05/riscv-privileged-v1.10.pdf,
and are currently used and defined in NuttX. Note that this is a CSR
provided by the risc-v core, not a memory mapped peripheral or region.

My original query was on providing a way to have a different proxy for a
syscall. From what I understand, these are only generated by
tools/mksyscall at build time, based on the information provided in
syscall.csv.

Sorry if I caused any misunderstanding.

On Wed, 29 May 2024 at 23:50, 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 ARM and MIPS MMUs
> well.  I have never looked at the RISC-V MMU management code.
>
>   * If the MMU is enabled then in order to access any memory region, it
> must be mapped by the MMU.  Otherwise, you will get a segmentation
> fault.
>   * When the memory region is mapped, access to the memory region is
> then controlled by settings in the MMU mapping for that region.
> This includes things like protections, cacheability, etc.
>   * The MMU must be set up by software as part of the power-on
> initialization and process initialization (and perhaps later after a
> page fault or sbrk).  This includes setting of the memory region
> protections.
>   * In order to permit user access to a memory region, the MMU must be
> programmed to allow user space access to a memory region.  Otherwise
> attempts to access that region results in a segmentation fault.
>
> So it is software that determines what applications can access in user
> mode code.
>
> In a secure system, all kernel resources must be setup to allow only
> supervisor mode access.  User code must be isolated; it must be
> restricted so that it can only access memory in its process sandbox.
> This prevents many types of attacks on system from any hostile code.
>
> The fix is relatively simple (if the description of the issue is
> correct). In all places where kernel-only accessible memory is mapped by
> the MMU, the protection bits must be set so that user space access is
> prohibited. This might have side effects on any existing applications
> that access kernel memory resources.
>
>

-- 
*Kind regards,*

*Stuart Ianna*
*Firmware Engineer*

-- 
*MoTeC Pty Ltd*

121 Merrindale Drive
Croydon South 3136
Victoria Australia
*T: *61 3 9761 5050
*W: *www.motec.com.au 


-- 
  
 
 



-- 
 

-- 


Disclaimer Notice: This message, including any attachments, contains 
confidential information intended for a specific individual and purpose and 
is protected by law. If you are not the intended recipient you should 
delete this message. Any disclosure, copying, or distribution of this 
message or the taking of any action based on it is strictly prohibited.

Re: Integrating port specific syscall proxies

[Nathan Hartman]

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_gettime with an equivalent
> > implementation that avoids a context switch, where appropriate.
>
> I've been puzzling about this since this discussion started.  Do you
> mean that you can access the hardware interface from user-space?  If so,
> that would be a MASSIVE security hole and would make the port unusable
> in any product that has even the most minimal security requirements.
>
> That would really be an error.  It might be useful during debugging, but
> would be catastrophic for most uses.  Are you sure that you want to
> exploit such a design flaw this way?  I believe we should create an
> issue for any such behavior to that people are aware and plug that
> security hole as soon as possible.
>
> Or maybe I got that wrong.



That's a security hole in the *hardware*, not in software, right? How can
that be fixed (unless a new chip is made)?

Re: Integrating port specific syscall proxies

[Gregory Nutt]

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, where appropriate.


I've been puzzling about this since this discussion started.  Do you 
mean that you can access the hardware interface from user-space?  If so, 
that would be a MASSIVE security hole and would make the port unusable 
in any product that has even the most minimal security requirements.


That would really be an error.  It might be useful during debugging, but 
would be catastrophic for most uses.  Are you sure that you want to 
exploit such a design flaw this way?  I believe we should create an 
issue for any such behavior to that people are aware and plug that 
security hole as soon as possible.


Or maybe I got that wrong.

Re: Integrating port specific syscall proxies

[Gregory Nutt]

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/riscv/litex/src/litex and board/risc-v. That assures modularity 
and keeps the common code from devolving into a mess of conditional logic.


Header files containing RISC-V-and-Litex-specific definitions should 
similarly go in arch/riscv/include or boards/riscv/litex.


Different topic ...

NOTE also that there are two "copies" of most (but not all) system 
calls: One is for use by applications and calls the system call proxy. 
The other lies inside the kernel and is normally called by the OS, but 
also by the corresponding system call stub. I think in the model you are 
thinking about, the former would operate in user space using user space 
mappings (with no system call) and the latter would use kernel space 
mappings (it could not use user space mappings because those may not be 
in place when called asynchronously within the OS).

Re: Integrating port specific syscall proxies

[Stuart Ianna]

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 is going to be easier, where I could
add an architecture specific implementation for gettimeofday in libc.
However, there are other places where clock_gettime is used, so it could be
advantageous to provide a proxy at this level.

Some of the integration at this level is going to be tricky, as Litex
customisations may not be risc-v generic. However, if there is or were to
be a standard way of providing this functionality, we could integrate these
additions a uniform manner, and contribute pieces back which make sense.


On Mon, 27 May 2024 at 09:49, Gregory Nutt  wrote:

>
> > 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.
>
> Replacement of standard OS APIs with architecture specific versions of
> the same APIs is something that is done in several places in the OS.
> For example, this is done for several libc functions that can be CPU
> hogs (like memcpy, strcmp, etc.).  This is already done for RISC-V in
> libs/libc/machine/risc-v.  You could simply extend this for the
> optimized APIs that you want.
>
> That keeps the APIs standard and is very easy to maintain, especially if
> you were to follow the same pattern.  I would recommend that you look
> into these and see if this approach meets your need.
>
>
>

-- 
*Kind regards,*

*Stuart Ianna*
*Firmware Engineer*

-- 
*MoTeC Pty Ltd*

121 Merrindale Drive
Croydon South 3136
Victoria Australia
*T: *61 3 9761 5050
*W: *www.motec.com.au 


-- 
  
 
 



-- 
 

-- 


Disclaimer Notice: This message, including any attachments, contains 
confidential information intended for a specific individual and purpose and 
is protected by law. If you are not the intended recipient you should 
delete this message. Any disclosure, copying, or distribution of this 
message or the taking of any action based on it is strictly prohibited.

Re: Integrating port specific syscall proxies

[Gregory Nutt]

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.


Replacement of standard OS APIs with architecture specific versions of 
the same APIs is something that is done in several places in the OS.  
For example, this is done for several libc functions that can be CPU 
hogs (like memcpy, strcmp, etc.).  This is already done for RISC-V in 
libs/libc/machine/risc-v.  You could simply extend this for the 
optimized APIs that you want.


That keeps the APIs standard and is very easy to maintain, especially if 
you were to follow the same pattern.  I would recommend that you look 
into these and see if this approach meets your need.

Re: Integrating port specific syscall proxies

[Gregory Nutt]

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, where appropriate.

I understand that th syscall.csv database is used to generate the syscall
proxies and stubs, but there doesn't seem to be any facility to provide a
different implementation. Potentially, I could remove the desired syscalls
from syscall.csv and provide my own proxy which is linked into libproxies
but it would be nice if this was more generally supported, rather than
patching the kernel locally.

I'd be interested to know if anyone has had a similar idea, or potentially
there is a method to achieve this in Nuttx which I have overlooked.


I would caution that only POSIX or Linux APIs are permissible in the 
OS.  Being a standards compliant OS is a key to the identity and value 
of the OS.


Could you use the POSIX mmap() or shm* APIs to map the TIME and TIMEH 
addresses into user space.  Then you could access the timer values as 
simple reads?  That is how you would do something like this in Linux.


[Unless someone has extended it, I think mmap() is rather incomplete.  
shm* is the better bet].


Adding non-standard APIs would be not be a good decision for the future 
of a standards compliant OS.  But since this would be non-standard and 
would operate entirely in user space, it does not have to be within the 
OS.  [In fact it show not be part of this OS. ] You could create such 
special logic under apps/ where code does not need to conform to any 
standards.

Integrating port specific syscall proxies

[Stuart Ianna]

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 syscall.csv database is used to generate the syscall
proxies and stubs, but there doesn't seem to be any facility to provide a
different implementation. Potentially, I could remove the desired syscalls
from syscall.csv and provide my own proxy which is linked into libproxies
but it would be nice if this was more generally supported, rather than
patching the kernel locally.

I'd be interested to know if anyone has had a similar idea, or potentially
there is a method to achieve this in Nuttx which I have overlooked.
-- 
*Kind regards,*

*Stuart Ianna*
*Firmware Engineer*

-- 
*MoTeC Pty Ltd*

121 Merrindale Drive
Croydon South 3136
Victoria Australia
*T: *61 3 9761 5050
*W: *www.motec.com.au 


-- 
  
 
 



-- 
 

-- 


Disclaimer Notice: This message, including any attachments, contains 
confidential information intended for a specific individual and purpose and 
is protected by law. If you are not the intended recipient you should 
delete this message. Any disclosure, copying, or distribution of this 
message or the taking of any action based on it is strictly prohibited.