|
|
|
|
|
|
by bcantrill
752 days ago
|
|
|
That is not correct. Hubris -- very importantly -- uses the MPU to isolate applications from one another and from the kernel: if any application accesses memory that it is not permitted to access (either in I/O space that has not been assigned to the application or in another application), it will fault and (by default) be restarted. Moreover, we make sure that the stack for a given application grows towards a protection boundary (rather than towards its own data), assuring that a stack overflow (our most common fault, by far!) does not result in an application corrupting its own data but rather in that application dying. It is definitely true that Hubris does not have (and never will have) a dynamic loading facility: dynamic loading is very important to Tock, but we saw that it was taking us not just away from our use case but directly contrary to it. In contrast, Hubris has exclusively static task assignment -- which has proved to be a very important constraint for overall system robustness as it allows things task restart to happen without fear of unavailability of resources. Cliff Biffle expands on more details of Hubris in his OSFC 2021 talk[0]. I also don't think it's accurate to speak of an "exact use case" for Hubris, as we ourselves use it in disparate applications: among other things, it runs our root-of-trust, our service processor, our power shelf controller, and on our manufacturing line to program parts. What these use cases have in common is that they are embedded microcontrollers in which robustness is essential. This is not to say that Hubris is a fit for all embedded use cases, of course -- but the fit is certainly more broad than how we happen to be using it. In terms of other contrasts to other embedded systems, we have spent quite a bit of time on debugging infrastructure, with our debugger being co-designed with the operating system; more details on this in Matt Keeter's OSFC 2023 talk.[1] [0] https://talks.osfc.io/osfc2021/talk/JTWYEH/ [1] https://talks.osfc.io/open-source-firmware-conference-2023/t... |
|
|