Integrate the shutdown sequence into the LMCO P1 traps

[rtadros125]

The LMCO trap handler needs to be updated with some FETT_APPS specific work so we can either:

1. End all apps, close all sockets, and end it with endOfFett. And thus report back to portal.
2. Go back to normal operation.

A decision needs to be made by the project leadership and LMCO. After that, this ticket is to implement the decision.

[rtadros125]

@kiniry @austinhroach @podhrmic @LM-BrianUhlhorn @jseiche

[austinhroach]

I'm not familiar with the semantics of endFett, but I'm assuming that this tears down the instance, requiring the researcher to relaunch it from the FETT portal.

If there's the ability from within FireSim to issue a system reset, equivalent to a system reset issued by a watchdog in a real embedded system, that to me would be the best approach.

If there is not such functionality, or if the state of peripherals would be questionable after such a reset, tearing down the instance seems like the next best approach.

I would not just return from the exception handler.

[rtadros125]

In the current plant, we don't poll the OS. So we won't be able to either issues a system reset, or report back to portal.

So based on your comment, the interrupt will trigger the ending sequence, at which we will close all sockets and end both HTTP and OTA and that's it. At this point, we expect the researcher to ask the portal for a new instance instead of the dead one.

My question would be: Would this be considered as a DoS win?

[austinhroach]

DoS is out of bands in general for FETT, since development by TA-1 has been focused on detection rather than graceful recovery from exploit attempts. So what you describe seems to me to be the right thing to do.

[rtadros125]

Awesome; makes sense. I will leave this ticket open until we integrate the shutdown call in the handler.

[podhrmic]

@austinhroach is there a way to distinguish between a regular illegal instruction trap, and the LMCO specific illegal instruction? I am not sure we actually need to distinguish between those two for the purpose of FETT, but wanted to bring it up to make sure we are on the same page.

@rtadros-Galois what do you think about making the trap handler such that it always shuts down gracefully (i.e. not only after an illegal instruction), and we save in the logs mcasue, mepc, mstatus register values? And then update the README accordingly, so the researchers know about this behavior.

[rtadros125]

@podhrmic Yeah sure. If the registers values will be printed on the UART, then they will automatically be included in the logs. This makes sense. We have a function for peaceful exit that will trigger the closure of all the sockets and the deletion of all tasks; it just needs to be called and a nod to the linker that it exists.

[austinhroach]

@podhrmic I'm not aware of a way to distinguish between the two.

[rtadros125]

@rod-chapman Just double checking you acknowledged this assignment.

[rod-chapman]

I see I am assigned. Is there anything to be done before LM deliver a new P1 to us?

[podhrmic]

@rod-chapman this exception handler needs to be modified to cleanly shut down the application as Ramy described above. Or you can redefine the handler somewhere else, if that makes things easier (either extern or weak would work). See https://github.com/DARPA-SSITH-Demonstrators/FreeRTOS-10.0.1/blob/develop/FreeRTOS/Demo/RISC-V_Galois_P1/bsp/bsp.h#L67

I don't think anything else is needed.

[rtadros125]

As Michal said, we just need to make the handler call our setStopRequested function before going into its infinite loop.

[rod-chapman]

OK.. I looking at this now.

[rod-chapman]

Opened PR#33 in the FreeRTOS Repo for this. Submodule update will be needed here when this is merged.

[rod-chapman]

Closed by PR#461