41–50 of 61 posts
Can someone explain what this is actually useful for, if you're not a kernel developer? Would people in userland care about anything like this?
Does make Spectre rather more potent thought!
From the readme: > I'm busy with my College Entrance Examination until ~June 10, 2018 This dude is in high school?! When I was your age I thought I was smart for writing a youtube scraper in PHP... Awesome work, really creative solution. Good luck to you.
From the readme: > I'm busy with my College Entrance Examination until ~June 10, 2018 This dude is in high school?! When I was your age I thought I was smart for writing a youtube scraper in PHP... Awesome work, really creative solution. Good luck to you.
> High school student. Interested in rust, operating systems, distributed systems and virtualization.
Hehe, when I was in hes age, my friend call me a hacker because I know how to use ping and ipconfig command on Windows.
Compare to him, I was really lame. What makes me more sad is, I'm still lame even today LOL.
Can someone explain what this is actually useful for, if you're not a kernel developer? Would people in userland care about anything like this?
But to summarize, jumps between kernal-space and user-space are expensive. Instead of doing that, we can run a well-vetted interpretor in kernal-space, and run "userspace" programs in kernal-space, in the interpretor.
This actually isn't slower (or so it is claimed), because a JITed interpretor can be native speed on hot-code paths, and the inefficiencies for most workloads are more than made up for by not having expensive syscalls.
So what you end up with is something that is about as fast as normal compiled code for cpu-intensive workloads (maybe faster sometimes), much faster for workloads involving a lot of syscalls, and interpreted languages like python/javascript end up much faster as well, presuming they can take advantage of the efficient JIT implementation.
Personally, what most exites me about this technology path, is that it should reduce the cost of interprocess communication to near zero. Combined with a shared object model, and a capabilities system, it could be pretty awesome.
From the readme: > I'm busy with my College Entrance Examination until ~June 10, 2018 This dude is in high school?! When I was your age I thought I was smart for writing a youtube scraper in PHP... Awesome work, really creative solution. Good luck to you.
From the readme: > I'm busy with my College Entrance Examination until ~June 10, 2018 This dude is in high school?! When I was your age I thought I was smart for writing a youtube scraper in PHP... Awesome work, really creative solution. Good luck to you.
From hes profile: https://github.com/losfair > High school student. Interested in rust, operating systems, distributed systems and virtualization. Hehe, when I was in hes age, my friend call me a hacker because I know how to use ping and ipconfig command on Windows. Compare to him, I was really lame. What makes me more sad is, I'm still lame even today LOL.
Earlier quoted context omitted.
From hes profile: https://github.com/losfair > High school student. Interested in rust, operating systems, distributed systems and virtualization. Hehe, when I was in hes age, my friend call me a hacker because I know how to use ping and ipconfig command on Windows. Compare to him, I was really lame. What makes me more sad is, I'm still lame even today LOL.
If you want to feel better, I didn't know what a variable was until I was 28. I feel pretty lame compared to virtually everyone here on HN haha.
Earlier quoted context omitted.
Why do you claim this? 1. Hardware sandboxing (i.e., ring not-0) isn't much better, as seen by Meltdown. 2. Most production-ready UNIXish kernels have had support for running untrusted code (namely BPF bytecode) in the kernel for decades. 3. Do you really trust all the code currently running in ring 0 on your computer? In particular, do you trust the executable loader. which handles complex untrusted input? What's th…
> 1. Hardware sandboxing (i.e., ring not-0) isn't much better, as seen by Meltdown. Meltdown was a single Intel bug, it did not occur on other CPU architectures or on AMD chips. It was a result of asynchronous permission checking and it is a side-channel disclosure (a non-write bug). It is objectively not as bad as the tens of thousands of buffer overruns and memory write vulnerabilities in software. > 2. Most produc…
I still think that this is a case of knowing how the sausage is made. I've operated public-facing Linux systems for many years (but I am not either a kernel nor V8 developer, so you know what you're talking about more than I do) and the Linux kernel is ... not good. You take security seriously, and find hundreds of bugs, and it scares you, which is great. The Linux kernel does not (remember the whole "security bugs are just normal bugs" thing, plus the resistance to architectural improvements that kill bug classes, which as far as I can tell you folks seem to be very excited about).
I would hope that you think that V8 + the associated Chrome sandbox (which, to be fair, I think does not have an equivalent in this project) is secure enough to be exposed to random JavaScript / WebAssembly from malicious parties on the internet running and updating 24/7, and keep things reasonably safe, because a billion people do exactly that. I'm not saying it's perfect or unbreakable - I'm just saying I definitely don't trust Linux to be secure against random userspace from malicious parties on the internet running and updating 24/7.
Highly related: https://github.com/nebulet/nebulet “(Going to be) A microkernel that implements a WebAssembly "usermode" that runs in Ring 0.” It’s inspired by the Microsoft experiment Singularity OS.
I've been wondering for a while as to why nobody was trying to run an entire VM at ring 0, the benefits would be significant. I was just not aware that's what Singularity/Midori were doing. I'm glad more people are picking up on it.
Before that the exokernels absolutely loved VMs at ring 0.