@gkelly I think this is related to your syscall filtering work.

You are correct to say that this PR is not secure under Tock's threat model.

Unfortunately, I think solving this limitation requires figuring out the app ID story. I don't think we can have a secure mechanism to enforce "only app X can do Y" unless we have a mechanism to verify that an app that claims it is X is actually X.

What we might need is a concept of resource ownership. Who "owns" a particular system call (i.e. determines who can call it)? Is it the kernel? I'm going to try to hash this out more on the core WG call and/or dev mailinglist.

An app ID will have the same problem. Eventually the app ID will be stored in the TBF header as well.

My thinking here is that the loader (which we trust) can check this. For example for Tockloader could take a config file like this:

app1: "My test app"
  file: app1.elf
  appid: 0x12345678
  permissions:
    i2c: read, write
    console: write

app2: "My second app"
  file: app2.elf
  appid: 0x23456789
  permissions:
     usb
     ctap
  persistent_storage:
    write_id: 0xdeadbeef
    read_ids: 0xdeadbeef, <old_id>

Then Tockloader can compare the config file permissions with the individual app permissions to make sure they match. Then it can generate and sign a binary ready to deploy.

I'm not clear how ownership would help. Would an app own a driver? What happens if that app is compromised?

I think it makes sense to have the kernel enforce access. The question is how to tell the kernel to do that. Hard coding a function in Rust in a board specific function is one option, but seems too inflexible. Also how would that function know which app can do what, unless we trust something in the TBF header?

Is this PR still reflective of the current state of the discussion?

I think it is

Is this PR still reflective of the current state of the discussion?

Based on the current state of discussion:

1. It is fine for an application to use this mechanism to sandbox itself, e.g. to limit the privileges an adversary would gain of the adversary compromises the app. This is equivalent to Unix daemons that drop privileges after startup.
2. We could make tockloader read this header and tell the user what permissions the app needs before the user decides whether or not to load the app. From the perspective of the threat model, we're making the user running tockloader the arbiter of app permissions, and enforcing those permissions through a combination of tockloader and the mechanism described in this PR.
3. We could add a permissions system to the kernel that contains a kernel-provided permissions list (keyed on application ID). The kernel would verify the list in this PR is consistent with the kernel-provided permissions for the app before loading an app. From the perspective of the threat model, the kernel-provided permissions list would be the arbiter of app permissions and this PR's mechanism would be part of the enforcement implementation.

So yes, it is consistent with the current state of the discussion. It is not a mechanism to isolate a possibly-malicious app on its own.

That was my understanding as well.

Is tock/elf2tab#28 up to date with the design here, or are you waiting for approvals on this PR before updating the elf2tab PR?

tock/elf2tab#28 is up to date.

Ping!

I looked through this PR and the corresponding elf2tab PR and think the design looks reasonable. I assume the idea is that this would be implemented by the already existing system call filtering mechanism -- perhaps the docs should mention that somewhere?

Ping!

This must be ready to merge

cc @phil-levis you need to dismiss your "request changes" for this to be mergeable

Updated and ready to go

Ready to go!

bors r+

Build succeeded:

• ci-build (macos-latest)
• ci-build (ubuntu-latest)
• ci-format (ubuntu-latest)
• ci-qemu
• ci-tests (macos-latest)
• ci-tests (ubuntu-latest)