Microsoft embraces Linux kernel's eBPF super-tool, extends it for Windows Microsoft on Monday launched an open source project to make a Linux kernel tool known as eBPF, short for Extended Berkeley Packet Filter, work on Windows. Inspired by network packet filtering and capture software dubbed Berkeley Packet Filter, eBPF is a register-based virtual machine designed to run custom 64-bit RISC-like …
There have been a number of vulnerabilities already reported with BPF over the years.
Although it is a virtual machine, it is really pretty simple, and is implemented to do some complex pattern matching on network packets. It is normally programmed by a tool such as tcpdump or wireshark (and firewall implementations), which take the required pattern, and then create a simple program that can be run against the packets to filter the ones of interest,
On Linux and UNIX systems that implement it, it is necessary to have a privileged session/process already to inject the generated program into the kernel based BPF. Obviously, if you have privilege already, this is a less of a threat.
The kernel based VM that runs the BPF code is sandboxed inside the kernel (and may actually be running in a kernel process, I've not looked that closely that at it), although the quality of the security is in strength of the sandbox.
The name is about the only similarity at the implementation level as the current BPF. It can do a few cool things, like PCI bus snooping. Things that totally won't be turned against us by evil ransomware and root kits.
eBPF will need privleges, but then again, windows has been pretty lax about local privilege escalation.
This screams hypervisor escape to me, but I need to do some more reading on how they're corralling it. Just finished the back story on the Metadata passing bun fight on the Kernel Dev lists.
You missed the part that one of the big contributors is Lennart Poettering, of systemd fame.
So of course it's named after the BPF but uses no BPF compatible semantics. There are security issues that are still being sorted at an architecture level, and now not only has the unholy hand of Pottering tainted the linux Kernel, it now runs on windows too. But Lennart says it's fine.
So keep a spare sixer in the cooler, because one day, this will probably spawn a cross platform rootkit, and you won't want to be the only one without recourse to a stiff drink.
and WTF if you are emulating an instruction set why not use the one systems already running on and your developers already know?
> WTF if you are emulating an instruction set why not use the one systems already running on and your developers already know?
3 reasons:
1) The amd64 instruction set is hideously complex and hard to emulate. Mainly because of backwards compatibility. While knowing nothing about the eBPF instruction set, I can confidently say that it's a lot simpler than amd64.
2) The advantages of amd64 are: You don't have to run it in a VM, you can just run it and have huge security holes, so that advantage is not actually useful. And: your developers already know it, although if you try to pick a sane safe subset then you lose that advantage as the developers have to learn what's in the subset and what isn't.
3) If you want to design a "safe" language, you don't start with an unsafe one and fix the holes you know about, you'll miss some. You start with a new, simple, well-defined language and try not to introduce security vulnerabilities as you go.
While I appreciate the fine points you raise, (and not calling out the glaring typos) I think your first 2 points would fall under more debate, as it's still almost certainly faster, easier, and safer to train someone up on a reduced instruction set then a whole new one.
Also, the existing code profiling tools and other bits for analysis can be applied, and are also familiar the broader community. So there is a prayer that if someone bothers to audit this stuff before it escapes the lab, they may stop some of the howlers that are probably waiting in there.
Hey, maybe I'm wrong though and we've all been hacking away on custom 64-bit RISK machines all summer. And by we I mean the rest of you, as my alt platforms were limited to an old Pi, a USB microcontroller, and some ARM stuff from a very old and VERY cheap android tablet. YMMV. Changing the instruction set would certainly be a trade off in accessibility and utility vs greatly reduced surface area.
Still your last point stands as good advice, especially on a day where apparently even a Universal Turing Machine running on imaginary paper tape has security flaws baked in.
1) I'm a major BPF contributor (tracing) and have worked on eBPF since 2014, and Lennart's name hasn't come up. I don't know where you're getting your information from.
2) BPF is a generic sandbox. Like JavaScript. Hence presenting an instruction set. Don't worry, it gets compiled into machine code, so it isn't slow. It provides a way to build kernel solutions that are safe for people to run (and many already are, in production). In simple terms: if you're a Windows user, it's the difference between downloading and running a .exe vs visiting a website with JavaScript. Huge difference, right?
This move reflects the change in the ideological stance of MS. Earlier, anything coming out of Linux used to be frowned upon by MS and there was an inclination to build something in parallel.
By adopting eBPF, MS is proving that it is maturing in terms of thought process. It doesn't simply reject anything coming out of Linux and is keen on working out the model that has worked out on Linux. eBPF has proved immensely successful for observability, monitoring, and lately for security enforcement and performance tuning on Linux. By adopting eBPF, MS will reduce the efforts required by security developers having to rebuild the same security engines again for MS windows. This certainly helps MS.
However, it remains to be seen as to how much of Linux eBPF hooks, primitives can actually percolate in MS Win. The power of eBPF lies in the hooks, helper functions, and maturity of the kernel verifier. Linux recently coupled eBPF with LSM hooks (called KRSI). How would MS Win handle this?
Anyways, a great start nonetheless, and looking forward.
"Earlier, anything coming out of Linux used to be frowned upon by MS"
Actually, I think it's a reversion to Bill Gates' original 1970s vision of PCs on desktops backed up by Unix servers. In the 1980s, the early MS devoted a lot of resource to its PC unix (XENIX) which was later subsumed into SCO back when SCO was a real software company and before SCO decided that copyright trolling was easier than working for a living.
"Bill Gates' original 1970s vision"
He had quite a few visions. There was the RAM related one that might be apocryphal but his dismissal of the internet as a thing was not his finest hour. The scramble to buy Mosaic was quite unseemly.
What Bill n Co did really well was IBM style bully boy with knobs on. They pulled off monopolistic practices that would leave the former Bell breathless and trembling at the knees. They bought extensively and often well. The entirety of MS Office is bought in, MS SQL, Skype and many, many more.
I can't help but begrudgingly admire the corporate skill that enabled these monsters to grow to such huge sizes without either im or exploding. I still hate the fuckers. I wasted so much time pissing around with their shit software. Anyone remember tweaking autoexec.bat and himem.sys to get a bloody game to run. Win95 ("What's a CDROM drive?" "I installed you from CD, there was a drum and everything" ... "Duh what's a CDROM drive" ... ... blue screen)
Whoops, sorry got carried away.
Bill's gift was the ruthless and efficient pursuit of cash. He was not and never was a visionary in the sense that you'd go and study his wisdom. The B and M Gates foundation is a good shout and has done some good.
Don't think it is.
Word was definitely written in-house, although the people who wrote it came from Xerox, it appears.
I know that Excel was bought in. Although R:Base was bought, it appears that Access was internally developed in parallel as Project Cirrus. Outlook appears to be internally developed, but Powerpoint was an acquisition (Forethought).
Visio was bought.
SQL Server (not srtictly part of Office) came from a database company they bought (Sybase?).
I've been downvoted for saying this before, and I guess I will again... Microsoft don't care any more about Windows. It has had its time and they have moved on. They would be very happy to have it replaced by Linux on servers, and by something a lot simpler (more like Android) for user devices (mainly tablets and phones, and some hold-out desktops). They are almost there -- the holdout is professional and specialised (high performance) workstations.
Microsoft care about what us old timers call "applications" and young people call "cloud services". They make their money by automating enterprises. So, mail and file storage applications, user tools like enterprise co-operative working and sharing environments, big data storage and the tools to exploit it, very expensive tools to manage high-risk regulatory requirements, etc. etc.
The sooner Windows goes away, the better for them - they can work on stuff that really makes them money. They are happy with Linux - it is not as though they are letting the money go to their competitors (AWS, Google, Oracle). I can see eBPF as being a really useful tool for them for making Linux do some things that the kernel devs aren't interested in but which they need to carry over from Windows. And in a way which minimizes their maintenance costs for keeping it working on future kernel releases.
Microsoft embraces... extends... falls flat on its face when it tries to extinguish.
How can you extinguish some thing that is like the Hydra? Cut off one head and another will appear, stronger and fiercer than the last.
A lot of people dislike and mistrust RMS but you have to give him credit for working out the GPL and also thank all those who took it up and applied it to their work.
MS can scrump as many apples from the Gnu/Linux orchard as it likes but it has no chance of taking it over and wiping it out.
Don't bet on it. I wouldn't put it past them to poison the well by sending back broken-by-design patches.
Besides they're not concerned about the bulk of the FLOSS community, only wanting to suck away as many businesses as they can - ideally enough to weaken the big distros.
I've been wanting THIS for a long time.
It might cause some initial problems, due to case-sensitivity of file names and the use of '/' vs '\', as well as drive letters and different device names/handling, but I believe if they were to "embrace" Wine, and migrate to a Linux kernel with Wine on top, we'd all be better for it.
I'd pay money for that, particularly if I can keep my Mate desktop and just use the subsystem to run windows applications.
People use Windows for backward compatibility with existing Windows apps, and with future Windows apps that they might buy.
WINE is not compatible enough, and probably never will be.
(I mean, WINE is great and if it runs the Windows apps you want to run, perhaps with a bit of messing around on your part and/or a few minor features broken, then that's great. But that's not enough for all customers, and worse it's not predictable without trying it. It's never going to be as compatible as just starting with the Windows codebase).
eBPF was a project before Microsoft proposed this. It's been a part of the Linux Kernel since 3.18 and currently Linux translates BPF bytecode to eBPF before executing it. So it's not a Microsoft conspiracy, it's something Microsoft thinks would be useful if it worked in Windows.
Microsoft is assigning employees to develop open source code which will be available to the community. It's not forcing people to use it or have a Microsoft account to use it, it's just putting it out there for people who find it useful (including Microsoft, obviously).
More programmers producing more open source code seems to me like a good thing.
Extending systemd Security Features with eBPF
That's right, the only place guaranteed free from systemd, the Linux Kernel, won't be any more.
Christ on a bike!
Reading that referenced document makes me wonder whether future Linux systems will remain maintainable.
Sure, I can see uses for it, but if you can modify the behavior of any LSF hook by attaching eBPF code to it, the OS becomes a support nightmare, especially if the error messages in the quoted examples remain so generic.
When faced with a problem, you will need to be able to take in the entirety of these attached modifications before you can understand it. It's already difficult enough, but being able to change fundamental behavior on-the-fly is, IMHO, a disaster waiting to happen.
> and application programming interfaces (APIs) on
Again. I have seen innumerable announcements and other texts, where the abbreviation API is defined in precisely this way, and never used again in the text. Besides, by now everyone knows what it stands for.
Sort of obligatory shibboleth to mention it.
Actually, the amusing thing here is that typically the abbreviation "API" is defined as in the example, but never used again in the same text. So why define it?
(I definitely agree it is a good idea to always define your TLA:s when you really use them).
My thought is that while in this example the term is only used once, if just the letters API were in the article then it may not be understood by some readers and therefore should be expanded. In this instance it's not about re-using the acronym later in the article, it's about using it once and ensuring that it's clear.
As someone who knows what an API is the article would have read a little strange to me if it just read "application programming interface" because I tend to expect the acronym API to be used instead. However, for someone who doesn't know what the term API is, including the expanded as well form aids those readers and doesn't detract from the article even if the acronym isn't used again later.
There's likely some good Search Engine Optimisation (SEO) reasons for including it in both forms too.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
