| commit | edceb83dee56669c270f32596ed9e9546b0e5f07 | |
| author | ananta <ananta@chromium.org> | |
| Thu, 23 Oct 2014 12:53:12 +0000 (23 05:53 -0700) | ||
| committer | Commit bot <commit-bot@chromium.org> | |
| Thu, 23 Oct 2014 12:53:30 +0000 (23 12:53 +0000) | ||
| tree | e94d327ad2647b54f866986c19436c462d557f73 | treesnapshot (tar.gz zip) |
| parent | e0648c9b77db1432c5523ea6118e2c94e17d3096 | commitdiff |
Prepare to enable win32K lockdown mode by default for renderer processes on Windows 8+
Win32K lockdown mode is currently enabled by a browser side command line switch "enable_win32k_lockdown_mode". Regular renderers and extension processes work well
in the win32k lockdown mode on Windows 8+. The pepper PDF plugin crashes because of
the following:-
1. Uses GDI for text rendering.
2. It uses image data functionality which eventually ends up creating DIB sections
which fail in the win32k lockdown mode.
We already have work underway to run the PDF plugin out of process. This works
nicely for us as these processes run as pepper processes and thus don't have the lockdown mode enabled.
Changes in this patch are as below:-
1. Propagate the --enable_win32k_lockdown_mode command line switch to renderer
processes. This is to enable them to check if they are running in lockdown mode.
There is a Windows API to query this. However the switch alleviates the need for
that.
2. If the renderer is in win32k lockdown mode, we always use the SIMPLE image data
type which creates a SkCanvas backed by memory rather than actual DIB sections.
This works well in my testing. I added TODO's in the relevant places to
investigate if there is a loss of functionality here.
3. If the --enable_win32k_lockdown_mode switch is specified in the browser we force
PDF plugins to run out of process with the --out-of-process-pdf command line
switch. This works well in most cases with subtle bugs like pdfs in iframes, not
working. This bug is being worked on at the moment.
Once the PDF out of process feature is complete we can enable the win32k lockdown
mode by default on Windows 8+.
BUG=365160
Review URL: https://codereview.chromium.org/669623005
Cr-Commit-Position: refs/heads/master@{#300875}
Win32K lockdown mode is currently enabled by a browser side command line switch "enable_win32k_lockdown_mode". Regular renderers and extension processes work well
in the win32k lockdown mode on Windows 8+. The pepper PDF plugin crashes because of
the following:-
1. Uses GDI for text rendering.
2. It uses image data functionality which eventually ends up creating DIB sections
which fail in the win32k lockdown mode.
We already have work underway to run the PDF plugin out of process. This works
nicely for us as these processes run as pepper processes and thus don't have the lockdown mode enabled.
Changes in this patch are as below:-
1. Propagate the --enable_win32k_lockdown_mode command line switch to renderer
processes. This is to enable them to check if they are running in lockdown mode.
There is a Windows API to query this. However the switch alleviates the need for
that.
2. If the renderer is in win32k lockdown mode, we always use the SIMPLE image data
type which creates a SkCanvas backed by memory rather than actual DIB sections.
This works well in my testing. I added TODO's in the relevant places to
investigate if there is a loss of functionality here.
3. If the --enable_win32k_lockdown_mode switch is specified in the browser we force
PDF plugins to run out of process with the --out-of-process-pdf command line
switch. This works well in most cases with subtle bugs like pdfs in iframes, not
working. This bug is being worked on at the moment.
Once the PDF out of process feature is complete we can enable the win32k lockdown
mode by default on Windows 8+.
BUG=365160
Review URL: https://codereview.chromium.org/669623005
Cr-Commit-Position: refs/heads/master@{#300875}