Protect RAM from unwanted writes

Hi,

I'd like to have a memory region with some data that should only be written by some special functions, but can be read by the whole system.

This is to make sure that no bugs in other parts can accidentally corrupt this data. In previous projects on STMs I achieved this by using the MPU and a priviledged mode to write.

What is the recommended way to do this with Nordic Connect SDK / Zephyr RTOS on the nRF5340?

I saw that using the User mode can do that, but this adds a lot of overhead to system calls and is probably not the right choice.

Best regards,

Lars

Parents
  • Hi Lars,

    Could you clarify further what you want to protect this RAM region against? Is it against certain malicious attack?

    If security of the data is your concern, then you can consider the PSA Protected Storage. My colleague Sigurd has a blog on persistent storage here:  Persistent storage of keys and data using the nRF Connect SDK .

    The blog is on persistent storage, but PSA Protected Storage also supports volatile storage. The information therefore will still be applicable.

    Please reply and let me know if it this suits your need. I will actually be out of office from tomorrow, but another engineer will be assigned if you need any further help.

    Best regards,

    Hieu

Reply
  • Hi Lars,

    Could you clarify further what you want to protect this RAM region against? Is it against certain malicious attack?

    If security of the data is your concern, then you can consider the PSA Protected Storage. My colleague Sigurd has a blog on persistent storage here:  Persistent storage of keys and data using the nRF Connect SDK .

    The blog is on persistent storage, but PSA Protected Storage also supports volatile storage. The information therefore will still be applicable.

    Please reply and let me know if it this suits your need. I will actually be out of office from tomorrow, but another engineer will be assigned if you need any further help.

    Best regards,

    Hieu

Children
  • Hi Hieu,

    thanks for your answer.

    My main goal is not to protect against malicious attacks, but rather to protect special memory regions against some bugs I create elsewhere. For example a thread that has a buffer overflow or is writing to an invalid location should not be able to overwrite some important data (to guarantee this, data shall only be manipulated by functions with some priviledged mode).

    All code running on the device can be trusted as it is written by myself, though of course it may contain afromentioned bugs. So user mode is probably not the right choice due to its overhead with syscalls that I use extensively.

    Best regards,

    Lars

  • Hi Lars,

    First, I was wrong before.
    I told Hieu that the PSA Persistent Storage API supports volatile storage. And today I found out that it does not support volatile information.

    I will continue helping in this case.

    colar said:
    My main goal is not to protect against malicious attacks, but rather to protect special memory regions against some bugs I create elsewhere. For example a thread that has a buffer overflow or is writing to an invalid location should not be able to overwrite some important data (to guarantee this, data shall only be manipulated by functions with some priviledged mode).

    In my explanation, I will use NSPE and SPE. See  An Introduction to Trusted Firmware-M (TF-M) for an explanation of these.

    Since PSA Protected Storage does not RAM, I think that is not what you need after all.

    But if you only need some RAM storage, you can leverage TF-M without using its PS Protected Storage.
    You can create a custom Application RoT Services which just saves a variable. This variable will live inside the SPE, which your NSPE can not access.
    This way, you assure that any bugs you do create in the NSPE will not affect your stored variable.

    Does this sound like what you need?

  • Hi,

    I don't think that this fits my application since the whole application should be able to access the variables (read) directly without any overhead.

    The whole application should also be able to write to variables, but only in a function made for that. What I imagine is something like

    __attribute__((__section__(".protected_region"))) int variables[1024];
    
    int read_variable(int index) {
        return variables[index];
    }
    
    void write_variable(int index, int value) {
        k_sched_lock();
        enable_write_to_protected_region();
        variables[index] = value;
        disable_write_to_protected_region();
        k_sched_unlock();
    }
    
    // This should throw an error:
    void write_unallowed_stuff() {
        variables[0] = 123; // throws a fault since write access has not been aquired
    }

    Best regards,

    Lars

  • TF-M levearges the SPU for its memory protection.

    You could maybe implement SPU functionality for the SPU to do RAM access control.
    To control this, I think you can have a look at SPU hal.

    TF-M uses the SPU as well, so you might have to be careful if you intend to use both at the same time.

    For the record, I recommend that you use TF-M application RoT Services instead

  • Hi,

    I've already looked into that and think it is a bit too much overhead.

    With the STM32L4 it was as simple as configuring the MPU to only allow writing in priviledged mode, so I could read my "variables" from everywhere but only write to them by switching to priviledged mode first. This induced almost no overhead and is what I intend to do with the nRF5340.

    With the SPU in nRF5340, I only see the option to specifiy permissions for secure and non-secure domains, not for priviledged/inpriviledged, so to use that feature I MUST use secure/non-secure domains. Am I right with that?

    And to read/write from non-secure code (no matter if with the application RoT services or not), all accesses have to go over an API, then IPC from non-secure to secure image and then back, right? This sounds like a lot of runtime overhead.

    Are there other options to that or have I misunderstood some aspect of the nRF5340's features?

    Best regards,

    Lars

Related