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

Added memory documentation #992

Merged
merged 6 commits into from Jun 19, 2018

Conversation

Projects
None yet
4 participants
@dverhaert
Copy link
Contributor

dverhaert commented Jun 13, 2018

Pull Request Overview

Since I'm working on the MPU, I'm constantly thinking about what high-level isolation properties we want to enforce with Tock. After discussing this with several people, the idea came up to write a small document and create a pull request, which is exactly what I just did.

I've changed the existing memory layout doc, and adjusted it to include some aspects regarding isolation.

TODO or Help Wanted

I'd like some feedback on this document. Are these all the security properties we want to enforce in memory in Tock, or am I missing something? Should I go more in-depth or does this have sufficient depth and clarity? Feel free to adjust.

Documentation Updated

  • Kernel: Updated the relevant files in /docs, or no updates are required.

Formatting

  • Ran make formatall.

dverhaert added some commits Jun 13, 2018

Merge pull request #5 from tock/master
Bringing fork up to date
@bradjc

This comment has been minimized.

Copy link
Contributor

bradjc commented Jun 13, 2018

Nice to see the doc/PR. I'm having trouble seeing what has changed because of the filename change. Do you think you could either revert the filename change or split the name change into its own commit?

@dverhaert

This comment has been minimized.

Copy link
Contributor

dverhaert commented Jun 14, 2018

Done! Tried splitting the name change into it's own commit, but this also led to git seeing a complete new file.

@bradjc
Copy link
Contributor

bradjc left a comment

Maybe a suggestion: move all of the notes about access restrictions to their own section. That section can then be very clear about the conceptual memory access restrictions, and how those are enforced by an MPU. Then it can also discuss the caveats: Rust does compile-time access restriction, processes can write their own flash (except for the header) using a capsule, etc.


## Flash
The kernel has the highest privileges and thus also full control, meaning the
ability to access all parts of code. Processes on the other hand have specific

This comment has been minimized.

@bradjc

bradjc Jun 14, 2018

Contributor

This is technically true of course, particularly from an MPU point of view, but I think we should at least note that the rust type system in practice restricts what the kernel can do. For example, a capsule cannot access a process's memory.

This comment has been minimized.

@dverhaert

dverhaert Jun 14, 2018

Contributor

What are the exact restrictions of a capsule?

This comment has been minimized.

@bradjc

bradjc Jun 14, 2018

Contributor

They cannot use unsafe. So they can only access memory and objects that are explicitly passed to them, and the only process memory a capsule ever gets passed is through the allow system call. They can't, for example, create and use a pointer to arbitrary memory, even though they are executing as privileged code.

This comment has been minimized.

@alevy

alevy Jun 15, 2018

Member

Right, this is a bit tricky do decide whether it goes in this doc or not. It is important for the tock isolation model that capsules are restricted from accessing arbitrary process memroy--they can only access process memory the process explicitly shares with them (through the allow system call).

So maybe the point in this doc, from a process perspective is that a process is guaranteed that capsules or other processes cannot access any of their memory unless the process allows it. That's a guarantee the process can rely on, rather than a restrictions.

valid process is set to all 0x00 or 0xFF.

Processes have read-only access to their own memory in flash, but can not read
other processes' code.

This comment has been minimized.

@bradjc

bradjc Jun 14, 2018

Contributor

Processes can, however, write their own flash using a system call (if the board supports it).

This comment has been minimized.

@ppannuto

ppannuto Jun 14, 2018

Member

Are there limits to this? i.e. can't write their own header (or even their own code?). I thought we had a dedicated 'app flash' area they wrote to? I don't totally remember how this works, but this would probably be a good place to document it

This comment has been minimized.

@bradjc

bradjc Jun 14, 2018

Contributor

Correct, they cannot overwrite the protected region of the app (as defined by the kernel) which includes the app header. However, from the perspective of this document, I think it is fair to assume that apps can write to any other part of their own flash (assuming the board supports it). The functions in the kernel crate that the app_flash capsule uses only protect the app header.

![Process' RAM](processram.png)

A process has full access to its own stack, data and heap. However, it has no
access to its grant region: this is only accessible by the kernel.

This comment has been minimized.

@ppannuto

ppannuto Jun 14, 2018

Member

It may be worth clarifying that the kernel doesn't really make a stack/data/heap distinction but for debugging prints on app crashes. Furthermore the app is in total control and can use syscalls to move these around at will. Clarifying the "kernel perspective" vs "app perspective" here I think would be valuable.

This comment has been minimized.

@dverhaert

dverhaert Jun 14, 2018

Contributor

How exactly would you see clarifying this perspective? Why does the kernel not make this distinction/is it relevant?

This comment has been minimized.

@alevy

alevy Jun 15, 2018

Member

The kernel doesn't make this distinction because it doesn't care at all how the process organizes it's own memory. This, for example, let's a process reorder it's heap, stack, static variables if it's more efficient/simpler/or even if it doesn't have a heap at all.

Processes can communicate with each other through an inter-process
communication (IPC) mechanism. If this is enabled, processes can read/write
specific parts of other processes. Otherwise, a process is never able to
read/write other processes' RAM.

This comment has been minimized.

@ppannuto

ppannuto Jun 14, 2018

Member

I might try to expand on this a little, right now it sounds scary: "enable IPC and other processes can read/write your memory!" :)

Tock includes an inter-process communication (IPC) mechanism built around memory sharing. A process may allow one or more other processes access to specific regions of its own memory. Allowed processes can then read or write this memory freely. A remote process can also send a notification to the sharing process to indicate that something has been written.

dverhaert added some commits Jun 13, 2018

Update and rename Memory_Layout.md to Memory.md
Adding information regarding isolation and updating old information

@dverhaert dverhaert force-pushed the dverhaert:master branch from 994108a to 2fc5faf Jun 15, 2018

@bradjc

bradjc approved these changes Jun 17, 2018

Copy link
Contributor

bradjc left a comment

I added some more detail to memory_isolation.md, but I think this is helpful documentation.

One thing I made a little more ambiguous is around process nonvolatile memory (in our platforms, flash). While it is true that we make the process flash region read only, from an architecture point of view I don't think that is something we mean to explicitly enforce, but rather a side effect from the complexities of writing flash memory. If we were running on FRAM, I'd imagine we would be ok with apps writing their own nonvolatile code/storage regions directly.

@alevy alevy merged commit 9814130 into tock:master Jun 19, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
deploy/netlify Deploy preview ready!
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment