Replace SDMExecutionContext with SDMConnectMode.

[flit]

This change replaces SDMAuthenticateParameters::expectedExecutionContext with SDMOpenParameters::connectMode. The execution context is most likely difficult or impossible for the debugger to know any better than the SDM plugin itself. But the debugger's connection mode, most importantly run vs attach, can be useful in several ways. For instance, knowing whether the plugin is allowed to reset the target.

The available connect modes are defined by SDMConnectModeEnum.

• SDM_ConnectLoad
• SDM_ConnectRestart
• SDM_ConnectAttach

These connect modes are mostly a quick attempt to start discussion and get feedback from debugger/tools developers.

The first two are variants of "run", where the application to be debugged either hasn't or has already been loaded into the target's memory. Whether this is actually a useful distinction isn't entirely clear to me. I was thinking this might reflect ROM versus application based SDA.

[henriksandin]

As I said in the meeting 2022-01-28, these three modes are a one-to-one mapping to how the Embedded Workbench debugger can be started so it makes perfect sense from a debugger-starting perspective. From an SDA location perspective, I don't have extensive knowledge on how embedded application developers organize their software. I'm not sure that there is a distinct logical connection between these three modes and where the SDA is located. It might also depend on the use case scenario, i.e. if the device is already released into the field (maintenance?) or if it is under development.

[flit]

You're right, of course. There's not necessarily a logical connection between the connect modes and execution context. Probably I shouldn't really have combined the two changes in this one PR. Regardless, the connect mode should be useful to the SDM, so it at least doesn't attempt to reset the target when the user wants attach mode.

[jamiebird-arm]

Some questions about the connection flow of the SDM_ConnectLoad and SDM_ConnectRestart modes.

SDM_ConnectRestart:

• Debugger calls SDM_Authenticate, which may or may not include a reset.
• Debugger performs reset.
  • Should this still be the case if SDM_Authenticate performed a reset?
  • Could this reset undo any authentication from SDM_Authenticate?

SDM_ConnectLoad:

• Debugger calls SDM_Authenticate, which may or may not include a reset.
• Debugger downloads application.
• Debugger performs reset to run application.
  • I suppose some deuggers could just set the PC.
  • Could this reset undo any authentication from SDM_Authenticate?

[henriksandin]

Approved by IAR. From my point of view, the debugger would have to make sure not to "break" the authentication during startup once it's established (whatever mechanism that would be, some type of hardware reset or other).

[flit]

@jamiebird-arm In regards to your questions, specifically whether the debugger resetting after authentication is performed will undo authentication, that depends on the SoC. For every existing secure debug implementation I know of (including our initial partner), a warm reset retains authentication whereas a cold/PoR reset restores permissions to the default state. The ADAC specification strongly recommends that the implementation behave this way, but ultimately it's IMPDEF.

Another sticky bit is that on some SoCs, different reset methods give you different warm vs cold resets. For example, for some TI MCUs (just a random example I happen to know off the top of my head) a pin reset via nRST will perform a cold reset.

It's quite possible we need a way to inform the debugger that in order to maintain authentication it should only allow/use a given set of reset types. This can probably be handled with a capability in the manifest, maybe something like this:

<capability>
  <!-- value is a bitmask where bit 0 is hw reset, bit 1 is sw reset -->
  <feature name="authentication-safe-resets" enable="true" value="0x2"/>
</capability>

(I'm not sure what point the enable attribute has here, but it's currently required in the schema.)

Created #21 to track defined capabilities.