Ecosystem for MCU

IGL: Embedded C++ Subset + WASM‑runtime for Controlled Execution on MCUs

Two components: IGL‑Converter (frontend for C and C++‑like subset: AST/NAST, security profile, IR/MMIO) and IGL‑RV‑emb (Draft/Alpha runtime for running WebAssembly modules in a sandbox on ARM Cortex‑M and RISC‑V). Focus - predictable memory, execution constraints, and traceable peripheral access.

🛡️

Status: v0.1 Draft/Alpha. Language feature support and protection level depend on profile, backend, and target platform.

IGL Ecosystem

An ecosystem for working with embedded code in a strict profile: parsing and semantics of C/C++‑like subset, static checks and lowering to IR with explicit MMIO operations, as well as target runtime (including WASM). Status: v0.1 Draft/Alpha.

Key components:

IGL‑Converter - frontend/converter for embedded code (C and C++‑like subset), which builds AST/NAST, performs semantic checks and applies security profile rules, then lowers the program to intermediate representation (IR) and target formats. Goal - predictable behavior, strong diagnostics, and controlled MMIO access within defined policies.

Approach (v0.1):

1. Single pipeline: preprocess → parse/AST → semantic → NAST → security profile → IR/MMIO → targets/runtime.

2. Profiled security: prohibitions and checks (e.g., no exceptions and no dynamic memory; optional runtime checks).

3. Multi-targeting: generation of C and WebAssembly is possible for the supported subset and selected backend.

  • IGL‑Converter: preprocess → AST → semantic → NAST → security profile → IR/MMIO → target generators (e.g., WASM/runtime, C)

Preprocessor

  • Macros;
  • Conditional compilation;
  • Diagnostics and predictable processing (some "macro tricks" may be limited in v0.1).

Parser

  • Lexical analysis;
  • AST construction;
  • Scopes and name resolution (within subset).

Semantics and Analysis

  • Type checks and construct correctness verification;
  • Reachability/initialization analysis (as per v0.1 capabilities);
  • Security profile rules and diagnostic messages.

IR Translator

  • Intermediate Representation (IR);
  • Metadata preservation;
  • Security annotations and MMIO labels (where applicable).

Optimizer

  • Dead code elimination;
  • Expression optimization;
  • Transformations compatible with profile and semantics preservation.

Generators

  • C code (with corresponding backend);
  • WebAssembly (target format);
  • Other formats - as implemented.
  • IGL-RV-emb: Secure execution environment (no-std runtime) for running safe embedded modules on ARM Cortex‑M and RISC‑V. Modules arrive as WASM‑subset and are lowered on the host to compact bytecode IGL‑BC2, which runs on MCU in a sandbox‑VM. IGL‑RV‑emb is a "digital bodyguard" for control logic, where all effects are strictly controlled through allowed hostcalls.

    • Execution policies:

    1. Execution limitation by steps (GasV1 / fuel), memory/stack/locals limits, traps on violations.

    2. Control of allowed effects: allowlist hostcalls and MMIO sandbox (deny‑by‑default).

    Module trust verification:

    1. IGL‑PKG container: CRC32 integrity.

    2. P‑256 ECDSA digital signature (in strict mode - mandatory, signature protects header.flags and package content).

    3. (Optional) Module binding to device (HW‑lock, e.g., STM32 UID).

    Features:

    1. no‑std / no OS, static memory (no heap) - designed for MCU.

    2. Flash/RAM requirements depend on BC2‑opcode set and enabled security options (fixed during pilot on target board).

    3. Doesn't require hardware replacement - works on existing MCUs.

Main components of IGL-RV-emb:

  • Host packer: WASM‑subset validation and lowering to IGL‑BC2 bytecode;
  • IGL‑PKG container: policy/mmio/gas/signature/hwlock sections + CRC;
  • No‑std VM (BC2 runtime) on MCU: sandbox execution without arbitrary native code;
  • HAL/Hostcalls: controlled access to MMIO/IRQ/timers via allowlist;
  • Static memory, no heap (by design).

Security functions of IGL-RV-emb:

  • Policy‑enforcement: stack/locals/memory limits, traps on violations;
  • Gas/fuel metering (GasV1) for predictable execution time;
  • Allowlist hostcalls + MMIO sandbox deny‑by‑default;
  • Integrity check (CRC32) and authenticity (P‑256 ECDSA signature);
  • HW‑lock: package binding to device (e.g., STM32 UID);
  • (Optional) Anti‑debug checks by flag (platform-dependent).

Benefits of using IGL Eco:

Controlled execution and managed attack surface

  • Security profile for embedded code: prohibition of dangerous features (e.g., exceptions, dynamic memory, recursion) and predictable execution model.
  • Traceable peripheral access: MMIO operations can be explicit and policy-limited (allowlist/sandbox), easing audit.
  • Runtime control: time/cycle limits (fuel) and execution integrity checks - depending on configuration and platform.

Faster adoption of security practices in development

  • Some checks automated in build: profile rules + optional checks (bounds/div‑by‑zero/initialization) - per settings.
  • Strong diagnostics: errors localized closer to occurrence, less time debugging regressions.
  • Suitable for gradual adoption: start with critical modules and expand coverage.

Trust and compliance preparation

  • Verifiable properties: resource constraints, profile rules, MMIO control, reproducible build results.
  • Simplifies internal audit and preparation for security and certification requirements (outcome depends on standard and assessment process).
  • Useful for industrial/enterprise/IoT where device controllability and predictable behavior are important.

Integration without "replacing everything"

  • Target MCUs: ARM Cortex‑M and RISC‑V (coverage and requirements depend on specific chip and configuration).
  • Converter handles analysis/lowering and annotations, runtime - sandbox and execution policies.
  • Integrates as a step in CI/CD and doesn't require changing familiar workflow if project fits supported subset.

How does it work?

IGL-Converter

Frontend and verification pipeline for embedded code

  • Parses C and C++‑like subset, builds AST/NAST and performs semantic checks.
  • Applies security profile and forms IR with annotations (including MMIO labels where applicable).
  • Generates target artifacts (e.g., WASM/runtime or C) - depending on backend and profile.

IGL-RV-emb

Draft/Alpha WASM‑runtime for microcontrollers

  • Runs WASM modules in sandbox on MCU (ARM Cortex‑M, RISC‑V) with execution policies and resource limits.
  • Supports fuel limits, stack/memory control and allowlist capabilities (per configuration).
  • Memory requirements and WASM instruction coverage depend on runtime version and target platform.

IGL Ecosystem

Integration into workflow

  • Embeds into build and CI/CD: profiles, checks and artifact generation performed reproducibly.
  • Supports gradual adoption: from pilot to coverage of critical components.
  • Doesn't promise "impossibility of hacking", but helps build controlled execution within chosen threat model.
Recommended

Note: IGL v0.1 - Draft/Alpha. Security profiles and sandbox reduce risks, but final security depends on configuration, target MCU, supply chain and adopted threat model.

Why choose IGL‑ECO

Reduced costs

for implementing and maintaining security practices (project-dependent)

Integration time

into build/CI/CD as pipeline step (estimate depends on coverage and profile)

Runtime memory

requirements depend on WASM features configuration, sandbox and target MCU

Performance overhead

depends on enabled checks and limits

Note: values depend on threat model, profile configuration, backend and target platform. For pilot, measurable metrics are usually fixed on your code.

What you get as output

IGL is a "glass‑box" pipeline: besides target artifact you get reproducible reports and intermediate stages, to understand what happened and why.

Profile report

  • report.md - PASS/FAIL and brief reasons
  • security.json - which rules applied, what prohibited/allowed
  • Local references to code locations and profile rule

MMIO trace

  • mmio.json - which regions/registers affected (allowlist)
  • Peripheral access labels at IR level (where applicable)
  • Fail on access outside policy (if enabled)

Intermediate stages

  • ast.txt, nast.txt - tree and normalized form
  • ir.txt - intermediate representation
  • "Explain mode" for key compilation decisions (per settings)

Target artifacts

  • module.wasm - artifact for runtime
  • output.c / other formats - with corresponding backend
  • repro.zip - reproducible package for bug/audit (optional)

Note: IGL v0.1 - Draft/Alpha. File set and stage coverage depend on selected profile and backend.

Typical use cases

Not "security magic", but engineering scenarios where predictability, constraints and observability matter.

Updatable logic on MCU

  • Deliver functionality as module (e.g., WASM) instead of full firmware update.
  • Runtime applies execution policies: sandbox, fuel, allowlist capabilities.
  • Optional: module signature/authenticity verification (if enabled in integration).

Peripheral access control

  • Declare which MMIO regions module can access.
  • Get report and MMIO trace; access attempts outside policy may cause fail.
  • Simplifies audit of "who touches hardware" and reduces hidden dependencies.

Embedded C++ subset under strict profile

  • Stable parsing and diagnostics of embedded patterns (HAL, drivers, protocols) within subset.
  • Profile prohibitions and constraints: no exceptions/heap/recursion, bounded loops or fuel policy.
  • Reproducible reports for code review and change risk control.

Debugging "strange bugs" and regressions

  • Intermediate stages AST → NAST → IR help quickly locate problem source.
  • Explain logs show pipeline decisions ("why typed this way", "why profile prohibited").
  • Repro‑bundle simplifies problem transfer between teams.

Explain mode

"Why so" mode: for key pipeline decisions IGL can provide explanations and decision points, not just final result.

Decision points

  • Why construct recognized as declaration/expression
  • Why type/cast chosen (within type model)
  • Why profile rule triggered (and where)

Stage diff

  • What changed after normalization (NAST)
  • What changed after lowering to IR/MMIO
  • Which optimizations applied and why they are safe

Repro bundle

  • Single package: input + profile + intermediate stages + reports
  • Convenient for support, audit and regression tests
  • Helps quickly reproduce and fix errors
Our feature

Threat model and boundaries

We sell controllability and reproducible checks. Final security depends on configuration, platform and development process.

IGL helps:

  • Restrict dangerous language features through profile;
  • Reduce risk of runtime error classes (depending on enabled checks and execution policy);
  • Make MMIO access observable and manageable;
  • Get "evidence" for internal audits and certification preparation.

IGL does NOT replace:

  • Hardware measures (secure boot, key protection, debug lock, fault‑injection resilience);
  • Secure development lifecycle process and testing;
  • Formal certification (this is a separate process).

Status: v0.1 Draft/Alpha. Supported constructs and WASM features are evolving; backend limitations may affect applicability.

Where IGL Eco is applicable

Where controlled execution on MCU, resource constraints and auditable peripheral/MMIO access matter. Below - typical application domains (example scenarios depend on project and threat model).

Industrial automation and IIoT

  • Controlled execution of modules on PLCs/controllers and sensors.
  • Restriction of "dangerous" code capabilities through profile.
  • Peripheral access policies (MMIO allowlist) and audit of critical operations.

Energy and Smart Grid

  • Smart meters, relays, remote stations: resource limits and execution control.
  • Reduced risk of unauthorized firmware behavior through profile and sandbox.
  • Execution observability and predictable update policies (depending on integration).

Transport and infrastructure

  • Controllers, sensors, communication nodes: module isolation and execution limits.
  • Simplified internal audit and incident analysis through reproducible build checks.
  • Control of access to critical device interfaces.

Telecom and network devices

  • Routers/gateways/base stations: secure modules with execution policies.
  • Reduced risk of runtime errors (depending on enabled checks).
  • Separation of trusted part and executable modules.

Medical and instrumentation

  • Instruments and peripherals: strict execution limits and predictable behavior.
  • Support for secure development practices (profiles, checks, auditable artifacts).
  • Applicability depends on regulator requirements and certification process.

Edge computing and ML devices

  • Running isolated modules (including alongside ML inference) with time/memory limits.
  • Control of module interactions with hardware via HAL/host‑ABI policies.
  • Convenient for "plugin" scenarios and updatable logic.

Aerospace/Defense

  • Controlled execution and resource limits on board.
  • Traceable interactions with peripherals and strict profiles.
  • Suitable for tasks where audit and predictability matter (specific measures depend on environment and requirements).

Security and access control

  • Access controllers, cameras, sensors: module isolation and execution policies.
  • Reduced risk of abnormal firmware behavior during updates.
  • Ability to embed module authenticity checks (if enabled in integration).

Important: IGL is not universal protection. Effect depends on threat model, profile configuration and platform.

Want to test IGL on your code?

We'll run a pilot: process one module through IGL‑Converter, show diagnostics, profile constraints and lowering artifacts (IR/WASM).

If needed - we'll help calculate ROI based on your inputs (code volume, requirements, platform, check level).