251–260 of 282 posts
WebAssembly is a better choice for sandboxing kernel code. It has a full formal specification with a mechanized proof of type safety, many high-performance implementations, broad toolchain support, is targetable from many languages, and a capability security model.
eBPF is fantastic, and it can be used for many purposes and improve a lot of things, but this is IMO overselling it. Assuming that BPF itself it free of bugs, it’s still a rather large sprawl of kernel hooks, and those hooks invoke eBPF code, which can call right back into the kernel. Here’s a list:
https://www.man7.org/linux/man-pages/man7/bpf-helpers.7.html
bpf_probe_read_kernel() is particularly heavily used, and it is not safe. It tries fairly hard not to OOPS or crash, but it is definitely not perfect.
The rest of that list contains plenty of this that will easily take down a system, even if it doesn’t actually oops or panic in the process.
And, of course, any tool that detects userspace “malicious behavior” and stops it can start calling everything malicious, and the computer becomes unusable.
Meanwhile, eBPF has no real security model on the userspace side. Actual attachment of an eBPF program goes through the bpf() syscall, not through sensibly permissioned operations on the underlying kernel objects being attached to, and there is nothing whatsoever that confines eBPF to, say, a container that uses it. (See bpf_probe_read_kernel() -- it's fundamentally able to read all kernel memory.)
So, IMO, most of the benefit of eBPF over ordinary kernel C code is that eBPF is kind of like writing code in a safe language with a limited unsafe API surface. It's a huge improvement for this sort of work, but it is not perfect by any means.
> The verifier is rigorous -- the Linux implementation has over 20,000 lines of code
The verifier is absurdly complex. I'd rather see something based on formal methods than 20kLOC of hand-written logic.
Earlier quoted context omitted.
Embrace, extend, ...
This doesn't really seem like their strategy anymore. It's not like Edge directly interprets Typescript, for example. While they embraced and extended Javascript, any extinguishing seems to be on the technical merits rather than corporate will. In the case of security scanners that run in the kernel, we learned this weekend that a market need exists. The mainstream media blamed Crowdstrike's bugs on "Windows". Micros…
Earlier quoted context omitted.
This assumes eBPF becomes the standard. It's not clear Microsoft wants that. They could create something else which integrates with dot net and push for that instead. Also this problem of too much software running in the kernel in an unbounded manner has long existed. Why should Microsoft suddenly invest in solving it on Windows?
> Why should Microsoft suddenly invest in solving it on Windows? If they can continue to avoid commercial repercussions for failing to provide a stable and secure system, then society should begin to hold them to account and force them to. I’m not necessarily advocating for eBPF here, either. If they want to get there through some “proprietary” means, so be it. Apple is doing much the same on their end by locking dow…
They have a long way to fall, but I'm not sure that if I'm a regulator I look at that and say there needs to be some kind of intervention by society apart from what market forces are gradually doing anyway.
Can someone tell me what's the advantage of eBPF over a user mode driver? The article makes it look it eBPF is have your cake and eat it too solution which is too good to be true? Can you run graphics drivers in eBPF for example?
No, you can't run arbitrary general-purpose programs in eBPF, and you cannot run graphics drivers in it. You generally can't run programs with unprovably bounded loops in eBPF, and your program can interact with the kernel only through a small series of explicitly enumerated "helpers" (for any given type of eBPF program, you probably have about 20 of these in total).
Surely that bars CrowdStrike's check for unprovably bounded vulnerabilities.
Earlier quoted context omitted.
I don’t understand statements like this. You only need to have some employee install some malware (unintentionally or otherwise); and you have a data breach on your hands.
I agree it's much more scalable to have a vendor install a spyware on all your workstations and have a centralized data breach.
> an unprecedented example of the inherent dangers of kernel programming I take issue with that. Kernel programming was not to blame; looking up addresses from a file and accessing those memory locations without any validation is. The same technique would yield the same result at any Ring.
Obviously in userspace it would only crash the running program and not the entire operating system? It's a significant difference. All of the service interruptions would have been just "computer temporarily not protected by crowdstrike agent". Not the same thing at all.
Significant and often far worse. It would leave the machine running unprotected.
Thank God some superheros have finally come along to make sure code never crashes any computers ever again! /s
"These security agents will then be safe and unable to cause a Windows kernel crash." Unless of course there is a bug in eBPF ( https://access.redhat.com/solutions/7068083 ) @brendangregg and the kernel panics/ BSoDs anyway which you mention later in the article of course.
“Many eyes” is a bit dubious in general but the Linux kernel is pretty much the best case for it being true.
Earlier quoted context omitted.
All of this could've been added to XP, right?
Longhorn was a significant rewrite, actually. The two big upheavals in windows history were: 2000, which essentially scrapped the 95 lineage in favour of NT; and Vista, which kicked a lot of 3rd-party crap out of the kernel and added a quality gate for drivers.