The kwast from kwast-os

Support SSE etc

Kernel heap

We need it soon because the wasm part of the kernel really depends on it.
We can use something like slab allocation as described by Jeff Bonwick for small objects.
The bigger objects can be allocated from a different allocator, something like a linked list or skip list.

small slabs create/free
freeing slabs when they're not needed anymore
big allocations
tests

Page coloring

Note: use multiple PMM stacks for this

Enough support to run simple PS/2 server

Function imports from kernel
Multitasked wasm
Some basic ABI stuff
PS/2 stuff

Optional hardware protection domains

Holds one or more SIPs.

Determine default stack size and guard stack size

Also, lazily allocate part of the stack?
Increase limit of interrupt stack?

Optimisation: heap caches for important datastructures

Specialised caches for the compilation is a nice optimisation to have.

For Cranelift datastructures
For kernel datastructures such as Process and Thread

Big realloc fails

"Proxy" microkernel server

Idea for the far future:

We have a microkernel architecture, which means that every service runs as a server. We could create a program that acts as a proxy for those servers.
The proxy intercepts the traffic between user program <-> server and could send it over network to another computer.
Could be used so other computers could interact with a device on another computer using such proxy server, could happen transparently.

ABI

Options:

WASI seems promising, I need to look more into it.
Make my own?

Lazy FPU store (without disabling FPU)

Some quick benchmarks show that a FPU store+restore takes about 32ns on my system (i7 4th gen 3.6GHz).
A single FPU store requires about 16ns.
Pingpong IPC requires two context switches, which means a 64ns overhead on FPU state.

Doing a lazy FPU store + restore the classic way requires disabling the FPU and relying on an ISR to re-enable and restore.
However, this approach has more overhead than what you get back (> 32ns) as I measured.
Besides the overhead issue, there's also the lazy FPU restore vulnerability. If a lazy mechanism is implemented, it can only be applied to storing the FPU state: the current task must always have its own FPU state loaded.

An alternative method to implement FPU lazy store is relying in the compiler.
If we could detect the use of FPU instructions in a basic block, we could insert an instruction in that basic block which sets a flag, something like this:

movb $1, %fs:0 // With fs the TLS register, assuming offset 0 is the flag offset

This would mean that the hardware overhead for lazy FPU store is replaced by a single move instruction, which should be pretty cheap.

Capabilities and permission design

Run compiler isolated

So panics, memory allocation can be recovered from.

Multitasking

Spectre, Meltdown & related issues

Note: I'm not sure about all of this.
Using classification of https://arxiv.org/pdf/1811.05441.pdf

Processes

Processes can run in the same hardware protection domain, or in a seperate domain. In case of the same domain, we rely on software isolation.
We give each process a 4GiB slice, to be used as a data heap. Processes can only address in this slice because memory accesses are represented as a "64-bit heap offset" + "32-bit user offset". We control the 64-bit offset, so it is impossible to address outside of your own slice. The code the processes are executing is located elsewhere in memory.

Spectre-PHT, Spectre-BTB, Spectre-RSB, Spectre-STL

Microcode and compiler mitigations inside Cranelift may help (Cranelift currently doesn't do that)?

Meltdown

Meltdown-US (original meltdown)

This is about leaking kernel memory. As far as I know, you need to be able to construct an address pointing to the kernel memory you want to leak. Due to the way processes are set up, this is not possible.

Meltdown-P

?

Meltdown-GP (Rogue System Register Read, Spectre variant 3a)

Architecture system registers cannot be represented in WebAssembly. System registers are accessed inside the kernel itself, so I'm not sure if that can be used in a way.

Meltdown-NM (Lazy FP State Restore)

Solution: Always restore the FP state, don't use the lazy restore mechanism.
Most applications nowadays use SIMD optimisations anyways, so the impact is not too bad.

Meltdown-RW (Read-only Protection Bypass, Spectre variant 1.2)

Does this require the creation of an arbitrary pointer, or can it be exploited in another way?

Meltdown-PK

?

Meltdown-BR

Software doesn't have direct access to the instructions required to trigger a "Bound Range Exceeded" exception. If this is ever exposed, the kernel will have to be involved, so this could maybe be mitigated there?

Microarchitectural Data Sampling

The vulnerabilities need (at least) microcode updates.

Locks of active page structure

Should figure out what locks to take, especially when modifying page table structures.

May not be necessary because each process will have their own virtual memory regions stored outside of the page tables.

If a service wants to map a MMIO area, we would have to make sure that no one else mapped this, but doing this in the page tables is probably not a good idea.

Locks will be needed when modifying tables (creating tables, removing, changing used count)

finish up most of the work in wasm_test
get cranelift to work inside the kernel
get basic relocations and memory working
allocate resources for process

Implement PCID

This helps the case of multiple address spaces.

Correct mapping of kernel sections

We should correctly map the kernel (and boot modules), now everything is read+write+execute.

kwast-os / kwast Goto Github PK

kwast's People

Contributors

Stargazers

Watchers

Forkers

kwast's Issues