Hello,

I dont agree. A fundamental feature to avoid widespread developement of the so-called Internet of Shit is basic embedded security.


Some thoughts:

An embedded system can have a minimal security. Of course security has several levels from non-existent to ideal.

Not having a full PKI protected secure boot does not mean some protections could not be used.


The question here is not adressable generally in ALL embedded systems, but the use of the ARM MPU could help a lot.

As anyone probably already knows, the ARM MPU is a MMU with a one-one virtual/physical mapping. It can be used to enforce access rights on selected memory zones. The MPU could be updated at each task switch to ensure that only the mem zones for the current task are usable.

The MPU could prevent the user app from reading the kernel flash and RAM when running in user space. Starting a system call then enables the MPU settings for supervisor mode.

The system calls could check the validity of passed pointers against the currently valid memory protection settings to avoid clobbering and reading kernel and/or other task memory zones. This single feature does not even need an MPU, just knowledge of application address boundaries.

True, it is complex and would need linker support or loadable apps.

True, it could be bypassed, but the requirements to do that would be a bit more complex than nothing.

Any security feature available should be used.

It is a common fallacy to state that bypassable security is not useful.

It is still better than no security at all.

It can also be useful to prevent... well, plain memory corruption bugs.


Sebastien

Le 25/02/2020 à 17:08, Nathan Hartman a écrit :
On Tue, Feb 25, 2020 at 10:59 AM Gregory Nutt <spudan...@gmail.com> wrote:
I think that most syscall which contain pointer has the security issue
in PROTECTED/KERNEL mode.
Certainly if high security is need, they all should be reviewed. Linux
goes to a lot of trouble to access data pointed to by user-provided
pointers. We might need to add all of those access macros in the future.

KERNEL mode is a little more complex in that you also have to assure
that the correct MMU mappings are in place before to access user data
from a different kernel thread (like a work queue).
The whole point of using a RTOS is to get a LIGHTWEIGHT operating
system. This is for embedded microcontrollers costing from cents up to
a few dollars in products that run embedded software logic.

If you need the sort of "security" that makes it possible to run
totally untrusted code, then maybe you need a full blown operating
system, which also comes with a full blown computer and not an
embedded microcontroller.

Cheers,
Nathan

Reply via email to