doc/wg/core/notes/core-notes-2020-05-08.md
Attending:
- amit: we have no love for our current IPC interface, but can you be more precise about what is different?
- vadim: looks more like a series of IPC buffers that are extant, then syscalls change access to the buffers; a "transfer" of region from one to another
- amit: similar to an exchange heap? like move semantics?
- vadim: yes
- amit: regarding syscalls: where are all these additional cycles coming from? in old ARM measurements was ~300 cycles, mostly configuring MPU
- vadim: not my data, from Titan team, so not sure
- [editor's note]: looks like it's apples/oranges, those cycle #'s might be for semantic operations, which may be several syscalls, given suggested optimizations
- amit: in general, these sycall optimizations seem good; in the cases of back-to-back syscalls, how much of this is syscall design versus inefficiencies in userspace (e.g. redundant subscribe)
- vadim: probably some of both; subscribe likely userspace, but command+yield likely often useful
[end presentation]
- amit: for the certified crypto library, reasonable to think of it as basically a hardware interface that happens to be implemented in software?
- amit: probably written in C, exposes limited symbols?
- vadim: yeah, basically it's a vtable with 4 function pointers as APIs
- andrey: it actually has more than a single layer; there's those interfaces, but also some key management to be done in Tock / in Rust; more than just closed crypto lib
- andrey: e.g. key handles from flash, from applications, or from hardware; thus need additional abstraction on top of just primitives
- amit: specifically thinking about cases like Bluetooth, where external libraries also expected to own the privileged mode of the CPU; sounds like this is more reasonable to think of as a HW wrapper++, but more amenable to integration
- vadim: up to this point, need to be part of the core; have another idea in mind where only certain tasks have access to certain modules (and certain hardware); maybe with PMP support, only user mode task with access can access HW
- amit: that seems reasonable
- vadim: design choice here: generic API in Tock; or as an isolated app communicating back via IPC; unclear at this point
- amit: pitfall in other systems: some register in HW that can expose channels (e.g. DMA registers; or pinmux registers) that can be unexpected leakage mechanisms
- andrey: the bigger question: can this be made part of TockOS? [should we upstream]
- amit: this is on OT which is open source, and the crypto is open source, so.. yes
- leon: with the FIPS certification, what obstacles would the Rust layer above the API possibly present?
- vadim: FIPS basically asserts correct implementation of algorithms, correct random, correct testing; don't think a stability of APIs or Rust layer affect this
- vadim: big this is stability of the library; that would trigger re-cert. That's what motivates library as blob.
- leon: so no limitation on layers above, so long as there is a clean interface for HW or library backend
- vadim: yeah
- vadim: maybe extra capsules somewhere for key management or other policies / needs, but generally yeah; isolated blobs will work
- amit: curious to hear more about what the filesystem would look like? all the way to directories? KV Store? what's the use case?
- vadim: something like KV store partitioned to each app likely enough; or flat directory, one per app
- vadim: use case, app uses some kind of handle for state or configuration
- leon: would like to point to tock-dev persistent storage discussion; would like to see some of these needs captured there
- andrey: arch still under development; have a working impl in another OS for file system; more journal-like approach there; will propose similar here
- andrey: still under active dev, don't expect to see anything in next week, but something on the sooner side
- amit: and ACL needs?
- vadim: basically just each app has access to its own objects
- andrey: not necessarily physical partition, just data projection
- vadim: each flash page could have data from multiple apps; OS in charge of controlling data access
- amit: is this primarily for on-chip or external?
- andrey: this is for on-chip; have external, but different application
- vadim: looking for flash that could allow two writes to the same place; some flash allow only 1 write, some allow many, ours allows 2 before requiring an erase (get one 1->0 reset before an erase); allows some optimizations, but not all flashes support this
- andrey: that shouldn't necessarily limit how much we upstream here; the flash write layer should hopefully be below a filesystem
- vadim: yes, but the interface then needs to expose things like how many writes to given addresses