[HN Gopher] A secure embedded operating system for microcontrollers
___________________________________________________________________
A secure embedded operating system for microcontrollers
Author : udev4096
Score : 105 points
Date : 2024-06-02 14:51 UTC (8 hours ago)
(HTM) web link (tockos.org)
(TXT) w3m dump (tockos.org)
| Mikhail_K wrote:
| Great, another "rewrite it in Rust" project!
| klysm wrote:
| It is good when it's actually implemented, the annoying part is
| suggesting a rewrite without doing anything
| palata wrote:
| Why would you care? If it's useful for you it's great, if not
| that's okay.
|
| Also it's open source (Apache/MIT) and I don't see a CLA, so I
| would say it's good.
| ranger_danger wrote:
| Because if I want to modify it, I prefer it to be in a
| language I understand. The syntax of Rust is incomprehensible
| to me.
| Levitating wrote:
| That argument is most often the other way around
| thesuperbigfrog wrote:
| >> Because if I want to modify it, I prefer it to be in a
| language I understand. The syntax of Rust is
| incomprehensible to me.
|
| It is a great time to learn Rust:
|
| https://www.rust-lang.org/learn
|
| It continues to see adoption in places where C and C++ were
| the primary choices.
|
| It is exciting to see it in the microcontroller OS space.
| gmueckl wrote:
| How is this a an appropriate answer to a (not totally
| baseless) complaint about bad developer ergonomics? GP
| didn't say how hard they tried learning rust. This comes
| off as needlessly condescending.
| reanimus wrote:
| Because if you can't understand the syntax it's quite
| literally a skill issue. They didn't give any substantive
| critique beyond "reading is hard".
| AnimalMuppet wrote:
| I assert that certain syntaxes work with how certain
| people think, and _don 't_ work with how certain other
| people think. You can train to get around that to some
| degree, but it's not entirely a skill issue.
| reanimus wrote:
| Again, without stating something more substantive about
| _why_ the syntax is "incomprehensible" to them, my best
| assessment is always going to be "skill issue".
| az09mugen wrote:
| More than the syntax, it's the verbosity. The more you
| have to read the more you have to process. Did anyone in
| the creators of Rust have a look at the syntax of
| Crystal, Kotlin, Julia, or Elixir ? They're simple, you
| really don't have to put a lot of effort into reading.
| Rust looks like C took the verbosity of Java as a
| mandatory requirement and borrowed some cool concepts of
| Haskell (but not the simplicity of its syntax though).
| reanimus wrote:
| Part of it is the explicitness mandated by the language
| (i.e. when dealing with Optionals or Results, you have to
| deal with both cases or explicitly state which you expect
| as an invariant). There's also curious (imo) choices on
| the part of rustfmt that seems to favor density of code
| that way.
| gmueckl wrote:
| Wow, this is just doubling down condescension again,
| while insinuating laziness baselessly. I resent that,
| especially when it is about a language that has parts
| that were _intentionally_ designed to yield hard to read
| code.
| pessimizer wrote:
| Counterpoint: Rust is easy to read, and none of it was
| designed to be hard to read.
|
| If you make a website listing the languages you do
| understand, people who are concerned can consult it
| before they begin a project.
| reanimus wrote:
| > insinuating laziness baselessly
|
| > intentionally designed to yield hard to read code
|
| I think if you assume that syntax you find odd/difficult
| was intended to confound you, I can safely make
| assumptions of my own.
| pjmlp wrote:
| There are already plenty of those to chose from.
| palata wrote:
| Well if I want to write an OS in Fortran, BASIC, nodejs or
| even assembly, I think it is my choice. If you don't like
| it, just ignore it, I really don't see the beginning of a
| problem there.
|
| I understand complaints in other contexts: for instance, if
| one sends tens of thousands of satellites or burns forests,
| the mere fact that they are doing it may bother me. But
| again: what do you care if somebody writes a software
| project in a language you don't like?
| pklausler wrote:
| I am allowed to care if I am in any way responsible for
| its future maintenance, or become dependent upon it in my
| own project.
| SpaghettiCthulu wrote:
| What a selfish, narrow-minded take.
|
| If I want to modify it, I prefer it to be in a language I
| understand. The syntax of C/C++ is incomprehensible to me.
|
| See? Anyone can do it. That genre of argument is meritless.
| vitiral wrote:
| Pretty sure this isn't so much a rewrite as a completely new
| architecture enabled by Rust's lifetime system.
| IshKebab wrote:
| Are you saying that one must only ever write an OS in C?
|
| I don't get you anti-Rust zealots.
| bborud wrote:
| As someone who does some embedded development and also has a
| deeper general software background than most full time embedded
| developers: having a few large players in the MCU and/or
| industrial automation sector support a from-scratch effort to
| build a decent embedded OS in Rust, with ditto tooling, would
| be a game changer.
|
| Most current embedded and RTOS operating systems and
| development toolchains are just horrific. Hence, most of the
| things around us that control important things, depend on much
| weaker foundation that you'd like to imagine.
| chillingeffect wrote:
| ime that's due to the number of variants and peripherals, not
| the language/os. See nrf device trees which morph w every rev
| of the sdk for example.
| bborud wrote:
| This is mostly a manifestation of MCU manufacturers having
| trouble just managing their own challenges and not having
| the capacity to even start thinking about what it is like
| to use the devtools for customers.
|
| They love Zephyr because it helps them solve _their_
| problems. That it is a pain in the ass for developers isn
| 't something they seem to spend much time thinking about.
| Or even seem to be aware of the importance of.
| the__alchemist wrote:
| Is this for if you are writing firmware that has non-cooperative
| processes (eg installable applications)? It sounds like it from
| the description. Of note, it seems like in C and C++, it is
| common use an RTOS for any project. In rust, you can get away
| with a lot (including complex programs with lots of IO) without
| one. Eg, using interrupts, DMA, timers etc to build an event loop
| and manage asynchronous events.
| therein wrote:
| A loop that puts you into a deeper sleep that you can be woken
| up by interrupts from DMA, timers, GPIO etc. would provide the
| same.
|
| I like Rust as much as the next guy but let's not pretend we
| couldn't do this with C, C++ or assembly.
| ladyanita22 wrote:
| Technically you could do the same in all three: C, C++ and
| Rust.
| the__alchemist wrote:
| You can do this in C, C++, assembly, but my observation is
| that many projects are started with an RTOS, even if they are
| cooperative and/or simple.
| RetroTechie wrote:
| How common are these Memory Protection Units (MPU) in
| microcontrollers today?
| the__alchemist wrote:
| There are certain lines that include security features designed
| for IoT. Becoming more popular. Arm Cortex-m33 etc. so, stm32
| L5, U5, nRF-53 etc. Lots of options if you want this. But most
| MCUs don't have them.
| bajsejohannes wrote:
| There's also MPU in even simpler/cheaper MCUs. For instance,
| ARM Cortex M0+ sports an MPU, and this architecture is used
| in STM32C0 ($0.24 in bulk) and RP2040.
|
| I have no idea how the landscape looks in general, though.
| comradelion wrote:
| The vast majority of modern MCUs have enough memory
| protection for Tock. Anything cortex-m0+ or "better" has an
| MPU. RISC-Vs PMP or ePMP as well. Most 16-bit "legacy"
| (though still popular) MCUs don't.
|
| Virtually anything with a radio these days (the MSPs were
| holdouts but mostly those are Cortex-M these days as well)
| ctz wrote:
| It's technically optional on Cortex-M0+ and above, but in
| practice everyone includes one.
| ladyanita22 wrote:
| Is it mandatory?
| all2 wrote:
| Is there any way this works with Zephyr?
| AlotOfReading wrote:
| It's an OS at the same layer as zephyr. They're not compatible,
| but you'll see similarities between them.
| michaelt wrote:
| _> Security critical devices, like TPMs and USB authentication
| fobs, are actually multiprogramming environments running
| applications written by different people._
|
| Eh, that doesn't sound like the design of a security-critical
| device to me.
|
| Many a "secure execution environment" has failed to deliver its
| security guarantees after some third-party clown was given access
| to run their DRM module or whatever, and introduced
| vulnerabilities while doing so.
|
| Devices that are serious about security tell the third party
| clowns to get their own chip. Although they may use a secure
| operating system as an extra layer of security, if it promises
| that.
| beardyw wrote:
| The term "microcontroller" covers about a gazillion different
| chips, most of which this doesn't address. (The one which makes
| your Christmas tree lights flash?) It needs to be qualified.
| Animats wrote:
| That's reasonable. There's a lack of good, free OSs for the space
| above Arduino and below Linux on Raspberry Pi. That's the land of
| VXworks and QNX, which are good, but not free. So people end up
| running an entire Linux environment, with all its
| vulnerabilities, on something that doesn't need it.
| ducktective wrote:
| It would be nice if any NASA engineer could weigh in on why
| they used Linux for that Mars helicopter instead of an RTOS
| like mentioned above.
|
| https://spectrum.ieee.org/nasa-designed-perseverance-helicop...
| farseer wrote:
| Because it's easy to work with. Even low end processors
| support it as long as they have an mmu.
| amelius wrote:
| But why not a _real-time_ OS? What if Linux schedules some
| unimportant job just as the helicopter is about to perform
| an important manoeuvre?
| vbezhenar wrote:
| I don't know specifics of this helicopter, but:
|
| 1. You can apply patches which turn Linux into RTOS.
|
| 2. You can offload RTOS-specific tasks into separate
| simpler MCUs and use ordinary OS to communicate with them
| in a more relaxed way.
| NoahKAndrews wrote:
| Linux can do real-time scheduling. Most of the patches
| for that have been merged into mainline at this point,
| but they've existed out of tree (with real use) for a
| long time.
| RobotToaster wrote:
| Doesn't GNU/linux have optional real time extensions?
| sillywalk wrote:
| It looks like Linux is doing higher-level stuff, and the
| real-time is done by a pair of redundant MCUs and a
| FPGA.[0]
|
| It's running F' (F Prime) flight control software,[1]
| which can run under Linux, as well as on MCUs with no OS.
| I'm not sure on which processors it's running.
|
| "The two redundant TI Hercules safety processors serve as
| the low-level flight controller (FC); each has dual-core
| lockstep ARM Cortex-R5F and ECC protected Flash and RAM.
| The two processors run in sync and are provided with the
| same clock and data by the FPGA, which handles all the
| sensors and actuators interface. The lockstep mechanism
| does cycle by cycle error detection. If a fault is
| detected, it signals the error to the FPGA; the FPGA
| switches to the other processor and power cycles the
| faulty one, so the flight control software continues to
| run without disruption.
|
| ..
|
| At the heart of the helicopter avionics is a Field-
| Programmable Gate Array (FPGA). The FPGA implements the
| custom digital functions not implemented in software due
| to resource limitations of the processors (e.g. I/O or
| bandwidth limits), timing requirements, power
| considerations, or fault tolerance considerations. The
| FPGA device is a military-grade version of MicroSemi's
| ProASIC3L, which uses the same silicon as the radiation-
| tolerant device from the same family. The FPGA perform
| all critical I/O to the sensors and actuators, and fault
| managment functions including detecting error flags from
| the MCU and hot-swapping to the functioning MCU in case
| of an error. The FPGA performs vehicle flight control
| including an attitude control loop operating at 500 Hz,
| an outer motor control loop, waypoint guidance, sensor
| I/O from the IMU, altimeter and inclinometer, and analog
| telemetry for current and temperature sensing. It is
| responsible for system time management, interfaces to the
| IMU, altimeter and inclinometer sensors. It implements
| the "inner" motor control loop used for the two brushless
| rotor motors and the six brushed motor servos (three at
| each rotor swashplate), as well as power management and
| thermal control functions."[0]
|
| [0] https://rotorcraft.arc.nasa.gov/Publications/files/Ba
| laram_A...
|
| [1] https://nasa.github.io/fprime/
| kibwen wrote:
| Ingenuity had a relatively shoe-string budget and leaned
| heavily on off-the-shelf components. It was also a technology
| demonstration rather than anything mission-critical, so it
| didn't need absolute reliability.
|
| Which isn't to say that NASA wouldn't necessarily use Linux
| in mission-critical applications; there exist real-time
| patches for Linux.
| 6SixTy wrote:
| That space is usually filled by FreeRTOS, no?
| roland35 wrote:
| FreeRTOS, and zephyr now
| SV_BubbleTime wrote:
| FreeRTOS isn't an OS. It's a nice scheduler. Which is what
| the vast majority of people want and need when they think
| embedded.
|
| Zephyr, is an OS. And imo will be eclipsed by embedded
| variants of Linux quickly as chips are coming up in
| performance. There is just no path for co-existence I see.
| pjmlp wrote:
| Zephyr, NutXX, and others aren't GPL, and that is a big
| deal for those folks.
| jononor wrote:
| Zephyr and Linux are not competing, generally. There are
| literally billion devices shipped annually in Zephyr
| niche - microcontrollers with under 1 MB RAM. This will
| continue the next 10 years - as for significant of the
| market cost reductions will go into power and radio
| improvements - not spending money on RAM and FLASH to run
| Linux.
| squarefoot wrote:
| There's a good number of them, although most aren't widely
| known outside of the embedded world.
|
| Here's a list: https://www.osrtos.com/
| farseer wrote:
| Yocto Linux can be stripped down to the bare minimum for
| embedded applications. You can reduce your attack surface by a
| lot. The advantage of Linux on embedded is your new developers
| are up and running immediately. Something not possible with all
| the rest of os/rtos. Additionally lots of packages for
| diagnostic utilities like iperf etc are available even for
| obscure processors that run Linux. As long as battery life
| isn't a concern, let embedded Linux be an overkill, the
| advantages are just too great.
| RobotToaster wrote:
| Microsoft ThreadX is open source.
|
| I guess minix is kinda in that space too.
|
| FreeRTOS has already been mentioned, but there's also
| NuttX/Vela.
| efrecon wrote:
| Isn't contiki-ng another one?
| buescher wrote:
| Micrium (uC/os-ii, uC/os-iii) is open source now. Best dead-
| trees book for an RTOS. I haven't shipped anything on it, so
| I have no other opinion.
|
| https://github.com/weston-embedded/uC-OS3
| tonetegeatinst wrote:
| Wouldn't something like tiny core Linux be the best compromise?
| Its the Linux kernal + bare essentials. You could probably
| harden it and modify it for this scenario
| spiritplumber wrote:
| I recommend TAQOZ for the Parallax Propeller 2.
| RobotToaster wrote:
| They made a second one? That's a blast from the past.
| hoc wrote:
| For that Nordic 52 dongle... the ones I bought early on had
| locked bootloaders and only allowed apps on top of that, AFAIR,
| and needed at least some HW debugger connection to remove it.
|
| Is this still necessary, included for TOCK or is not needed at
| all?
| bongodongobob wrote:
| I feel like if your microcontroller needs an OS you should be
| using an SoC? Genuinely wondering why'd you'd need an OS on a
| microcontroller.
| AnimalMuppet wrote:
| The line between "OS" and "not OS" is not binary. It's a blur.
| For that matter, there's not a clear line between
| "microcontroller" and "SoC", either.
|
| Does your microcontroller have an external flash? Does it have
| a file system on that flash? Does that make it need an OS to
| support the file system?
|
| Does it have enough memory to support allocation to different
| processes? Does that make it need an OS? And so on.
| bongodongobob wrote:
| Right, that's my question. You can use flash and display and
| whatnot without an OS. When are you using a microcontroller
| that you'd need the overhead of an OS where an SoC wouldn't
| be appropriate?
| krisoft wrote:
| This looks quite interesting and promising.
|
| Just to illustrate how hard is to naming things without
| accidentally colliding with some meaning in some language:
| "tockos" in hungarian means a light smack, specifically one aimed
| at the back of the head. Luckily that is something I quite often
| want to give to computers (micro or otherwise). So all is well
| with the balance of the universe.
| comradelion wrote:
| One of the Tock maintainers here, happy to answer any questions.
|
| For some context, Tock has been around for a number of years now
| (we first built it in 2015). Beyond it's intended original
| purpose (naval gazing academic research) it runs the Chromebook
| embedded controller, has similar other similar applicatioms in
| data center root-of-trust, Microsoft's Pluton (rumor has it, for
| some future version anyway), and others.
| fanf2 wrote:
| How does Tock compare to Oxide's Hubris?
| comradelion wrote:
| Oxide was involved with Tock before building Hubris. They are
| similar in some ways with somewhat different "visions" for
| the end use case. Hubris compiles all "applications" into the
| "kernel", and relies exclusively on the type system for
| isolation---in this sense it is a much more traditional RTOS,
| just written in Rust (and well designed!). Whereas Tock
| targets applications that are not just in Rust, and may be
| dynamically load/replaced/removed separately from the kernel
| ---in this sense it is much more similar to a traditional
| desktop/server OS but designed for significantly lower
| resourced settings. This also makes Tock more robust to
| applications that are actually untrusted or unreliable.
|
| There is also of course a difference in development and
| evolution. Hubris is developed by Oxide and released open
| source, while Tock is more community based and, thus, more
| open to supporting a variety of use cases. This is both bad
| and good. If your use case is exactly Oxide's use case, it's
| likely Hubris is better than Tock (there is just no design
| decision baggage for other use cases). If you're use case is
| a bit different, Tock starts to be more appropriate.
|
| A side note that I think the Hubris-Tock relationship is a
| real positive case for open source development. Oxide was
| very transparent and forthcoming when they decided to switch
| away and offered a lot of useful feedback. I hope they took
| some ideas from Tock and I think we took some ideas from
| following Hubris.
| nevi-me wrote:
| What are practical applications that I can build for home use
| on Tock, using either ESP32-C3 or NRF52840 dongle?
| comradelion wrote:
| In principle many things, but you're mostly restricted by
| what you can meaningfully physically build with off the shelf
| parts. Prototyping with a bunch of wires on a bread board is
| one thing... Sticking that on your wall is another. And most
| off the shelf dev kits have very few useful sensors/actuators
| on board.
|
| The cannonical thing is an environment sensor (so a
| temperature et al sensor). Unfortunately, often a larger HVAC
| system will integrate with sensors through some proprietary
| protocol (even Thread based systems like Nest don't
| necessarily work with just any thread-based sensor, but you
| could of course hack something with Home assistant).
|
| One of the maintainers has been using it on the side for a
| plan monitoring system.
|
| All of these require some sensors beyond just the dev kit,
| which are typically pretty bare bones.
|
| You can build a two factor auth device with the nrf52840
| dongle (OpenSK is built with Tock), which requires basically
| no extra peripherals.
|
| I've used the nrf52840dk to control a garage door, which
| similarly only need a couple wires.
| sillywalk wrote:
| I thought the Chromebook embedded controllers run Zephyr?
| comradelion wrote:
| Nope. It used to be a home baked solution that was totally
| unrelated to (and pre-dates) Zephyr. I believe that is the
| one that is still in the ChromiumOS EC repo, but for the last
| year or so, it's a Tock-based system.
| transpute wrote:
| _> Microsoft 's Pluton (rumor has it, for some future version
| anyway)_
|
| Which embedded OS does Pluton run today?
| comradelion wrote:
| Good question, I don't know! I would guess it's a home baked
| solution, but I believe Pluton, the hardware, is changing as
| well (I am not an authority on this, I only know a bit from
| talking with the developers at Microsoft who work on the next
| gen stuff).
| transpute wrote:
| Sounds promising. Pluton (AMD Ryzen and Qualcomm
| Snapdragon) running OSS Tock would be huge.
| hollerith wrote:
| I was unimpressed after reading Tock's home page (and I think I
| read it all), but then I was quite impressed by your "runs the
| Chromebook embedded controller" (because the ChromeOS team
| seems to me to be great at security).
|
| I humbly suggest adding that to the home page (being careful to
| mention that the ChromiumOS EC repo has not been updated to
| reflect that fact and to mention that before about a year ago,
| something else ran the EC).
| SandmanDP wrote:
| Previously discussed in 2017:
| https://news.ycombinator.com/item?id=15647452
| comradelion wrote:
| Shameless plug for anyone interested in these kinds of systems
| and near or able to travel to San Diego, that TockWolrd is
| happening at the end of this month and has general-audience
| oriented talks and tutorials for this first year! Please join us!
| https://world.tockos.org
___________________________________________________________________
(page generated 2024-06-02 23:01 UTC)