New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 9 users

Issue metadata

Status: Verified
Last visit > 30 days ago
Closed: Jul 2018
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Feature

Blocked on:
issue 440500

issue 659765

Sign in to add a comment

Issue 584575: Support Control Flow Guard (CFG) in Chromium

Reported by, Feb 5 2016

Issue description


Since Windows 10, Windows 8.1 Update 3 and the soon to be released Windows Server 2016, Microsoft has built-in full support for Control Flow Guard (CFG) protection.
In case you're not familiar with CFG yet, simply said CFG will help in protecting processes from exploits overwriting memory locations and redirecting this to malicious code. For example in the case of use-after-free vulnerabilities.
The way CFG protects this is by analyzing the control flow of all indirect calls during compile time of the executable/DLL. It will then insert extra runtime checks to protect against attackers trying to target other memory locations.

I've verified the latest Chrome beta "49.0.2623.39" (64-bit) on a Windows 10 64-bit (up-to-date) install and found that these are not yet compiled with CFG support.
This is not a direct security vulnerability, but supporting CFG would greatly reduce the chance of creating a successful exploit against Chrome and thus preventing a system compromise.
So this would be an extra defense-in-depth measure.
Adding CFG support is possible if Chrome is compiled with Visual Studio 2015 using the additional "/guard:cf" flag (see and
Binaries compiled with CFG support will continue to function on older Windows operating systems, just without CFG being enabled, same as would be the case with ASLR.

For your information, I've verified Chrome using the "dumpbin.exe" included with Visual Studio 2015 and using the latest version of "Process Hacker" which also supports showing ASLR/CFG flags on processes and used DLLs.

An easy check is doing this on the chrome.exe file and look for the string "Guard":

dumpbin.exe /headers /loadconfig chrome.exe | findstr "Guard"

Is Control Flow Guard something that you've already considered to implement? If not, do you think it's possible to add this feature, to give an extra defense layer of security?

Kind Regards,

Robert van Hamburg

Comment 1 by, Feb 5 2016

Sending to wfh who is willing to take a look at this, thanks for the report.

Comment 2 by, Feb 5 2016

Blockedon: chromium:440500
Labels: -Restrict-View-SecurityTeam -Type-Bug-Security Build-Toolchain Cr-Security OS-Windows
Owner: ----
Status: Available
Summary: Support Control Flow Guard (CFG) in Chromium (was: Security: Google Chrome Control Flow Guard (CFG) support on Windows 8.1 u3 / Windows 10)
Thanks for your bug.

We have already evaluated the use of CFG in Chromium but this is currently dependent on upgrading our entire build environment to VS2015 which is covered by  issue 440500 .

We started work on this in 2014 but this is almost complete (over a year later!) so we will certainly be looking at CFG once we know this new toolchain is stable.

Comment 3 by, Feb 11 2016

Good to hear you guys have been evaluating the use of CFG for Chromium already and good to hear the transition to VS2015 will soon be realised!

Could you please keep me updated through this ticket when further steps are taken?

Thanks and keep up the good work guys! :)

Comment 4 by, Apr 14 2016

Labels: Pri-2 Type-Feature

Comment 5 by, Apr 14 2016

* CFG is similar (but weaker) to LLVM's CFI which we are trying to enable on Linux, see  bug 464797 
* Protecting virtual calls in Blink may be very expensive due to extremely frequent use of tiny virtual functions such as e.g.  LayoutObject::isOfType. 
In LLVM we solve this by implementing virtual constant propagation, 
and I am not sure if VC++ has a similar optimization.
See  bug 580389  (#c15) for details
I suggest to start evaluating the performance from e.g. layout_tests.layers_overlap_3d

Comment 6 by, Apr 22 2016

Visual Studio will at the very least try to optimize out unneeded CFG checks.
I'm not sure if this has any implications for the types of virtual calls that
have been talked about here.

It may also be worth noting that you can easily combine CFG and non-CFG compiled
code as it will link fine (but obviously only the code compiled with /guard:cf
will have the protection).

The implication of this is that you should be able to turn on CFG for the main
Chrome executable yet only enable it for certain things (e.g. Flash) since there
appears to be a concern about the performance impact.  At least Flash seems like
the most logical place to start, sure CFG isn't perfect but maybe it can raise
the bar a little.  As long as there aren't concerns about the performance impact
for modules like Flash or the PDF reader perhaps enabling CFG for these while
investigating using it globally?

Comment 7 by, May 17 2016

Status: Assigned (was: Available)

Comment 8 by, Jul 5 2016

Well since there hasn't been an update on this for a little while now perhaps doing a phased rollout of CFG might speed things up since there are performance implications to consider.  I don't know if there are other plans for this or not, just seeing what's going on.

I was thinking something like:

Phase 1:
Main Chrome executable only (along with appropriate linker flags for said executable).  This should have a negligible performance impact since most of the "meat" isn't actually being instrumented.  This would however allow Chrome to pick up on the CF instrumentation in all of the linked Microsoft dll's (basically anything Chrome links to that's in system32 is going to have CFG instrumentation.  So that's some coverage with basically zero effort and zero performance impact.  The CFG info isn't used unless it's actually enabled for the main process.

Phase 2:
Expand coverage to low hanging fruit like plugins.  e.g. Flash, widevine, pdf, etc.  Could also be combined with the following "phase" (or previous) but I think there are less performance considerations(?) with these.

Phase 3:
Full CFG coverage or as full as can reasonably be done taking performance into consideration.  I believe CFG can be controlled on a per-source-file basis if that level of granularity is necessary.  CFG and non-CFG instrumented code can be combined and will link fine (just one won't be protected).

Phase 4:
Investigate using CFG for JITed code[1].  Edge (IE too?) does this for its JIT.

Anyway, I have no idea if there are other plans (internal or otherwise) but just seeing if some actual progress could be made with this (or to at least get an update).  Also Microsoft may be expanding what CFG covers in the upcoming W10 Anniversary Update (or maybe not)[2].

[1] (interesting bits on pages 17-20)
[2] (it's somewhere on there... probably)

Comment 9 by, Oct 14 2016

Project Member
The following revision refers to this bug:

commit d46842301ebc1f41a92448026bf95e3194538213
Author: pennymac <>
Date: Fri Oct 14 01:14:33 2016

[Windows MSVC CFG] Add support for CFG, and enable on chrome.exe & chrome_elf.dll.

CFG supported on x86 and x64 >= Windows 8.1 Update (KB3000850).

Initial support for Control Flow Guard.  "Enable" on chrome.exe to take
advantage of MS system32 dll CFG.  Also compile and link chrome_elf with CFG.

NOTE: As ASLR is disabled in debug builds, so too is CFG.

Using the dumpbin tool from the Visual Studio command prompt, run "dumpbin /headers /loadconfig" against chrome.exe or chrome_elf.dll.  1) "DLL characteristics" now includes "Control Flow Guard", and 2) if code was compiled with cfg there will be "load config" for "Guard CF" function table and flags.

BUG= 584575

Cr-Commit-Position: refs/heads/master@{#425226}


Comment 10 by, Oct 17 2016

Status: Started (was: Assigned)
Note: This first CL started going out to canary in 56.0.2891.0, on 15 Oct 2016.

Comment 11 by, Oct 17 2016

Do you have any numbers on performance/code size/memory usage?

Comment 12 by, Oct 31 2016

seems to be a *slight* uptick in STATUS_STACK_BUFFER_OVERRUN exit codes since first M56 Dev (56.0.2896.3) -

might be more visible split by version and aggregated over multiple days: if you squint the right way.

Comment 13 by, Dec 20 2016

Blocking: 659765

Comment 14 by, Feb 14 2017

Project Member
The following revision refers to this bug:

commit 8c67aad851ba03a83144557abfb2d4b3d182095e
Author: pennymac <>
Date: Tue Feb 14 22:45:28 2017

[Windows CFG Test] Added unittest for CFG enabling on process.

Test ensures our build system enables CFG for a process when asked.
Ensures that an MS system DLL in the process space is protected, even if
none of Chromium code is compiled with CFG.

TEST=New test CFGSupportTests.MsIndirectFailure in sbox_integration_tests suite.

BUG= 584575

Cr-Commit-Position: refs/heads/master@{#450498}


Comment 15 by, Feb 16 2017

Project Member
The following revision refers to this bug:

commit f160102d25fb949a3ed24478268b8835cc086477
Author: pennymac <>
Date: Thu Feb 16 22:21:15 2017

[Windows MSVC CFG] Turning on linker CFG for all.  Disabling CFG compile.

This enables support for CFG that is already compiled into Microsoft
system DLLs - in any of our processes.

Also disabling compilation of CFG with MSVC compiler.  Preparing for
clang CFI instead.

TEST=CFGSupportTests.MsIndirectFailure in sbox_integration_tests suite.
BUG= 584575
TBR=thestig or jochen (chrome\

Cr-Commit-Position: refs/heads/master@{#451116}


Comment 16 by, Apr 13 2017

Project Member
The following revision refers to this bug:

commit 723503ec2956cc8b66e53a5ee97985ec262a599d
Author: pennymac <>
Date: Thu Apr 13 18:23:10 2017

[Windows MSVC CFG]  Link with CFG only on executables.

Adjust GN configs to only link with Control Flow Guard for executables.
This will still support CFG compiled into Microsoft system DLLs, in all
Chromium processes (e.g. chrome.exe).

This should prevent sporadic official clang build problems in DLLs, related
to CFG.  Further investigation/fixes to follow.

TEST=CFGSupportTests.MsIndirectFailure in sbox_integration_tests suite.
BUG= 584575 ,708098

Cr-Commit-Position: refs/heads/master@{#464475}


Comment 17 by, Jul 23 2018

Status: Verified (was: Started)
I'm shutting down this ticket now - as it's focused on CFG on Windows.  We've gone as far as currently planned, to support CFG compiled into system DLLs in our processes.

Any further CFI support on Windows (clang toolchain) should be tracked in new, specific tickets.

Ref also: crbug/659765

Sign in to add a comment