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.

Hi, Nathan,

I think you are hitting on the crux a very important discussion that needs to be had about IoT directions.  Historically, IoT OS's have been primitive little things from Contiki, RIOT, MyNewt, Zephyr, etc.

But IoT vendors have become very aware of security issues. Imagine the consequences if someone could hack into your smart home, your IoT based utilities, security system, or your car. Automotive is really driving security issues in small MCUs. Breaking into Xiaomi smart home IoT systems has quite a few followers in the hacker world.  So IoT needs high quality, more-or-less undefeatable security.

Distributed systems also need remote updates and customizations as you would be from the use of installable ELF files.

And, yes, you are right.  Embedded systems need to be small, low cost, with minimal resources.

I don't really know how to resolve all of this.  The discussion, I think, involves only PROTECTED and KERNEL builds.  So I would hope that any additional security burden would apply only to those builds without impacting the FLAT builds.  I think in the case of PROTECTED and KERNEL builds, increased memory usage will be a natural consequence of adding security features.  If such a base kernel could be produced in a few 100's of Kb, then I think it would still be a viable solution for that space.

Still more questions than answers.

Greg



Reply via email to