Sometimes I like to think that I know how computers work, and then I read something written by someone who actually does and I’m humbled most completely.
A lot of this complexity seems down to the way Windows works, though. As a Linux user, the amount of somewhat confusing/crufty stuff going on in a typical Windows install boggles the mind; it’s almost as bad as Emacs.
I guess to me it doesn’t feel like there’s much Windows specific complexity here, just a generally complex issue; a bug in v8’s sandboxed runtime and how it interacts with low-level OS-provided virtual memory protection and specific lock contention behavior, which only expressed itself by happenstance for the OP.
Some of this stuff just feels like irreducible complexity, though my lack of familiarity with Windowsisms (function naming style, non-fair locks, etc.) probably doesn’t help there.
CFG is MS’s Control Flow Guard, it’s a combination of compile-time instrumentation from MSVC and runtime integration with the OS. CFI on Linux (via clang/LLVM), in contrast, is entirely compile time AFAIK, with basically no runtime support.
Yes and no. :) The linux CFI implementation doesn’t include the jit protection feature in CFG that’s implicated in the bug, so I’m not sure it’s fair to characterize this as “cruft”.
llvm’s implementation of CFI does have the beginnings of a runtime support library (libclang_rt.cfi). HardenedBSD is working on integrating Cross-DSO CFI from llvm, which is what uses the support library.
Here’s a funny thought in terms of performance: don’t get attached to apps. I recently compared mail apps on mac. I’ve ran Thunderbird, Apple Mail and Outlook, and surprisingly the first two were really inadequate with large inboxes (gigabytes, 50K+ messages). Outlook crunches them without a problem. Oh and Thunderbird just hangs up when you try to use unified inbox with large accounts - you can’t even start it after the crash, you need to remove the data files in the Finder. (The same happens on Linux…)
PS. Having a gmail tab opened for 8 days is thrilling. Also, it may be a good idea to remove yourself from Google services ;)
Sometimes I like to think that I know how computers work, and then I read something written by someone who actually does and I’m humbled most completely.
A lot of this complexity seems down to the way Windows works, though. As a Linux user, the amount of somewhat confusing/crufty stuff going on in a typical Windows install boggles the mind; it’s almost as bad as Emacs.
I guess to me it doesn’t feel like there’s much Windows specific complexity here, just a generally complex issue; a bug in v8’s sandboxed runtime and how it interacts with low-level OS-provided virtual memory protection and specific lock contention behavior, which only expressed itself by happenstance for the OP.
Some of this stuff just feels like irreducible complexity, though my lack of familiarity with Windowsisms (function naming style, non-fair locks, etc.) probably doesn’t help there.
How does CFG work with chrome on linux?
Do you mean CFI?
CFG is MS’s Control Flow Guard, it’s a combination of compile-time instrumentation from MSVC and runtime integration with the OS. CFI on Linux (via clang/LLVM), in contrast, is entirely compile time AFAIK, with basically no runtime support.
See:
for more details on the differences.
Yes and no. :) The linux CFI implementation doesn’t include the jit protection feature in CFG that’s implicated in the bug, so I’m not sure it’s fair to characterize this as “cruft”.
The CFI implementation in llvm isn’t a “linux CFI implementation.” :)
As OpenBSD moves towards llvm on all architectures, it can take advantage of CFI, just as HardenedBSD already does. :)
llvm’s implementation of CFI does have the beginnings of a runtime support library (
libclang_rt.cfi). HardenedBSD is working on integrating Cross-DSO CFI from llvm, which is what uses the support library.Linux just hasit’s own weirdnesses in other places.
That said, memory management seems to be a source of strange behaviour regardless of OS.
I found it a great read as well and his blog has more. Thank you for submitting this.
Here’s a funny thought in terms of performance: don’t get attached to apps. I recently compared mail apps on mac. I’ve ran Thunderbird, Apple Mail and Outlook, and surprisingly the first two were really inadequate with large inboxes (gigabytes, 50K+ messages). Outlook crunches them without a problem. Oh and Thunderbird just hangs up when you try to use unified inbox with large accounts - you can’t even start it after the crash, you need to remove the data files in the Finder. (The same happens on Linux…) PS. Having a gmail tab opened for 8 days is thrilling. Also, it may be a good idea to remove yourself from Google services ;)
The author works at Google.
Then he would be a pioneer.
PSA: The gmail HTML interface still exists and works fine. Even in your favorite text browser like links+ (links2 in some package managers).
Layer after layer of hacks.