-
Notifications
You must be signed in to change notification settings - Fork 963
TinyGo and Security
These are a few ways that we could evaluate TinyGo from a secure computing perspective.
-
Trusted execution environment (TEE) - https://en.wikipedia.org/wiki/Trusted_execution_environment
-
Hardware security module (HSM) - https://en.wikipedia.org/wiki/Hardware_security_module
-
Host firmware in conventional rack-mounted servers (x86-64, ARM) - https://en.wikipedia.org/wiki/Open-source_firmware
-
Baseboard management controller (BMC) firmware - https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface#Baseboard_management_controller
-
Mixed-criticality systems - https://en.wikipedia.org/wiki/Mixed_criticality
-
Sandboxed WASM execution - https://webassembly.org/docs/security/
-
Where does TinyGo use unsafe? Could we reduce use of unsafe?
-
What is the state of the TinyGo runtime? How likely is it that the memory allocator, GC, handling of stacks, or scheduler contains bugs that have a security impact?
-
What is the state of the TinyGo compiler toolchain? Especially glue between the official Go compiler frontend, and the LLVM backend. A useful exercise would be to go through golang-announce and think about which ones of those vulnerabilities affected the toolchain and whether TinyGo could be affected.
-
What is the state of TinyGo supply chain security? How wide and deep is the dependency tree? Consider embedding dependency manifests like "go version -m".
-
Possible guidelines for ensuring a secure development life-cycle
-
Signed software releases, key generation, and key access/handling.
-
Bug bounty program
-
What does TinyGo do about side channels? Does it have a Spectre mode like big Go?