ATMFD strikes again, and undoubtedly not for the last time.
More info on the history of ATMFD (and some previous vulnerabilities): https://googleprojectzero.blogspot.com/2015/07/one-font-vuln...
More info on the history of ATMFD (and some previous vulnerabilities): https://googleprojectzero.blogspot.com/2015/07/one-font-vuln...
Back when "put everything in the kernel to make it fast" was the forefront of computing technology. Microsoft obviously still has work to do but they did take a large chunk of sound and graphics code out of kernel space in Vista.
Linux kernel/bpf is getting nervous.
joking aside (and sorry for going off on this tangent) under Linux it seems the kernel is eating more of user-space every year. That argument could of course be also turned around by claiming that user-space is eating the kernel. which ever way you look at - systems programming has gotten much more challenging (interesting) in the past years.
bpf is a sandbox, and unprivileged processes do not magically gain access to it; anything malicious that could be done with bpf could as easily be done with the coincident root privileges.
What is your example of where the Linux kernel is "eating more of user space every year"?
X.509 parsers... or three or so...
Heck, the entire io_uring system is a prime example of the Linux kernel “eating more of user space” - it’s essentially a programmable syscall pipeline that executes entirely in kernel mode. All to reduce some user/kernel transitions - exactly why ATMFD and http.sys were invented in the Windows kernel.
Except everything ATMFD does is basically obsolete if you have memory mapped files. FreeType works fine, nobody ever tried to put it in the kernel (at least upstream, in a form accessible to userspace).
No they can't. Calling bpf(2) requires you to be running as root or have CAP_SYS_ADMIN.
I am sure the engineers at Microsoft were shipping and not thinking about exploits. Or at least the exploits were the lesser of their worries.
to clarify I love ebpf traffic processing as opposed to having an iptables nfqueue[1] based approach (or worse a fully privileged kernel module).
my point was that userspace now looks different than before because I have to gain a pretty deep understanding of LLVM in order to do meaningful work to achieve the same goal (and be rewarded by a ~50% speed up).
Is ebpf user-space? Is it kerne-space? Is it something inbetween? I've written C for over 2 decades and have used assembler to optimize for embedded architecture where it made sense. far from an expert in assembler - maybe I'm not a good systems programmer because I should know more about this topic?
[1] I wrote this in January: https://github.com/DyslexicAtheist/nfq/ fully aware it could be done in ebpf but chose NFQ nevertheless - because my LLVM foo is simply not good enough. I feel either I'm dumb or the learning-curve is so big that it will take me a year or more to get the same done in ebpf. So ebpf has in some way hi-jacked my existing user-land skills :) not complaining - just saying my skill set has been obsoleted in a matter of few months - again not complaining - I will just have to dig deeper into LLVM and know more about the hardware than I did before :)
____
really don't understand where the downvotes are coming from since I haven't criticized the current approach. it seems HN is a bad place to make a joke.
I don't call having to tweak my kernel config to be very convenient, or the graphics driver crashing my system, or not having an obvious way to reboot the network/audio/FS stacks without doing a full reboot (I am sure it may be possible).
However, I am hardly the target market for gnu/linux.
Linux can't really do either of those things nicely because graphics is just another program. Although I'm sure you can isolate your don't decoding better than shoving it in the kernel.
Probably I'm wrong in that supposition there, but then what happens?
Am I missing something?
Moving things into the kernel is one heck of a sledgehammer solution to DLL Hell, at least.
(Windows 10 has slowly moved a lot of the graphics stack back out of kernel space. It appears to be moving the right direction, just very slowly.)
This makes exploits like this possible: https://sensepost.com/blog/2017/abusing-gdi-objects-for-ring...
The Vista experience shows you it was and still is necessary for perf.
I don’t know of any specific blogs/resources. I used to work on Excel’s render code so had a bit of an inside view.
There is:
https://portal.msrc.microsoft.com/en-US/security-guidance/ad...
Microsoft documents, as a possibility, how to "Rename ATMFD.DLL" and describes the impact.
> Rename ATMFD.DLL, or alternatively, disable the file from the registry
Caveat:
> Renaming ATMFD.DLL, the last recommended stopgap, will cause display problems for applications that rely on embedded fonts and could cause some apps to stop working if they use OpenType fonts.
Also from TFA:
> Monday’s advisory provides detailed instructions for both turning on and turning off all three workarounds.
(If you're reading lots of LaTeX-generated papers, then yes, you're probably seeing PostScript fonts.)