Skip to content

Remove SYS_futex, SYS_write, SYS_close, and SYS_mmap from list of default allowed syscalls for seccomp on Linux #183

Closed
Enhancement
Closed
Remove SYS_futex, SYS_write, SYS_close, and SYS_mmap from list of default allowed syscalls for seccomp on Linux#183
Enhancement
Labels
area/securityInvolves security-related changes or fixeslifecycle/confirmedBug is verified or proposal seems reasonable
Milestone
Upcoming

Description

@danbugs
danbugs
opened on Jan 29, 2025

Currently, we allow SYS_futex, SYS_write, SYS_close, and SYS_mmap (

hyperlight/src/hyperlight_host/src/seccomp/guest.rs

Line 56 in b9c67fb

(libc::SYS_futex, vec![]),
) by default beause they are needed by some writer functions we have. Writer functions are not registered like normal host functions. Instead, they are passed in as a parameter to UninitializedSandbox::new (

hyperlight/src/hyperlight_host/src/sandbox/uninitialized.rs

Line 125 in b9c67fb

host_print_writer: Option<&dyn HostFunction1<String, i32>>,
) and, so, allowing extra syscalls to it is a bit cumbersome. We should consider refactoring UninitializedSandbox::new to leverage a builder pattern.

Activity

  1. danbugs
    added
    lifecycle/confirmedBug is verified or proposal seems reasonable
    area/securityInvolves security-related changes or fixes
    on Jan 29, 2025
  2. github-actions
    added
    lifecycle/needs-reviewThe issue has not yet been reviewed.
    on Jan 29, 2025
  3. syntactically
    removed
    lifecycle/needs-reviewThe issue has not yet been reviewed.
    on Jan 29, 2025
  4. danbugs
    added this to Hyperlight Milestoneson Mar 4, 2025
  5. danbugs
    added this to the Backlog milestone on Mar 4, 2025
  6. danbugs
    modified the milestones: Backlog, Upcoming on Mar 12, 2025

  7. jprendes commented on Jul 2, 2025

    @jprendes
    jprendes
    on Jul 2, 2025
    Contributor

    I think we can go ahead with removing the syscalls from the default.
    Now the print writer is registered like any other function.
    It does have a dedicated registration function to simplify some things (signature checking, using the correct name, and adding the extra syscalls we add for printing), but that one also comes with the extra syscalls flavor.

  8. syntactically commented on Jul 2, 2025

    @syntactically
    syntactically
    on Jul 2, 2025
    Member

    Is removing mmap() entirely from the hypervisor thread safe? I would imagine there are some scenarios where the allocator will mmap(MAP_ANONYMOUS) to get a chunk of heap memory. I would also think we should be quite careful about removing futexes, as those are used all over the place.

  9. dblnz
    marked this as blocked on Oct 23, 2025

  10. dblnz commented on Oct 23, 2025

    @dblnz
    dblnz
    on Oct 23, 2025
    Contributor

    @danbugs I think this no longer applies since we have merged #970 , is that right?

  11. danbugs commented on Nov 4, 2025

    @danbugs
    danbugs
    on Nov 4, 2025
    ContributorAuthor

    @dblnz ~ you're right! Closing this.

  12. danbugs
    closed this as completedon Nov 4, 2025
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/securityInvolves security-related changes or fixeslifecycle/confirmedBug is verified or proposal seems reasonable

    Type

    Enhancement

    Projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions