[Chrome ELF] Early browser security support.

[Chrome ELF] Early browser security support.

This CL is part of a chain of CLs:
1) "MITIGATION_EXTENSION_POINT_DISABLE support for children" (https://codereview.chromium.org/1835003003)
2) "MITIGATION_EXTENSION_POINT_DISABLE emergency off finch" (https://codereview.chromium.org/1836523004/)
3) "New NT registry API" (https://codereview.chromium.org/1841573002)
-> THIS
5) "Turn on MITIGATION_EXTENSION_POINT_DISABLE" (https://codereview.chromium.org/1854323002)

Adjusted chrome_elf on Windows to disable extension points (early) in
the browser process.  Supported on >= Win8.  Added a small test as well.

Note: this CL does not "turn on" the mitigation.  That will happen in the small, last CL (easy to revert if necessary).

Tests:
1) chrome_elf_unittests, chrome_elf_util_unittest.cc: ChromeElfUtilTest.BrowserProcessSecurityTest*.

BUG=557798
Committed: https://crrev.com/4e0b5f2a52d54bb39d85e9f9f9ca26ce7dd27975
Cr-Commit-Position: refs/heads/master@{#406337}

[penny, 2016-01-29 23:19:34]

Description was changed from

==========
[Block legacy hooking in Win browser] Disabling extension DLLs in browser.

Adjusted chrome_elf on Windows to disable extension points (early) in
the browser process.  Supported on >= Win8.  Added a small test as well.

BUG=557798
==========

to

==========
[Block legacy hooking in Win browser] Disabling extension DLLs in browser.

Adjusted chrome_elf on Windows to disable extension points (early) in
the browser process.  Supported on >= Win8.  Added a small test as well.

BUG=557798
==========

[penny, 2016-01-29 23:19:34]

pennymac@chromium.org changed reviewers:
+ robertshield@chromium.org

[penny, 2016-01-29 23:35:24]

Hi Robert,

Do you have thoughts on whether I should make DllMain fail if a (very
unexpected) failure happens when adjusting security?  For now, if we somehow
fail to get the function pointer we need, or the call to set the mitigation
fails, I'm just silently failing (dll load still continues).  And I'm ok with
that for now (given how small a change this is, and that failure is completely
unexpected).

Any feedback on the CL would be appreciated - thanks for your time!

[penny, 2016-01-29 23:51:05]

Oh, I'm also interested to know if people think it's worth adding the finch
experiment in the elf.  (Given the complexity and restart mentioned in comments
here: https://codereview.chromium.org/1452393002/.)

[Will Harris, 2016-01-30 01:19:04]

wfh@chromium.org changed reviewers:
+ wfh@chromium.org

[Will Harris, 2016-01-30 01:19:05]

drive by!!!

On 2016/01/29 23:51:05, penny wrote:
> Oh, I'm also interested to know if people think it's worth adding the finch
> experiment in the elf.  (Given the complexity and restart mentioned in
comments
> here: https://codereview.chromium.org/1452393002/.)

finching this early is a real pain....

https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util.cc
File chrome_elf/chrome_elf_util.cc (right):

https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util....
chrome_elf/chrome_elf_util.cc:230: 
nit: remove line

https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util....
chrome_elf/chrome_elf_util.cc:231: if (::IsWindows8OrGreater()) {
What does this function pull in? we would normally use base::win::Version even
though MS says not to. Any particular reason to use this instead?

https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util....
chrome_elf/chrome_elf_util.cc:243: }
my vote would be a DCHECK here, this would trip the bots.  Maybe a CHECK...?

https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util.h
File chrome_elf/chrome_elf_util.h (right):

https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util....
chrome_elf/chrome_elf_util.h:8: #include <Windows.h>
chromium convention is not to capitalize even though the files themselves have
capitals

also, these includes should be in the .cc files (implementation and test), not
the .h file as they are not used here.

[jschuh, 2016-02-01 20:28:07]

jschuh@chromium.org changed reviewers:
+ jschuh@chromium.org

[jschuh, 2016-02-01 20:28:07]

https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util.cc
File chrome_elf/chrome_elf_util.cc (right):

https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util....
chrome_elf/chrome_elf_util.cc:231: if (::IsWindows8OrGreater()) {
On 2016/01/30 01:19:05, Will Harris wrote:
> What does this function pull in? we would normally use base::win::Version even
> though MS says not to. Any particular reason to use this instead?

ELF doesn't depend on base. So, this is an easy way to version check without
depending on anything outside of kernel32. IIRC, it's implemented almost
entirely with macros in the header.

https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util....
chrome_elf/chrome_elf_util.cc:243: }
On 2016/01/30 01:19:05, Will Harris wrote:
> my vote would be a DCHECK here, this would trip the bots.  Maybe a CHECK...?

I don't think you can introduce that dependency either, but a DebugBreak() might
work.

[grt (UTC plus 2), 2016-02-01 20:43:06]

just passing through...

https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util.cc
File chrome_elf/chrome_elf_util.cc (right):

https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util....
chrome_elf/chrome_elf_util.cc:243: }
On 2016/02/01 20:28:07, jschuh (very slow) wrote:
> On 2016/01/30 01:19:05, Will Harris wrote:
> > my vote would be a DCHECK here, this would trip the bots.  Maybe a CHECK...?
> 
> I don't think you can introduce that dependency either, but a DebugBreak()
might
> work.

nit: prefer the __debugbreak() compiler intrinsic
(https://msdn.microsoft.com/en-us/library/f408b4et.aspx) over the function call,
IMO.

[penny, 2016-02-01 21:31:52]

Thanks for the comments and "drive by" reviews!  A few changes uploaded.

https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util.cc
File chrome_elf/chrome_elf_util.cc (right):

https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util....
chrome_elf/chrome_elf_util.cc:230: 
On 2016/01/30 01:19:05, Will Harris wrote:
> nit: remove line

Done.

https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util....
chrome_elf/chrome_elf_util.cc:231: if (::IsWindows8OrGreater()) {
On 2016/02/01 20:28:07, jschuh (very slow) wrote:
> On 2016/01/30 01:19:05, Will Harris wrote:
> > What does this function pull in? we would normally use base::win::Version
even
> > though MS says not to. Any particular reason to use this instead?
> 
> ELF doesn't depend on base. So, this is an easy way to version check without
> depending on anything outside of kernel32. IIRC, it's implemented almost
> entirely with macros in the header.

Yes indeed.  I like these APIs.  Supported back to Win2k.  They're in kernel32,
are mostly macros, don't pull anything in, and are safe for using with loader
lock.  Since I don't have base in chrome_elf, went this route to keep the code
clean and simple.

https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util....
chrome_elf/chrome_elf_util.cc:243: }
On 2016/02/01 20:43:06, grt wrote:
> On 2016/02/01 20:28:07, jschuh (very slow) wrote:
> > On 2016/01/30 01:19:05, Will Harris wrote:
> > > my vote would be a DCHECK here, this would trip the bots.  Maybe a
CHECK...?
> > 
> > I don't think you can introduce that dependency either, but a DebugBreak()
> might
> > work.
> 
> nit: prefer the __debugbreak() compiler intrinsic
> (https://msdn.microsoft.com/en-us/library/f408b4et.aspx) over the function
call,
> IMO.

Done.  I'm in the habit of using the intrinsic as well - added if the call to
set mitigation happens to fail.

**Are we ok with having a __debugbreak() - essentially an int 3 - inside
DllMain?  And in both debug and release?  Or only debug?

https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util.h
File chrome_elf/chrome_elf_util.h (right):

https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util....
chrome_elf/chrome_elf_util.h:8: #include <Windows.h>
On 2016/01/30 01:19:05, Will Harris wrote:
> chromium convention is not to capitalize even though the files themselves have
> capitals
> 
> also, these includes should be in the .cc files (implementation and test), not
> the .h file as they are not used here.

Done.

[robertshield, 2016-02-01 22:40:50]

https://codereview.chromium.org/1656453002/diff/20001/chrome_elf/chrome_elf_u...
File chrome_elf/chrome_elf_util.cc (right):

https://codereview.chromium.org/1656453002/diff/20001/chrome_elf/chrome_elf_u...
chrome_elf/chrome_elf_util.cc:243: &policy, sizeof(policy)))
It would be nice to UMA this. 

Two ways come to mind - expose it to Chrome startup a la blacklist
(https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/chr...)
or run the check you have in the unit test for whether the mitigation policy is
enabled sometime during Chrome startup.

What do you think?

[grt (UTC plus 2), 2016-02-02 01:12:29]

https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util.cc
File chrome_elf/chrome_elf_util.cc (right):

https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util....
chrome_elf/chrome_elf_util.cc:243: }
On 2016/02/01 21:31:52, penny wrote:
> On 2016/02/01 20:43:06, grt wrote:
> > On 2016/02/01 20:28:07, jschuh (very slow) wrote:
> > > On 2016/01/30 01:19:05, Will Harris wrote:
> > > > my vote would be a DCHECK here, this would trip the bots.  Maybe a
> CHECK...?
> > > 
> > > I don't think you can introduce that dependency either, but a DebugBreak()
> > might
> > > work.
> > 
> > nit: prefer the __debugbreak() compiler intrinsic
> > (https://msdn.microsoft.com/en-us/library/f408b4et.aspx) over the function
> call,
> > IMO.
> 
> Done.  I'm in the habit of using the intrinsic as well - added if the call to
> set mitigation happens to fail.
> 
> **Are we ok with having a __debugbreak() - essentially an int 3 - inside
> DllMain?  And in both debug and release?  Or only debug?

As a rule of thumb: crash the process in a release build if Chrome should not
run at all in this scenario because it's such a gross security violation. I
haven't grokked this CL, but bear in mind that a crash during startup is
completely incomprehensible and undiagnosable for users. Is Chrome connected to
the crash service at this point?

[Will Harris, 2016-02-02 01:15:16]

On 2016/02/02 01:12:29, grt wrote:
>
https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util.cc
> File chrome_elf/chrome_elf_util.cc (right):
> 
>
https://codereview.chromium.org/1656453002/diff/1/chrome_elf/chrome_elf_util....
> chrome_elf/chrome_elf_util.cc:243: }
> On 2016/02/01 21:31:52, penny wrote:
> > On 2016/02/01 20:43:06, grt wrote:
> > > On 2016/02/01 20:28:07, jschuh (very slow) wrote:
> > > > On 2016/01/30 01:19:05, Will Harris wrote:
> > > > > my vote would be a DCHECK here, this would trip the bots.  Maybe a
> > CHECK...?
> > > > 
> > > > I don't think you can introduce that dependency either, but a
DebugBreak()
> > > might
> > > > work.
> > > 
> > > nit: prefer the __debugbreak() compiler intrinsic
> > > (https://msdn.microsoft.com/en-us/library/f408b4et.aspx) over the function
> > call,
> > > IMO.
> > 
> > Done.  I'm in the habit of using the intrinsic as well - added if the call
to
> > set mitigation happens to fail.
> > 
> > **Are we ok with having a __debugbreak() - essentially an int 3 - inside
> > DllMain?  And in both debug and release?  Or only debug?
> 
> As a rule of thumb: crash the process in a release build if Chrome should not
> run at all in this scenario because it's such a gross security violation. I
> haven't grokked this CL, but bear in mind that a crash during startup is
> completely incomprehensible and undiagnosable for users. Is Chrome connected
to
> the crash service at this point?

I think I'd prefer the code that is currently in IsSecuritySet in the test to
run somewhere as an UMA_HISTOGRAM_BOOLEAN so we get an idea of how often this is
happening.

in fact, it might be worth histograming other mitigations to know how often they
are actually enabled...

I agree that crashing this early with no user interaction is probably a bad idea
for users.

[penny, 2016-02-02 18:43:43]

I've removed the break in case of failure setting the mitigation.  (This is very
unexpected.)

I plan to create a follow-up CL that checks the security settings a bit later on
- adding some new UMA counts if any mitigations failed to be set.

[penny, 2016-04-04 21:18:43]

Description was changed from

==========
[Block legacy hooking in Win browser] Disabling extension DLLs in browser.

Adjusted chrome_elf on Windows to disable extension points (early) in
the browser process.  Supported on >= Win8.  Added a small test as well.

BUG=557798
==========

to

==========
[Chrome ELF] Early browser security support.

This CL is part of a chain of CLs:
1) "MITIGATION_EXTENSION_POINT_DISABLE support for children"
(https://codereview.chromium.org/1835003003)
2) "MITIGATION_EXTENSION_POINT_DISABLE emergency off finch"
(https://codereview.chromium.org/1836523004/)
3) "New NT registry API" (https://codereview.chromium.org/1841573002)
-> THIS
5) "Turn on MITIGATION_EXTENSION_POINT_DISABLE"
(https://codereview.chromium.org/1854323002)

Adjusted chrome_elf on Windows to disable extension points (early) in
the browser process.  Supported on >= Win8.  Added a small test as well.

Tests:
1) chrome_elf_unittests, chrome_elf_util_unittest.cc:
ChromeElfUtilTest.BrowserProcessSecurityTest*.

BUG=557798
==========

[penny, 2016-04-04 21:18:44]

pennymac@chromium.org changed reviewers:
- jschuh@chromium.org, wfh@chromium.org

[penny, 2016-04-06 20:56:59]

Description was changed from

==========
[Chrome ELF] Early browser security support.

This CL is part of a chain of CLs:
1) "MITIGATION_EXTENSION_POINT_DISABLE support for children"
(https://codereview.chromium.org/1835003003)
2) "MITIGATION_EXTENSION_POINT_DISABLE emergency off finch"
(https://codereview.chromium.org/1836523004/)
3) "New NT registry API" (https://codereview.chromium.org/1841573002)
-> THIS
5) "Turn on MITIGATION_EXTENSION_POINT_DISABLE"
(https://codereview.chromium.org/1854323002)

Adjusted chrome_elf on Windows to disable extension points (early) in
the browser process.  Supported on >= Win8.  Added a small test as well.

Tests:
1) chrome_elf_unittests, chrome_elf_util_unittest.cc:
ChromeElfUtilTest.BrowserProcessSecurityTest*.

BUG=557798
==========

to

==========
[Chrome ELF] Early browser security support.

This CL is part of a chain of CLs:
1) "MITIGATION_EXTENSION_POINT_DISABLE support for children"
(https://codereview.chromium.org/1835003003)
2) "MITIGATION_EXTENSION_POINT_DISABLE emergency off finch"
(https://codereview.chromium.org/1836523004/)
3) "New NT registry API" (https://codereview.chromium.org/1841573002)
-> THIS
5) "Turn on MITIGATION_EXTENSION_POINT_DISABLE"
(https://codereview.chromium.org/1854323002)

Adjusted chrome_elf on Windows to disable extension points (early) in
the browser process.  Supported on >= Win8.  Added a small test as well.

Note: this CL does not "turn on" the mitigation.  That will happen in the small,
last CL (easy to revert if necessary).

Tests:
1) chrome_elf_unittests, chrome_elf_util_unittest.cc:
ChromeElfUtilTest.BrowserProcessSecurityTest*.

BUG=557798
==========

[penny, 2016-04-12 18:05:38]

Hi Robert,

This CL (and summary) has been updated to be the fourth CL that will land.  It
only adds the support for early browser security.  It will only be "turned on"
in the fifth/last CL.

There's no try bot run yet, as I'll wait for CL #3 to land first (NT Registry
API), and then update this branch.  Very little overlap, except using the new NT
API in chrome_elf_main.cc.  (Note that I did run tests successfully with this
locally - with all CLs together.)

Many thanks!

[robertshield, 2016-04-12 18:24:57]

Thanks Penny, going over the list of CLs now to understand how they all fit
together.

On Tue, Apr 12, 2016 at 2:05 PM, <pennymac@chromium.org> wrote:

> Hi Robert,
>
> This CL (and summary) has been updated to be the fourth CL that will land.
> It
> only adds the support for early browser security. It will only be "turned
> on"
> in the fifth/last CL.
>
> There's no try bot run yet, as I'll wait for CL #3 to land first (NT
> Registry
> API), and then update this branch. Very little overlap, except using the
> new NT
> API in chrome_elf_main.cc. (Note that I did run tests successfully with
> this
> locally - with all CLs together.)
>
> Many thanks!
>
> https://codereview.chromium.org/1656453002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[robertshield, 2016-04-12 20:53:12]

lg, some nits

https://codereview.chromium.org/1656453002/diff/60001/chrome_elf/chrome_elf_u...
File chrome_elf/chrome_elf_util.cc (right):

https://codereview.chromium.org/1656453002/diff/60001/chrome_elf/chrome_elf_u...
chrome_elf/chrome_elf_util.cc:227: typedef decltype(SetProcessMitigationPolicy)*
SetProcessMitigationPolicyFunc;
Any reason not to keep this typedef inside the scope of the EarlyBrowserSecurity
function?

https://codereview.chromium.org/1656453002/diff/60001/chrome_elf/chrome_elf_u...
chrome_elf/chrome_elf_util.cc:232: NTSTATUS ret_val;
initialize to STATUS_SUCCESS

https://codereview.chromium.org/1656453002/diff/60001/chrome_elf/chrome_elf_u...
chrome_elf/chrome_elf_util.cc:233: HANDLE handle;
initialize this to NULL

https://codereview.chromium.org/1656453002/diff/60001/chrome_elf/chrome_elf_u...
File chrome_elf/chrome_elf_util_unittest.cc (right):

https://codereview.chromium.org/1656453002/diff/60001/chrome_elf/chrome_elf_u...
chrome_elf/chrome_elf_util_unittest.cc:59: typedef
decltype(GetProcessMitigationPolicy)* GetProcessMitigationPolicyFunc;
same question about moving this into the function scope below

[penny, 2016-04-15 18:03:51]

Thanks Robert!  Fixes uploaded.

It's just habit for me to put Function defs outside of functions.  I don't mind
putting them inside scope here.

https://codereview.chromium.org/1656453002/diff/60001/chrome_elf/chrome_elf_u...
File chrome_elf/chrome_elf_util.cc (right):

https://codereview.chromium.org/1656453002/diff/60001/chrome_elf/chrome_elf_u...
chrome_elf/chrome_elf_util.cc:227: typedef decltype(SetProcessMitigationPolicy)*
SetProcessMitigationPolicyFunc;
On 2016/04/12 20:53:12, robertshield wrote:
> Any reason not to keep this typedef inside the scope of the
EarlyBrowserSecurity
> function?

Done.

https://codereview.chromium.org/1656453002/diff/60001/chrome_elf/chrome_elf_u...
chrome_elf/chrome_elf_util.cc:232: NTSTATUS ret_val;
On 2016/04/12 20:53:12, robertshield wrote:
> initialize to STATUS_SUCCESS

Done.

https://codereview.chromium.org/1656453002/diff/60001/chrome_elf/chrome_elf_u...
chrome_elf/chrome_elf_util.cc:233: HANDLE handle;
On 2016/04/12 20:53:12, robertshield wrote:
> initialize this to NULL

Done.

https://codereview.chromium.org/1656453002/diff/60001/chrome_elf/chrome_elf_u...
File chrome_elf/chrome_elf_util_unittest.cc (right):

https://codereview.chromium.org/1656453002/diff/60001/chrome_elf/chrome_elf_u...
chrome_elf/chrome_elf_util_unittest.cc:59: typedef
decltype(GetProcessMitigationPolicy)* GetProcessMitigationPolicyFunc;
On 2016/04/12 20:53:12, robertshield wrote:
> same question about moving this into the function scope below

Done.

[robertshield, 2016-04-18 15:01:04]

lgtm

[penny, 2016-07-18 22:14:29]

The CQ bit was checked by pennymac@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-18 22:15:09]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-18 22:25:02]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-18 22:25:03]

Dry run: Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)
  win_clang on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/...)

[penny, 2016-07-18 22:53:24]

The CQ bit was checked by pennymac@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-18 22:54:08]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-19 00:56:29]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-19 00:56:30]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[penny, 2016-07-19 17:34:52]

The CQ bit was checked by pennymac@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-19 17:35:21]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-19 18:26:07]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-19 18:26:09]

Dry run: This issue passed the CQ dry run.

[penny, 2016-07-19 18:42:49]

The CQ bit was checked by pennymac@chromium.org

[penny, 2016-07-19 18:42:50]

The patchset sent to the CQ was uploaded after l-g-t-m from
robertshield@chromium.org
Link to the patchset: https://codereview.chromium.org/1656453002/#ps140001
(title: "Only run the new browser security test on >= Win8.")

[commit-bot: I haz the power, 2016-07-19 18:43:35]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-19 19:15:57]

Description was changed from

==========
[Chrome ELF] Early browser security support.

This CL is part of a chain of CLs:
1) "MITIGATION_EXTENSION_POINT_DISABLE support for children"
(https://codereview.chromium.org/1835003003)
2) "MITIGATION_EXTENSION_POINT_DISABLE emergency off finch"
(https://codereview.chromium.org/1836523004/)
3) "New NT registry API" (https://codereview.chromium.org/1841573002)
-> THIS
5) "Turn on MITIGATION_EXTENSION_POINT_DISABLE"
(https://codereview.chromium.org/1854323002)

Adjusted chrome_elf on Windows to disable extension points (early) in
the browser process.  Supported on >= Win8.  Added a small test as well.

Note: this CL does not "turn on" the mitigation.  That will happen in the small,
last CL (easy to revert if necessary).

Tests:
1) chrome_elf_unittests, chrome_elf_util_unittest.cc:
ChromeElfUtilTest.BrowserProcessSecurityTest*.

BUG=557798
==========

to

==========
[Chrome ELF] Early browser security support.

This CL is part of a chain of CLs:
1) "MITIGATION_EXTENSION_POINT_DISABLE support for children"
(https://codereview.chromium.org/1835003003)
2) "MITIGATION_EXTENSION_POINT_DISABLE emergency off finch"
(https://codereview.chromium.org/1836523004/)
3) "New NT registry API" (https://codereview.chromium.org/1841573002)
-> THIS
5) "Turn on MITIGATION_EXTENSION_POINT_DISABLE"
(https://codereview.chromium.org/1854323002)

Adjusted chrome_elf on Windows to disable extension points (early) in
the browser process.  Supported on >= Win8.  Added a small test as well.

Note: this CL does not "turn on" the mitigation.  That will happen in the small,
last CL (easy to revert if necessary).

Tests:
1) chrome_elf_unittests, chrome_elf_util_unittest.cc:
ChromeElfUtilTest.BrowserProcessSecurityTest*.

BUG=557798
==========

[commit-bot: I haz the power, 2016-07-19 19:15:59]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2016-07-19 19:16:31]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-07-19 19:17:51]

Description was changed from

==========
[Chrome ELF] Early browser security support.

This CL is part of a chain of CLs:
1) "MITIGATION_EXTENSION_POINT_DISABLE support for children"
(https://codereview.chromium.org/1835003003)
2) "MITIGATION_EXTENSION_POINT_DISABLE emergency off finch"
(https://codereview.chromium.org/1836523004/)
3) "New NT registry API" (https://codereview.chromium.org/1841573002)
-> THIS
5) "Turn on MITIGATION_EXTENSION_POINT_DISABLE"
(https://codereview.chromium.org/1854323002)

Adjusted chrome_elf on Windows to disable extension points (early) in
the browser process.  Supported on >= Win8.  Added a small test as well.

Note: this CL does not "turn on" the mitigation.  That will happen in the small,
last CL (easy to revert if necessary).

Tests:
1) chrome_elf_unittests, chrome_elf_util_unittest.cc:
ChromeElfUtilTest.BrowserProcessSecurityTest*.

BUG=557798
==========

to

==========
[Chrome ELF] Early browser security support.

This CL is part of a chain of CLs:
1) "MITIGATION_EXTENSION_POINT_DISABLE support for children"
(https://codereview.chromium.org/1835003003)
2) "MITIGATION_EXTENSION_POINT_DISABLE emergency off finch"
(https://codereview.chromium.org/1836523004/)
3) "New NT registry API" (https://codereview.chromium.org/1841573002)
-> THIS
5) "Turn on MITIGATION_EXTENSION_POINT_DISABLE"
(https://codereview.chromium.org/1854323002)

Adjusted chrome_elf on Windows to disable extension points (early) in
the browser process.  Supported on >= Win8.  Added a small test as well.

Note: this CL does not "turn on" the mitigation.  That will happen in the small,
last CL (easy to revert if necessary).

Tests:
1) chrome_elf_unittests, chrome_elf_util_unittest.cc:
ChromeElfUtilTest.BrowserProcessSecurityTest*.

BUG=557798

Committed: https://crrev.com/4e0b5f2a52d54bb39d85e9f9f9ca26ce7dd27975
Cr-Commit-Position: refs/heads/master@{#406337}
==========

[commit-bot: I haz the power, 2016-07-19 19:17:53]

Patchset 8 (id:??) landed as
https://crrev.com/4e0b5f2a52d54bb39d85e9f9f9ca26ce7dd27975
Cr-Commit-Position: refs/heads/master@{#406337}