ARMmbed / ARMmbed/uvisor

Move uVisor debug functionality to debug box

Open
#70 4 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
C
Stars
135
Forks
72
PR merge metrics
No merged PRs in 30d

Description

- uVisor is supposed to have as little as possible special knowledge about the target and it peripherals
- uVisor must still support complex debugging like over meshed wireless networks, IPv6 Ethernet with SSL or USB CDC serial.

Solution:
- Debug communication and debug LED handling will be moved into a uVisor box: a "debug driver" that doesn't even need to be uVisor aware. Such a debug driver will map debug requirements like ("blink LED 3 times repeating" or "print log-text over whatever interface you support") to the underlying hardware. The OS above uses that driver in a hardware-independent way.
- uVisor or OS create a machine readable stack trace of crash in network endianness format, the debug box can choose to forward it to turn it into a local "bluescreen" (USB serial etc.)
- The debug box can choose to maintain the hardware-dependent memory map with human readable peripheral names to enrich a "blue screen" output- whenever the remote system wants to communicate to uVisor, the debug box will call into uVisor to deliver just the payload.
- whenever uVisor will print messages, it will issue a de-privileged call to the dedicated box that handles the output.
- as a result uVisor does not need to know about complex protocols, but is still able to interact with remote systems in a debug session.
- the debug box might be able to debug other boxes if these boxes allow to do so (similar to Android where an app needs to explicitly allow debugging in its manifest)
- we stop uVisors attack surface from growing by reducing privileged code
- uVisors security properties are very comparable across a multitude of system: security verifications become transferable across systems
- consider using CBOR format for a verbose debug dump, as the format requires not just standard outputs like stack traces etc, but various status register and context/security related info that might be platform dependent

See also https://github.com/ARMmbed/uvisor/pull/64

Contributor guide

Open the contributing guide

Research direction

Start by reading the requirements in this issue and the related pull request #64. Trace how uVisor currently handles debug communication, LED handling, messages, and crash information, then define the debug-box boundary and interfaces. Done means the design supports hardware-independent debug output while reducing uVisor's privileged, target-specific knowledge.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
embedded-iot, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.