I love projects like this. I've considered getting a smartwatch. Something like this makes the idea more appealing. Whats the most hackable watch? Is there a pinephone of smartwatches?
PineTime with wasp-os!
Oxide on My Wrist: Hubris on PineTime was the best worst idea
11–20 of 51 posts
Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea
#12Thanks for the shoutout on the twister :)
Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea
#13Earlier quoted context omitted.
People often have good reason to not adopt existing systems. Oxide started with TockOS and have written and talked about why they didn't end up using it. This twitter space goes into a lot of detail: https://www.youtube.com/watch?v=cypmufnPfLw But at the end of the day, no_std will allow a bigger ecosystem and sharing between many of these projects.
Thing is, it's not even clear that their added elements are all that sensible. If you're always running trusted tasks on your embedded hardware, what do you need the MPU for? Even in principle, it can only save you a bounds check. And if you start running outside code, then the clear privilege separation in Tock between trusted "Capsules" and other "Tasks" starts looking plenty attractive. Even OP notes that this MPU…
Data-execution exploits mean that you may accidentally run code you weren't expecting to.
If you have any kind of message parser taking input from an external system and examining it, you may be vulnerable to these types of exploits without realising it.
Having the ability to mark (for example) your stack as non-executable is a simple change that can remove a whole class of problems.
That is only the skimming the surface tho.
Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea
#14Earlier quoted context omitted.
Thing is, it's not even clear that their added elements are all that sensible. If you're always running trusted tasks on your embedded hardware, what do you need the MPU for? Even in principle, it can only save you a bounds check. And if you start running outside code, then the clear privilege separation in Tock between trusted "Capsules" and other "Tasks" starts looking plenty attractive. Even OP notes that this MPU…
Data-execution exploits mean that you may accidentally run code you weren't expecting to. If you have any kind of message parser taking input from an external system and examining it, you may be vulnerable to these types of exploits without realising it. Having the ability to mark (for example) your stack as non-executable is a simple change that can remove a whole class of problems. That is only the skimming the sur…
Yes, this is a concern in memory-unsafe languages like C. But Rust can build memory-safe primitives with only a modest amount of runtime checking wrt. inherently unsafe operations.
(Of course, having better formal models of how 'unsafe' code behaves might allow us to be a lot more rigorous in building safe primitives, such as by endowing some 'unsafe' calls with proof objects that might reify the outcome of a bounds check.)
Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea
#15The github repo of hubris [0] is very nice, as they immediately tell you where what is, e.g. drv/ contains drivers, a mix of simple driver lib crates and fully-fledged server bin crates. Current convention is that drv/SYSTEM-DEVICE is the driver for DEVICE on SYSTEM (where SYSTEM is usually an SoC name), whereas drv/SYSTEM-DEVICE-server is the server bin crate. Why does nobody do this in their readmes normally? They…
No post body was provided.
Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea
#16Earlier quoted context omitted.
People often have good reason to not adopt existing systems. Oxide started with TockOS and have written and talked about why they didn't end up using it. This twitter space goes into a lot of detail: https://www.youtube.com/watch?v=cypmufnPfLw But at the end of the day, no_std will allow a bigger ecosystem and sharing between many of these projects.
Thing is, it's not even clear that their added elements are all that sensible. If you're always running trusted tasks on your embedded hardware, what do you need the MPU for? Even in principle, it can only save you a bounds check. And if you start running outside code, then the clear privilege separation in Tock between trusted "Capsules" and other "Tasks" starts looking plenty attractive. Even OP notes that this MPU…
That is just one of many reasons and not the main one. Again, actually watch and listen to the associated talks/blogs/docs and so on.
Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea
#17Earlier quoted context omitted.
Data-execution exploits mean that you may accidentally run code you weren't expecting to. If you have any kind of message parser taking input from an external system and examining it, you may be vulnerable to these types of exploits without realising it. Having the ability to mark (for example) your stack as non-executable is a simple change that can remove a whole class of problems. That is only the skimming the sur…
Yes, this is a concern in memory-unsafe languages like C. But Rust can build memory-safe primitives with only a modest amount of runtime checking wrt. inherently unsafe operations. (Of course, having better formal models of how 'unsafe' code behaves might allow us to be a lot more rigorous in building safe primitives, such as by endowing some 'unsafe' calls with proof objects that might reify the outcome of a bounds…
Defence in depth. Rust isn't completely immune to memory safety bugs, due to the need for unsafe code underlying many primitives in the language as well as soundness bugs in the compiler, it just makes them much rarer. It's well worth designing the system so it doesn't fall apart as soon as one such bug appears.
Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea
#18See Tock OS https://www.tockos.org/ for another Rust-based embedded OS with a fairly comparable design to Hubris. The debugging capabilities of Humility make an interesting comparison to what's provided by cargo-embed https://probe.rs/docs/tools/cargo-embed/ and the Knurling Tools https://knurling.ferrous-systems.com/tools/ by Ferrous Systems. Ultimately, the embedded space (including all sorts of low-level, retro, "…
Under the hood, cargo-embed, knurling's probe-run, and Humility are all built atop probe-rs (https://probe.rs/) to provide debugging - I think in this case it's actually a great example of cooperation between projects! Probe-rs has received PRs from both Knurling and Oxide devs; it provides the common interface to use various types of debug hardware and talk to various types of microcontroller cores, essentially replacing OpenOCD.
Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea
#19No post body was provided.
Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea
#20The github repo of hubris [0] is very nice, as they immediately tell you where what is, e.g. drv/ contains drivers, a mix of simple driver lib crates and fully-fledged server bin crates. Current convention is that drv/SYSTEM-DEVICE is the driver for DEVICE on SYSTEM (where SYSTEM is usually an SoC name), whereas drv/SYSTEM-DEVICE-server is the server bin crate. Why does nobody do this in their readmes normally? They…
> Why does nobody do this in their readmes normally? They just let you look into their code and tell you "now figure it all out yourself".
I think it's worth praising this repo without knocking others. Open source authors have no obligation to their users; if they don't have the time to, or just don't care to, so organise their READMEs, then they need not. In fact, if it's sufficiently important, for much open-source software anyone else can do it, and submit a patch.