11 ms·
A secure embedded operating system for microcontrollers
- Mikhail_K 2y ago[flagged]
- klysm 2y agoIt is good when it’s actually implemented, the annoying part is suggesting a rewrite without doing anything
- palata 2y agoWhy 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 2y agoBecause 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 2y agoThat argument is most often the other way around
- thesuperbigfrog 2y ago>> 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 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 2y agoHow 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 2y agoBecause 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 2y agoI 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 2y agoAgain, without stating something more substantive about why the syntax is "incomprehensible" to them, my best assessment is always going to be "skill issue".
- gmueckl 2y agoWow, 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 2y agoCounterpoint: 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.
- 2y ago
- pjmlp 2y agoThere are already plenty of those to chose from.
- palata 2y agoWell 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 2y agoI am allowed to care if I am in any way responsible for its future maintenance, or become dependent upon it in my own project.
- palata 2y agoHmm... if you are part of the creators of the project, of course. Now if you don't like Rust, you should not become a maintainer of a Rust project, it's as simple as that. No need to go complain on every Rust project you find online. Same for your own project: don't become dependent upon a project that you don't want to have to deal with... If you do, then don't go complain about it: you made the choice to depend upon it.
- SpaghettiCthulu 2y agoWhat 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.
- helpfulContrib 2y ago[dead]
- vitiral 2y agoPretty sure this isn't so much a rewrite as a completely new architecture enabled by Rust's lifetime system.
- IshKebab 2y agoAre you saying that one must only ever write an OS in C? I don't get you anti-Rust zealots.
- bborud 2y agoAs 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 2y agoime 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 2y agoThis 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.
- ajhasjkhdasjk 2y agoYou can think of Rust as a containment zone to isolate the kind of people who would be a Rust programmer from people working on actual real things, obviously in C and C++.
- the__alchemist 2y agoIs 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 2y agoA 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 2y agoTechnically you could do the same in all three: C, C++ and Rust.
- the__alchemist 2y agoYou 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 2y agoHow common are these Memory Protection Units (MPU) in microcontrollers today?
- the__alchemist 2y agoThere 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 2y agoThere'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 2y agoThe 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 2y agoIt's technically optional on Cortex-M0+ and above, but in practice everyone includes one.
- ladyanita22 2y agoIs it mandatory?
- all2 2y agoIs there any way this works with Zephyr?
- AlotOfReading 2y agoIt's an OS at the same layer as zephyr. They're not compatible, but you'll see similarities between them.
- michaelt 2y ago> 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 2y agoThe 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.
- nolongerthere 2y ago[dead]
- Animats 2y agoThat'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.
- farseer 2y agoYocto 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.
- thebruce87m 2y ago> immediately I love yocto, but ‘immediately’ can sometimes take a while!
- ducktective 2y agoIt 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-helicopter-rover-fly-autonomously-mars https://spectrum.ieee.org/nasa-designed-perseverance-helicop...
- spiritplumber 2y agoI recommend TAQOZ for the Parallax Propeller 2.
- RobotToaster 2y agoThey made a second one? That's a blast from the past.
- spiritplumber 2y agoyep. while it's less "a decade ahead" than the prop1 was back then, it's still a powerhouse. we use it for autopilots.
- hoc 2y agoFor 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 2y agoI 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 2y agoThe 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 2y agoRight, 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?
- AnimalMuppet 2y agoAgain, these are not binary. I may decide I need a more feature-full (more "OS-like") task switcher for what I'm trying to do, without going to a full OS (by some definition). I may decide that I need some aspects of SoC in my microcontroller. (Youi can get pretty much any set of features with any core; it's more the number of desktop-like features that makes it a SoC.) To your specific question: I'm not sure it goes that direction, because a full OS depends on the presence of certain features on the chip. I can think of some examples of it going the other way, though - of an SoC where you don't need or want a full OS.
- comradelion 2y agoIt's the application that needs an OS, not the computer. It is possible (and isn't unheard of, though decreasingly common) to run software on a more featureful CPU with virtual memory and loads of RAM next door, without an OS, for example. And it of course depends what one means by "a OS." But, generally, if you are running multiple tasks that might depend on shared resources, you might want an OS---after all, an OS is just something that mediates shared resources among different applications. You might prefer to use a microcontroller because of power constraints, security (generally easier to mitigate physical attacks and side channels in simpler hardware), or cost and you don't need more resources.
- krisoft 2y agoThis 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 2y agoOne 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 2y agoHow does Tock compare to Oxide’s Hubris?
- comradelion 2y agoNote bcantrill's comment below for corrections of my misstatements here. 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.
- bcantrill 2y ago
- SandmanDP 2y agoPreviously discussed in 2017: https://news.ycombinator.com/item?id=15647452 https://news.ycombinator.com/item?id=15647452
- comradelion 2y agoShameless 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 https://world.tockos.org