181–190 of 192 posts
Earlier quoted context omitted.
Please no.
Care to explain?
Earlier quoted context omitted.
Out of the loop, why is Linux now "more hybrid"?
Many of the benefits of microkernels have been implemented in Linux over the past 25 years. Modules, FUSE, and live patching for example.
Earlier quoted context omitted.
Looks like `pyflame` was recently deprecated & archived. I've had success using `py-spy` for debugging perf issues. Flamegraphs are much nicer to work with than cProfile's output. https://github.com/benfred/py-spy
I just wrote up a quick survey of python profilers that hasn't been published yet, and along with py-spy, there is austin ( https://github.com/P403n1x87/austin ). The thing that I liked the most about austin is that it also samples the memory usage of the system so that you have the context of the world outside of the process being sampled, in case it is useful. That said, py-spy is easier to install (it can be insta…
I plan to test it out but hadn’t yet.
For anyone that wants to understand how py-spy works id also suggest the talk on rbspy (see YouTube) it’s great and basically the same but for ruby.
Sounds a lot like SPIN OS https://en.wikipedia.org/wiki/SPIN_(operating_system) They have to make do without type safety (in SPIN's case provided by modula-3), but it's really cool to see it tried. For those interested: SPIN and other hybrid kernels (like Exo) were created in the fall-out of "microkernels are bad" by attempting to allow a hybrid approach. Linux was created around the same time staying straight in the…
Out of the loop, why is Linux now "more hybrid"?
Earlier quoted context omitted.
According to https://news.ycombinator.com/item?id=18496054 , these programs have to halt? How does this system guarantee that the programs halt? Does this mean eBPF is not Turing complete?
The language itself is Turing complete, but the kernel will refuse to run a program that it cannot prove will halt. There are three categories of programs; programs you can trivially prove will halt, programs you can trivially prove won't halt, and programs where it's difficult or impossible to prove whether or not will halt. The third category is what we call the halting problem. Only the first category will be run…
eBPF reminds me a lot of exokernel type systems.
eBPF can be viewed as a mechanism to safely run user code in kernel since it uses a DSL and a compiler before the byte code is executed in kernel. This opens up doors for running performance critical functionality in kernel without having to bundle it with the kernel or very tightly coupled with the kernel version. Optimizing FUSE is an example: https://extfuse.github.io/ I expect custom security auditing software, r…
Bytecode + compiler was also how both Flash and Java Applets worked. Have we forgotten how secure those were?
You are correct however that allowing arbitrary eBPF code to be installed by untrusted users increases the attack surface. For example, we need to trust that the eBPF checker is correct, as well as the implementation of the eBPF operations. Moreover, even though eBPF may be safe I suspect it could potentially trigger or exploit bugs in internal kernel subsystems that might be harder or even impossible to trigger through the regular system call interface.
Brendan has a lot of great content that gets posted here regularly: http://www.brendangregg.com/ (I'm still trying find the time to get through it though). There's also https://github.com/iovisor/bcc#tools as an easy way to get started using BPF.
Earlier quoted context omitted.
Care to explain?
The tendency to dump all kinds of unrelated stuff in the kernel is a very bad trend. It increases the attacks surface of the kernel in unpredictable ways and will lead to security issues, especially with something as complex as an interpreter.
But I got your point. Thanks!
Earlier quoted context omitted.
You can see which bpf programs are loaded in the kernel via the bpf() syscall. Theoretically it could be used for a rootkit, but the programs needed to loaded as root, and they can't have side effects. BPF has also been around for a long time, and it's in basically all of the nix operating systems.
Generally agreed, but Linux BPF is considerably more powerful than traditional Unix BPF, so I wouldn't depend on "it has been around for a long time" for safety. I would like to see some academic research on Linux BPF verifier. If you are a graduate student working on formal methods looking for a topic, this is a hint.