gpoulios opened a new pull request, #15278:
URL: https://github.com/apache/nuttx/pull/15278

   ## Summary
   
   At least on RISC-V, TCP server sockets were pretty much unusable on high 
load environments and kernel build.
   
   User addresses passed to `accept()` would be accessed when the wrong MMU 
mappings were active. A crash would manifest when attempting to `accept()` for 
instance on a TCP server socket under significant load. The accept event 
handler would be called by the HP worker upon client connection. At this point, 
`accept_tcpsender()` would attempt to write to `addr` resulting in a page 
fault. Reproducibility would depend on the current system load (num tasks or 
CPU stress) but in loaded environments, it would crash almost 100% of the times.
   
   ## Impact
   
   The change should be transparent to users. `accept()` now maps pointer 
arguments to kernel virtual memory before proceeding. It also checks whether 
the given pointers indeed point to user memory.
   
   It should be noted that Linux does this the other way around: it operates on 
kernel stack allocated data and once done, it copies them to user. This can 
also be a viable alternative, albeit with one extra copy and a little extra 
memory.
   
   ## Testing
   
   ### RISC-V testing only
   
   Prior to patch: trying with `CONFIG_NETUTILS_NETCAT=y` would cause a store 
fault once a client attempted to connect. The point of the crash was 
consistently `tcp_accept.c / accept_tcpsender()` at the first write to the 
`inaddr` structure ([line 
102](https://github.com/apache/nuttx/blob/5d68ab635c065d97ac0cbc08372be7c37fb59d02/net/tcp/tcp_accept.c#L102)):
   
   ```
   knsh> netcat -l 9999
   log: net: listening on :9999
   riscv_exception: EXCEPTION: Store/AMO page fault. MCAUSE: 000000000000000f, 
EPC: 00000000a002f4d2, MTVAL: 00000000c000af90
   riscv_exception: PANIC!!! Exception = 000000000000000f
   [...]
   ```
   ...where 0xc000af90 is the 2nd argument passed to `accept()`.
   
   After the patch: `accept()` works normally after multiple connections.
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to