mirror of
https://github.com/saymrwulf/xous-core.git
synced 2026-11-14 08:03:34 +00:00
e6bef77b5f
The motivation for this is to make the tester configuration exactly identical to that used in production. Right now a "cheater" step is used to set the board type to dabao and enable boot waiting because in the test environment there isn't a physical switch anyone can press to invoke that behavior. So, in order to get the test environment to work just like production, the behavior goes from insta-die if no valid image is found on the next stage, to "wait for new image". This is slightly less secure of a default, but only slightly so. Basically the previous scheme required someone to be physically present to press the "give me a new image" button, this one causes the system to automatically accept a new image. I suppose the main downside is this does allow the possibility of say, a fully remote, automated exploit to be delivered if an adversary can damage the loader image such that it doesn't pass signature check and then it will automatically go into a mode looking for a new image, at which point an arbitrary image could be potentially loaded (although because the image would need to be signed, and there is a trap that destroys secrets if a developer image is presented, it wouldn't instantly lead to secret disclosure, but it would be a denial of service). The flip side is that with the paranoid default, developers are "confused" by the silent failure of a brand new chip that has no code loaded in it (because it goes catatonic until the developer knows to press the load button). The loader image is protected from writes after boot, so in theory there isn't a direct path to "spoil" the loader image and trigger this path, so it's not like we're just hanging in the wind. It just means that there isn't a full human-presence requirement as a defense in depth against a potential denial of service if an adversary could find a way to spoil the loader image. If the DoS path is a concern, one option is to configure the system such that the developer key is revoked. This would disallow that from being recognized as a valid image, and would also prevent the DoS from happening, as it would require the adversary to present a valid, signed image which presumably they can't as long as the signing keys are kept safe. |
||
|---|---|---|
| .. | ||
| bao1x-api | ||
| bao1x-hal | ||
| blitstr2 | ||
| chat | ||
| cos_table | ||
| flatipc | ||
| flatipc-derive | ||
| keystore-api | ||
| mass-storage | ||
| perflib | ||
| precursor-hal | ||
| tls | ||
| userprefs | ||
| ux-api | ||
| xous-bio | ||
| xous-bio-bdma | ||
| xous-pio | ||
| xous-pl230 | ||