Skip to content

Add architecture-independent exception handling APIs sufficient for hyperlight-wasm #1690

Description

@syntactically

Currently, hyperlight-guest exposes an architecture-specific way of overriding certain raw exception handler on x86-64 that is used by hyperlight-wasm. Really, we should instead have architecture-independent hooks for

  • Intercepting certain kinds of misbehaviour-indicating exceptions (e.g. FP divide by zero, access to guard regions)
  • Support for the virtual memory primitives that hyperlight-wasm needs in hyperlight-guest (e.g. zero-on-first-read regions, copy-on-write images, guard regions)

Activity

  1. syntactically commented on Aug 26, 2026

    @syntactically
    MemberAuthor

    These should likely be split up a little bit:

    • For virtual memory:
      • For CoW images, hl-wasm already uses vmem::MappingKind::Cow and does not need any extra help
      • We should add vmem::MappingKind::LazyZeroInitialised (or something of the sort), which would also be useful for the heap, potentially replacing the existing stack growth, etc, which populates invalid PTEs with flags on them that let the normal fault handler know to replace them with zero initialised pages
      • We also need some way to trap on violations of the permissions on pages, which are currently not being used. That should likely actually be handled like the next category, instead of like other virtual memory regions
    • For other exceptions:
      • Currently (already) the hl-wasm support is a little lacking: it only handles #UD on x86-64 which is used because that is the explicit trap instruction that wasmtime uses. We should instead have e.g. hyperlight_guest::exception::handle_undefined_instr, hyperlight_guest::exception::handle_permission_fault, etc., and the rewriting of registers to actually move into that handler (which should for the moment abort or longjmp) should move into the exception handler in hyperlight_guest.
  2. added this to the v0.18.0 milestone on Sep 3, 2026
  3. modified the milestones: v0.18.0, v0.19.0 on Oct 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/APIRelated to the API or public interfacelifecycle/confirmedBug is verified or proposal seems reasonable

    Projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions