3 ms·

I think this was part of the shell layer. Which is why it's fascinating how the performance team wanted to prune it out; presumably the fonts were mapped into

I *think* this was part of the shell layer. Which is why it's fascinating how the performance team wanted to prune it out; presumably the fonts were mapped into memory elsewhere and thus deduplic...oh, maybe Windows doesn't have mmap page dedupe.

raverbashing 5y ago
Edit: I don't think the kernel would render TTF and/or use the full graphical stak so that's probably the main difference It probably has, but maybe not between kernel and userspace
- formerly_proven 5y ago
  > Edit: I don't think the kernel would render TTF and/or use the full graphical stak so that's probably the main difference Oh but it does. Most (all?) text rendering on Windows happens in the kernel.
  - raverbashing 5y ago
    I stand corrected then! (Unless this changed recently) https://googleprojectzero.blogspot.com/2016/06/a-year-of-windows-kernel-font-fuzzing-1_27.html https://googleprojectzero.blogspot.com/2016/06/a-year-of-win...
    - zinekeller 5y ago
      I mean, in recent version of Windows it's now on the user-space, but because Microsoft retains bug-for-bug compatibility Windows 8 will be stuck with a kernel font rasteriser* * DirectWrite and WPF have been always user-space.
  - fredoralive 5y ago
    AFAIK stuff like .net's WPF and the GPU accelerated DirectWrite do font rendering in userspace. It's ye olde GDI that is in the kernel, because NT didn't run well on a 486[1]. Yes, Windows has about 5 different ways to render fonts, and no, they don't seem to render fonts the same way. (In the case of this kernel text mode / BSOD code, I do wonder does it use the GDI font rendering, or does it have its own separate mini renderer just for those screens?) [1] Probably a bit of a simplification, I know.
    - formerly_proven 5y ago
      I don't know anything about DirectWrite, but there seems to be a DirectWrite kernel component due to CVE-2020-1577 (DirectWrite leaking kernel memory "by convincing a user to visit an untrusted webpage", which I'm not sure whether the exploit route would be in TTF/OTF processing, e.g. due to webfonts, or the text rendering itself).
monocasa 5y ago
NT's VFS cache does a decent enough job at sharing pages to actual data for the same file, even between kernel space and user space; the problems start around FS metadata caching.

I *think* this was part of the shell layer. Which is why it's fascinating how the performance team wanted to prune it out; presumably the fonts were mapped into

raverbashing 5y ago

Edit: I don't think the kernel would render TTF and/or use the full graphical stak so that's probably the main difference It probably has, but maybe not between kernel and userspace

formerly_proven 5y ago
> Edit: I don't think the kernel would render TTF and/or use the full graphical stak so that's probably the main difference Oh but it does. Most (all?) text rendering on Windows happens in the kernel.
- raverbashing 5y ago
  I stand corrected then! (Unless this changed recently) https://googleprojectzero.blogspot.com/2016/06/a-year-of-windows-kernel-font-fuzzing-1_27.html https://googleprojectzero.blogspot.com/2016/06/a-year-of-win...
  - zinekeller 5y ago
    I mean, in recent version of Windows it's now on the user-space, but because Microsoft retains bug-for-bug compatibility Windows 8 will be stuck with a kernel font rasteriser* * DirectWrite and WPF have been always user-space.
- fredoralive 5y ago
  AFAIK stuff like .net's WPF and the GPU accelerated DirectWrite do font rendering in userspace. It's ye olde GDI that is in the kernel, because NT didn't run well on a 486[1]. Yes, Windows has about 5 different ways to render fonts, and no, they don't seem to render fonts the same way. (In the case of this kernel text mode / BSOD code, I do wonder does it use the GDI font rendering, or does it have its own separate mini renderer just for those screens?) [1] Probably a bit of a simplification, I know.
  - formerly_proven 5y ago
    I don't know anything about DirectWrite, but there seems to be a DirectWrite kernel component due to CVE-2020-1577 (DirectWrite leaking kernel memory "by convincing a user to visit an untrusted webpage", which I'm not sure whether the exploit route would be in TTF/OTF processing, e.g. due to webfonts, or the text rendering itself).

monocasa 5y ago

NT's VFS cache does a decent enough job at sharing pages to actual data for the same file, even between kernel space and user space; the problems start around FS metadata caching.