Open andrew-bivin opened 4 years ago
Everything stays provisioned, modifications here are above AWS. (ie; no reflash, etC)
TBD if a UI is needed for this.
Moving back to backlog, based on @rtadros-Galois input.
Could you please summarise the input that led to this decision for those of us not at Galois/Five Talent/etc?
@jrtc27 Given FETT-Target #673 and #674, and given that this is low priority in point of view of DARPA who is prioritizing other tasks, we do not have enough cycles to focus on debugging these (basically #673). The interns will be poking at them; we'll include the feature if the bugs are totally solved instead of having a broken feature.
We view fast recovery from crashes as a key feature to allow FETT researchers to operate efficiently with the forthcoming CHERI-RISC-V Release 2, in which kernel debugging will play an essential role. Could you let us know what current reset vs re-provision times are for CHERI-RISC-V nodes?
@jrtc27 @rwatson I think we might be speaking about two different things, or maybe we're not. Let me elaborate:
Regarding the "rebootable Unix" phrasing:
su
, then reboot
and it will work fine. Or, if they cause a kernel panic or lose network, they can use the UART piping to reboot
as well. This ticket is not related to that.The portal "reset" button:
terminate
or reset target
. This would reload the FPGAs and boot the OS again, but using the same filesystem and without any tests.Answering Robert's specific questions:
- Both of Cheri variants (default and purecap) are completely rebootable from the researcher end. So they can
su
, thenreboot
and it will work fine. Or, if they cause a kernel panic or lose network, they can use the UART piping toreboot
as well. This ticket is not related to that.
Ok, so C-a r will be documented as the supported way to reboot CHERI instances? Button in the UI would of course be nicer, but that approach is sufficient (and they probably will have the UART logs up anyway to see what happened).
Ok, so C-a r will be documented as the supported way to reboot CHERI instances? Button in the UI would of course be nicer, but that approach is sufficient (and they probably will have the UART logs up anyway to see what happened).
@mattlebeau-galois Can you please add the use of Ctrl+A
+ r
to reboot Cheri to portal learn? I'd say in the same sentence as reboot
is mentioned.
Hi @rtadros-Galois: Yes, I think I misunderstood the title of this issue. As long as the portal reset button works, resetting the state of the FPGA and OS kernel, but leaving the same filesystem in place, I think we are OK.
Ok, so C-a r will be documented as the supported way to reboot CHERI instances? Button in the UI would of course be nicer, but that approach is sufficient (and they probably will have the UART logs up anyway to see what happened).
@mattlebeau-galois Can you please add the use of
Ctrl+A
+r
to reboot Cheri to portal learn? I'd say in the same sentence asreboot
is mentioned.
@rtadros-Galois - Added a story for this over in #445 - May I ask for your review/edits of the AC on that ticket to verify that I've correctly transposed the instructions, please?
Once the FETT-Target team has tested rebootable Unix system functionality (described in this closed issue: https://github.com/DARPA-SSITH-Demonstrators/SSITH-FETT-Target/issues/526), we need to implement back- and front-end functionality in FETT Portal for researchers to soft-reboot an instance (rather than re-provision an instance from scratch).