Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update libtock_unittest to disallow non-swapping Allow behavior. #349

Open
jrvanwhy opened this issue Dec 12, 2021 · 0 comments
Open

Update libtock_unittest to disallow non-swapping Allow behavior. #349

jrvanwhy opened this issue Dec 12, 2021 · 0 comments
Assignees

Comments

@jrvanwhy
Copy link
Collaborator

jrvanwhy commented Dec 12, 2021

When Tock 2.0 was released, capsules had the ability to refuse to return Allow buffers as well as the ability to return buffers other than the most recently provided buffer. This was reflected in TRD 104, as well as the design of the fake::Driver trait:

fn allow_readonly(&self, buffer_num: u32, buffer: RoAllowBuffer)
    -> Result<RoAllowBuffer, (RoAllowBuffer, ErrorCode)>;

fn allow_readwrite(&self, buffer_num: u32, buffer: RwAllowBuffer)
    -> Result<RwAllowBuffer, (RwAllowBuffer, ErrorCode)>;

However, that is changing in upstream Tock: tock/tock#2906. Now, libtock_platform can rely on the Allow system call to always return the last successfully-Allowed buffer. The Allow APIs I am designing for libtock-rs (e.g. #348) rely on this.

As a result, libtock_platform and libtock_unittest are currently unsound when combined: libtock_unittest allows a safe fake::Driver implementation to handle buffers in a way that libtock_platform assumes is impossible. To resolve this, we need to update libtock_unittest to match the new behavior of the Tock kernel (and the new TRD 104 wording).

@jrvanwhy jrvanwhy self-assigned this Dec 12, 2021
@jrvanwhy jrvanwhy changed the title Allow unsoundness due to TRD change (capsule behavior limits) Update libtock_unittest to disallow non-swapping Allow behavior. Dec 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant