Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oxide on My Wrist: Hubris on PineTime was the best worst idea

artemis.sh

Post reply on HN
Print view View original

21–30 of 51 posts

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#21

Post by TickleSteve »

zozbot234 wrote: post #14
TickleSteve wrote: post #13

Earlier 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…

Rust helps, but isnt immune (e.g. stack overflows).

Also, when you're dealing with embedded code, you're very likely going to be using unsafe code (e.g. driver level). With no other protection, incorrectly programming a DMA transfer to trample over code-space is not unknown... and Rust cannot protect you from that.

(Having said that... an MPU window will also not necessarilly catch a bad DMA transfer either).

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#22

Post by nerdponx »

JadeNB wrote: post #20
protoman3000 wrote: post #10

The 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…

This isn't just about open source. Developers on internal projects should do this too, but don't.

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#23

Post by zozbot234 »

TickleSteve wrote: post #21
zozbot234 wrote: post #14

Earlier quoted context omitted.

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…

Rust helps, but isnt immune (e.g. stack overflows). Also, when you're dealing with embedded code, you're very likely going to be using unsafe code (e.g. driver level). With no other protection, incorrectly programming a DMA transfer to trample over code-space is not unknown... and Rust cannot protect you from that. (Having said that... an MPU window will also not necessarilly catch a bad DMA transfer either).

> Rust helps, but isnt immune (e.g. stack overflows).

This is a good point but isn't Hubris designed to use statically bounded amounts of memory anyway, like much embedded software? AIUI, this was a key reason for keeping their design focused on synchronized requests, avoiding the hard-to-predict buffering that's needed for supporting 'async' models.

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#24

Post by nickspacek »

f0e4c2f7 wrote: post #6

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?

It's not the most hackable, but there are some dedicated folks hacking at the Amazfit watches. I have the original Bip, which has a ridiculous battery life (30+ days easily) and GPS. The GPS will run your battery down with extensive use, but if I'm running a few times a week it'll still go 2 weeks.

It isn't that powerful, and I wish it had a second physical button. I haven't explored the mods very much because it does what I need it to do, but the scene has the feel of the early Xbox hacking scene, to me at least.

There's this watch which appears to be heavily inspired from the Amazfit Bip: https://www.kickstarter.com/projects/gfw/banglejs-2-the-open...

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#25

Post by bluGill »

nerdponx wrote: post #22
JadeNB wrote: post #20

Earlier quoted context omitted.

> 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…

This isn't just about open source. Developers on internal projects should do this too, but don't.

Have you ever tried to write useful documentation? As a programmer you are far to close to the code. You assume things are obvious that are not, while going into great detail describing things that are obvious (or maybe not obvious, but only rarely interesting and so should be documented in a deeper link not the main documentation). Or worse because you have to document it you document the code lines (++i; // increment i by one).

This is a hard problem. I try to make an effort, but too often I get it wrong.

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#26

Post by bcantrill »

zozbot234 wrote: post #4
panick21_ wrote: post #3

Earlier 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…

Other folks have mentioned this, but it's important to understand the limitations of Rust with respect to safety. In particular: every stack operation is -- at some level -- an unsafe operation as it operates without a bounds check. This isn't Rust's fault per se; non-segmented architectures don't have an architecturally defined way to know the stack base. As a result, even an entirely safe Rust program can make an illegal access to memory that results in fatal program failure. That, of course, assumes memory protection; if you don't have memory protection (or, like many embedded operating systems, you don't make use of it), stack overflows will plow into adjacent memory.

But wait, it gets worse: stack overflows are often not due to infinite stack consumption (e.g., recursion) but rather simply going deep on an unusual code path. If stack consumption just goes slightly beyond the base of the stack and there is no memory protection, this is corrupt-and-run -- and you are left debugging a problem that looks every bit like a gnarly data race in an unsafe programming language. And this problem becomes especially acute when memory is scarce: you really don't want a tiny embedded system to be dedicating a bunch of its memory to stack space that will never ("never") be used, so you make the stacks as tight as possible -- making stack overflows in fact much more likely.

Indeed, even with the MPU, these problems were acute in the development of Hubris: we originally put the stack at the top of a task's data space, and its data at the bottom -- and we found that tasks that only slightly exceeded their stack (rather than running all of the way through its data and into the protection boundary) were corrupting themselves with difficult-to-debug failures. We flipped the order to assure that every stack overflow hit the protection boundary[0], which required us to be much more intentional about the stack versus data split -- but had the added benefit of allowing us to add debugging support for it.[1]

Stack overflows are still pesky (and still a leading cause of task death!), but without the MPU, each one of these stack overflows would be data corruption -- answering for us viscerally what we "need the MPU for."

[0] https://github.com/oxidecomputer/hubris/commit/d75e832931f67...

[1] https://github.com/oxidecomputer/humility#humility-stackmarg...

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#27

Post by steveklabnik »

protoman3000 wrote: post #10

The 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…

In Rust, it's because most projects follow the default layout, and so is less needed.

We have a custom build system on top of Cargo, and so things are a bit weird for a normal Rust project, and so it's extra important.

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#28

Post by zozbot234 »

bcantrill wrote: post #26
zozbot234 wrote: post #4

Earlier 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…

Other folks have mentioned this, but it's important to understand the limitations of Rust with respect to safety. In particular: every stack operation is -- at some level -- an unsafe operation as it operates without a bounds check. This isn't Rust's fault per se; non-segmented architectures don't have an architecturally defined way to know the stack base. As a result, even an entirely safe Rust program can make an i…

> This isn't Rust's fault per se; non-segmented architectures don't have an architecturally defined way to know the stack base.

Bounding stack usage is of course a whole-program concern, but that ought to be feasible when building for embedded, where external "plugin" components are unlikely and there's no inherent need for true separate compilation. (Arguably, in such cases even the need for an actual "stack" structure is actually quite limited; a smarter compiler might well replace many uses of the activation stack with references to static data, reserving it for cases where e.g. reentrancy is actively needed. AIUI, there has been some work along those lines for LLVM.)

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#29

Post by steveklabnik »

zozbot234 wrote: post #23
TickleSteve wrote: post #21

Earlier quoted context omitted.

Rust helps, but isnt immune (e.g. stack overflows). Also, when you're dealing with embedded code, you're very likely going to be using unsafe code (e.g. driver level). With no other protection, incorrectly programming a DMA transfer to trample over code-space is not unknown... and Rust cannot protect you from that. (Having said that... an MPU window will also not necessarilly catch a bad DMA transfer either).

> Rust helps, but isnt immune (e.g. stack overflows). This is a good point but isn't Hubris designed to use statically bounded amounts of memory anyway, like much embedded software? AIUI, this was a key reason for keeping their design focused on synchronized requests, avoiding the hard-to-predict buffering that's needed for supporting 'async' models.

Defense in depth matters. The blog post shows an example of Hubris correctly killing a task that's touching memory it's not supposed to. That "supposed to" was due to a configuration error, but configuration errors can and do happen, and maybe would not be as benign as this one was.
Post reply on HN