comesee

Theres nothing you can do. Just accept what management wants and do your job as best as you can

Google is clearly evil now. Will anyone do anything about it?

Your anecdote is valid but so is wil Wheaton's http://wilwheaton.net/2018/08/the-world-is-a-terrible-place-...

This is super cool. For what are you using it?

I've authentically made the front page 3 times in the past two weeks. No help from my friends.

jcs is pretty good

Fwiw Dbxfs seems to be a lot faster than rclone

Good point on the MMU performance advantage and trade offs involved. When everyone's heads were on fire, made sense to indiscriminately mask off user controlled pointers. Now that the dust has settled a bit I imagine we'll see more usage of memory mapping tricks in performance critical sections.

I'm still not sure how this is relevant to wasmjit?

Your criticism is for another layer. If you don't like C, use Rust or Go. They also compile to wasm.

I never argued that it shouldn't, just that the issues you're raising aren't relevant to the security of running wasm in kernel space.

Again, not in any way that can cause instability to the kernel differently from running the same program in user space.

You can do masking in the same way Linux does it. It prevents "branch code bypass" without using an explicit size:

    cmp %bound, %ptr
    jae bad_ptr
    sbb %mask, %mask
    and %mask, %ptr

Just two extra instructions. No need to memory map or hard code the size of bounds.

See `array_index_mask_nospec` in https://github.com/torvalds/linux/blob/master/arch/x86/inclu...

How is this relevant to wasmjit? User space programs written in C can already corrupt themselves. As far as I can tell there is no new inherent risk to kernel stability by running wasm code in kernel space as long as the wasm spec is followed. Just like wasm programs aren't able to corrupt the browser sandbox in which they run.

Performing operations using the segmented registers is no faster than using the 32-bit analogues. Benchmark an add of eax,edx vs Al,dl in a loop.

This is a moot point, the entire kernel is written in C. Since all code running on your computer involves kernel code running in ring 0, by your logic that would imply something is wrong, but it's not. System calls verify all input before executing.

WebAssembly protects the host from memory corruption by the user module. To do this it does a bounds check before executing the load. It does not protect a user module from itself. It does not change the semantics of C.

Relevant documentation http://webassembly.github.io/spec/core/syntax/instructions.h...

Wasm has efficient 16/8 byte load/store instructions. 16/8 bit data types are irrelevant on x86 since it internally uses 32 bit registers anyway.

The load8_s instruction will check that the computed offset into the memory of size 64KB (1 wasm page) does not index past the bounds of 64KB. If it does, the program will trap.

It does

I read through it and this is indeed how it works. Wasm as a language provides the restrictions that the MMU provides for machine code. You can't read from/write to arbitrary pointers in wasm.

From looking at high_level.h it can instantiate any wasm file, but it seems to need the host code specially integrated. There is a function to instantiate the emscripten runtime, probably code can be added to instantiate the go or rust runtimes.

Emscripten seems like a good start, the tooling already exists.

Aren't those side channels dependent on addressing kernel memory that you don't have permissions for? You can't address kernel memory in WebAssembly, therefore you can't provoke the speculator into caching those pages.

How so? WebAssembly can't address memory outside of its sandbox

Upon inspection of the code, it seems like this is something that could be used by browsers as well...

Yeah the education category is alright https://www.fairtrending.com/?lang=en&fc=cat&cat=27&tag=&msc...

I used the filter on the site and I watched a view of these videos https://www.fairtrending.com/?lang=en&fc=cat&cat=28&tag=&msc...

The default feed is pretty clickbaity but I filtered to only show the technology category and it's not terrible https://www.fairtrending.com/?lang=en&fc=cat&cat=28&tag=&msc...

Though it seems to be a different list of clickbaity garbage from https://m.youtube.com/feed/trending which is sort of interesting.

I think the "preying on fish" part is key here not "scientifically observed." A captive mantis eating a fish placed in front of it is different from a wild mantis specifically hunting fish.