It looks like MS have had a few attempts at tightening up the potential for security exploits caused by executing what can effectively be untrusted code (the glyph program) in kernel space. This is why fonts are considered system components - they are code, not data, executing on a VM.
If you like MS conspiracy theories of course, you can pretend that it's a deliberate ploy to break LibreOffice, but personally I think that's tin-foil hat territory. Most likely there's a bug in the GDI code triggered by an unusual glyph in the font (perhaps in turn generated by a bug in whatever font design software was used). Complexity + poor choice of performance optimisation = fail. At least the kernel bug check is working as designed - if only all OSes were so robust in the face of memory corruption.
Hi, I filed the bug. I definitely don't think that Microsoft deliberately went out of their way to cause issues for LibreOffice. I am surprised that they basically allow untrusted input like a font to be passed to a kernel function, which can then cause the kernel to panic.
I don't think I've seen any kernel deal directly with fonts. I understand the reasoning they added the GDI to kernel space, but IMHO it seems to me that they should seriously reconsider their reasoning.
At the very least, they need to relook at their glyph parsing/building algorithm and perhaps look into better fuzz testing around these routines. Just my 2c :-)
We have a crash caused by memory writes in the kernel. What part of this doesn't suggest kernel mode exploitation via a cleverly-crafted font that can be embedded into a web page or PDF? Font bugs should result in errors, not BSODs. Untrusted code on a VM is easy to secure: make the VM do nothing more then draw some glyphs, and check every access!
If you like MS conspiracy theories of course, you can pretend that it's a deliberate ploy to break LibreOffice
If they hadn't done the same sort of thing before, it would sound like a conspiracy theory. Since they have, well... DOS isn't done 'til Lotus won't run, right?
The original design of Windows NT had the graphics stack in user space. It remained this way in the first two releases, 3.1 and 3.5, but the performance was not competitive with desktop contemporaries like OS/2 and Win95 that had graphics in the kernel. So Windows NT 4.0 reverted to that design.
I guess part of the reason for the poor performance was that video card drivers of the era were tightly coupled with the OS, effectively replacing GDI functions with their own implementations. The NT 3.x design made it difficult to support these existing graphics accelerators.
Graphics drivers were moved into user mode in Windows Vista. If you've ever seen the screen blink, and a balloon pop up saying that the graphics driver was restarted -- that would've been a bluescreen in XP.
I wonder why they didn't move the rest of GDI out of the kernel at the same time? A composing window manager was also introduced in Windows Vista, which really cuts down on the number of window repaints. Surely they can afford to take the performance hit now?
If I were going to write a microkernel OS today, and was going to rely entirely on the GPU for rendering, could I get away with putting the graphics stack entirely in user-space, or would it still be relatively slower?
In Linux systems good chunk of graphics stack already resides in userspace. The kernel provides only modesetting, GPU memory management, access multiplexing and isolation.
Applications render by calling OpenGL library, which obviously executes in calling processes. OpenGL library asks the kernel to allocate required memory buffers, prepares code for the GPU and submits it to the kernel for execution. Kernel collects jobs submitted by processes, executes them on the GPU and notifies processes on completion.
When application wants to display something on the screen, it shares its buffer with the X server (or equivalent) and instructs it to redraw its window from this buffer. The display server uses some special syscall to obtain access to screen output buffer.
Remember the news that L4D2 on Linux outperformed the Windows version? As I understand it, the L4D2 code base uses Direct 3D, and on Linux it uses a D3D emulator with OpenGL as the backend, and yet after going through these user-space hoops it still gets a better framerate. The best theory I've heard is that context switching is cheaper on Linux.
"D3D emulator with OpenGL as the backend" sounds an awful lot like Wine. There've been reports of Wine apps running faster than their Windows equivalent too, although usually some wine bug or another gets in the way of performance.
This wouldn't surprise me. Based on the console output, Counterstrike Source does the same thing. Lots of output about Direct3D that look exactly like messages from wine. I suspect they did this to speed up porting.
Usually the user-space overhead is real tiny, I can't imagine it would be needed to place it in the kernel. Linux has the high-level graphics stack in user-space and it works just fine.
This (plus some low-level register poking) is the stuff you would need to implement in your GPU daemon. Actual generation of drawing commands, compilation of shaders etc is performed by applications.
The overhead should be in the order of few context switches to the GPU server for each frame rendered by any application (in Linux it's few syscalls instead of context switches). Probably not terrible.
This is the kind of stuff that makes Windows seem like alien territory to me. The last time I looked at code using the win32 api, I noticed that the spawn() call accepts a bitmask which can determine whether a window is drawn for the process or not. The window system is so tightly coupled with the kernel that it's in the system calls? I guess Windows really earns its name.
This is win32 and does not represent the NT kernel in any way. There is a load of stuff they had to port from win16 which was shit and have been stuck with it ever since that effectively compromises NT's architecture. GDI in kernel space was a pragmatic choice considering the other competitors on the workstation market were basically HP, Sun and SGI and they all had nearly graphics acceleration.
I like to tell people "Deep inside all the Windows NT distributions there's a great OS dying to get out...". REACTOS gives me hope that, someday, there'll be a distribution of an NT-based operating system w/o Win32. (Interix on top of NT w/o Win32 would have been close to what I'd have been interested in seeing...)
> I like to tell people "Deep inside all the Windows NT distributions there's a great OS dying to get out...".
I was a dev in the Windows organization for a few years and this is the conclusion I came to as well. When people complain about development on Windows, they're rarely talking about NT or even Win32. They're usually talking about some layer on top.
Even the example here about spawn() - that function is from the CRT, which honestly is a very crummy and poorly maintained library, but more importantly it isn't really "Windows" and couldn't really be called "the Windows API" - it's just some library that gets new versions alongside releases of Visual Studio. And that spawn() function, ironically enough, mostly exists so that people who know the fork + exec pattern will feel at home.
:) +1 for REACTOS. I am one of those that is looking forward to that one becoming mainstream... They have a GSOC running this year too. I hope they get enough traction to get it in some shape.
I should note that I had the darndest time trying to install the Winows debugging tools on my laptop - not least because I believe that Windows caches all the fonts and was bug checking every time I did so.
Your assumptions make you look foolish. I did indeed Google for the installer, I then attempted to install it. Here's where the difficulties were:
Firstly, it's massive. Recall that I said that every 45 minties or so my laptop would BSOD. Secondly, when I tried to install it the install failed with obscure Windows installer errors.
I've installed it hundreds of times with no problems. Its also not huge - it only downloads the parts you need which includes just the debuggers if you want.
What obscure msi errors?
Just to add, when windows crashes it leaves a minidump on disk. Usual practice is to get this on another host and debug there. If you're out or away from such a facility, that's what system restore is for.
Thanks for the lecture. System restore, for a variety of reasons, wasn't going to help me here. I was able to troubleshoot and restore my system to normal without system restore. Not to mention had I installed LibreOffice again, the issue would have reappeared - system restore would not have helped.
I don't know that they _had_ to release an update, but as a Mathematica user who was seeing WordPad (yes, WordPad) bluescreen my computer, I was really happy that Wolfram fixed it for me so I didn't have to wait for Windows to.
I've considered this. I don't believe that Microsoft loads ttf fonts directly from webpages. I also don't believe that IE uses the Win32 API for font rendering, but uses it's own engine.
IE9+ uses DirectWrite and Direct2D API for font rendering. [0] That is why they added a "Hardware Acceleration" setting. I would guess this bug could have the same effect in IE. I have no idea what it does when you turn off hardware acceleration though.
That is not true. IE do load EOT and later WOFF fonts from webpages and pass them to the OS engine. Even the other web browsers still uses the OS engine, they just sanitize the font using OTS before doing so. Hence if reproducible yes this should be sent to MSRC.
FWIW I just updated LibreOffice to 4.0.1.2 from 4.0.0 and cannot reproduce the issue with the steps in the bugzilla link so there may be some additional requirement for the bug to surface. Possibly a GPU from a specific manufacturer?
Fonts are rendered by the kernel (architecture bug explained above), fonts have "code" in the form of hints which directs the rendering. Bad data in the fonts and/or hinting leads to the rendering algorithm overwriting memory/stack. Since we're in kernel mode it doesn't generate a fault and instead corrupts the kernel. Blam! BSOD.
No doubt there are zero day exploits in there as well.
Actually, even without hints or any other "code" parsing nontrivial formats provides opportunities for bugs causing buffer overflows or other memory corruptions. This simply shouldn't be done in the kernel, period.
However, twenty years ago (when this code likely has been written) security in the PC world was pretty much nonexistent and nobody cared about such issues.
Btw, this attachment seems to contain the real meat (STACK TEXT): https://bugs.freedesktop.org/attachment.cgi?id=77055