Re: NAND Flash supported Board suggestion

[Sebastien Lorquet]

Hello,

Yes, the inability to write individual bits in already programmed 
sectors is a HUGE constraint. We have flash like this in some high 
security embedded products, and it required a full redesign of our flash 
interface.


Wear leveling is doable, but the particular bit that made us think 
*very* hard was the interruption recovery. Which is critical in any 
embedded product where the battery can be removed any time.


This stuff is not trivial at all. If you find an easy solution, then 
test it over 9000 times under load stress, because it might be the wrong 
solution.



Remember, flash memory is analog, bits are just a bunch of electrons in 
a floating gate, and their value is determined by thresholds, that 
change with temperature and the age of the captain.


Any interruption can result in half-written or half-erased bits, that 
are unstable and change value at each read.


Sebastien


On 25/05/2024 21:38, Gregory Nutt wrote:

> Mr. Greg Nutt implemented it for Atmel about 10 years ago, but if I
> remember correctly, he never got it well tested because there is no 
FS for

> NAND on NuttX.

I did test the FS's that were available and they mostly worked on 
these platforms.  I could actually run nxffs and smartfs for a long 
while before they failed. They failed because the FSs that I looked at 
assumed that you can always write a "1" to a "0". Actually, you can do 
that but this then results in ECC error. Even a single bit 1=>0 change 
requires a full  erase, re-writing the ECC, and a full sector write.


As I recall, nxffs would write some single "0" bits to indicate sector 
state changes; SmartFS had a small counter that was used to manage 
wear leveling.


> I think if you decide to use an SPI NAND Flash with ECC and bad block
> support in HW it will be easier to test your FS, in this case even 
LittleFS

> could work:
> https://github.com/littlefs-project/littlefs/issues/11

Sparing and wear-leveling would also be needed.

> But later on we will need to get ECC and bad block table support on 
NuttX

> to validate your FS with some native NAND Flash controller.

I think that software bad block and ECC are already supported and 
verified (but it has been awhile since I used them).  Sparing, and 
wear-leveling are normally done by an FTL, but can be done by the file 
system.  Bad block detection and ECC may be done by hardware, FTL, or 
higher level software.  Then the only outstanding issues are finding 
such an FTL and a file system that does not do read-modify-write 
operations without updating the ECC.


LittleFS was a candidate a few years ago and required a special FTL to 
get all of these features.  Maybe that has changed in more recent 
versions.

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 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