Transient boot selection #2050
Transient boot selection #2050
Conversation
See bootleby:src/lib.rs for the receiving end of the override selection.
| @@ -93,6 +93,22 @@ write = true | |||
| execute = false | |||
| dma = true | |||
|
|
|||
| [[override]] | |||
| name = "a" | |||
| address = 0x3003ffe0 | |||
There was a problem hiding this comment.
Can we use the non-secure alias 0x2003ffe0 ? This better matches what we do for our other addresses
| // The sequence: [update, set transient preference, update] is legal. | ||
| // Clear any stale transient preference before update. | ||
| // Stage0 doesn't support transient override. | ||
| if component == RotComponent::Hubris { | ||
| set_hubris_transient_override(None); | ||
| } |
There was a problem hiding this comment.
I think I see what this is trying to do but I'm not sure this is the right place. This would make [set transient preference, update] quietly not work as expected. I'm also not sure about the example [update, set transient preference, update] being legal but not supported. Can we clarify what the semantics of transient boot preference are supposed to be? Having it be effective for exactly one boot and clearing it on task startup seems like the least confusing semantics.
There was a problem hiding this comment.
Okay I re-read the RFD and double checked the bootleby source, the transient command is supposed to be nuked on boot by bootleby. I'm still not quite sure what makes this a 'stale' choice.
There was a problem hiding this comment.
It's not actually stale until some flash has been altered. Given the sequence where SlotId::B is active:
- prep_image_update SlotId::A
- flash to hubris-a with version 1
- switch_default_hubris_image(SlotId::A, SwitchDuration::Once)
- prep_image_update SlotId::A
- // abandon or abort the update before flashing anything
- // reset the RoT
What image is preferred to boot?
This is a corner case since we normally expect update, set-preference, reset.
I'm thinking that in this case, since the RoT update server saw an intent to boot once into SlotId::A and then saw intent to update A again, that should cancel the boot once directive.
We could wait until the first block of an image is received or that block is written to cancel the boot once directive.
There was a problem hiding this comment.
I agree it's a corner case. Fixing it in this way is a pretty poor developer experience because there's no indication that the boot setting has changed which will frustrate everyone. The transient boot setting should not be cancelled without some indication. We also have the exact same issue with the persistent settings. I get the theory is to avoid booting into a potentially bad image because we're now relying on bootleby to correctly determine that the slot is unbootable but this feels like it causes more problems than it solves. I think this issue of boot settings would be better tracked as a separate issue.
Automated update should take advantage of transient boot selection. This is the last piece to make that feature available.
See RFD 374 for a description and bootleby source for the logic being driven.