Open Bug 1381019 (win32k-lockdown) Opened 7 years ago Updated 4 months ago

[meta] Remove win32k access from content process

Categories

(Core :: Security: Process Sandboxing, enhancement, P2)

All
Windows
enhancement

Tracking

()

REOPENED

People

(Reporter: Alex_Gaynor, Assigned: cmartin)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

(4 keywords, Whiteboard: sb+)

Attachments

(2 obsolete files)

This is a meta bug for work towards removing win32k usage from the content process, and using the windows8+ mitigation policy to disable access to it.

This work is currently in the research/scoping phase - it is known that we make use of win32k APIs in the content process and we need to establish where and come up with a plan for dealing with all of them.
Depends on: 1381022
Depends on: 1362220
Depends on: 1381938
Depends on: 1382232
See Also: → 1382251
Depends on: 1382326
Depends on: 1382333
Keywords: meta
Whiteboard: sb+
Depends on: 1382795
Depends on: 1383083
Depends on: 1383522
Depends on: 1383524
No longer depends on: 1382795
Depends on: win32k-plugin
No longer depends on: 1362220
Blocks: sb-audio
Depends on: 1395238
Depends on: win32k-webrtc
Depends on: 1395315
Depends on: 1400317
Depends on: 1400344
Alias: win32k-lockdown
Depends on: 1402922
Priority: -- → P3
Depends on: 1394163
Depends on: 1407992
Depends on: 1403302
Assignee: nobody → jmathies
Priority: P3 → P2
Depends on: webrender
Depends on: linux-nnt
No longer depends on: linux-nnt
Depends on: canvas-ipc
Depends on: webgl-ipc-refactor
Depends on: 1533097
Depends on: 1533100
No longer depends on: 1383522
Depends on: 1539577
No longer depends on: 1539577
Depends on: 1539841
Depends on: 1541029
No longer depends on: 1541029
No longer depends on: 1400317
Depends on: 1400317
Depends on: 1652561
Depends on: 1657041
Depends on: sb-temp
No longer depends on: 1696387
Depends on: segmenter
No longer depends on: 1696940
No longer depends on: sb-temp
No longer depends on: 1539841
Depends on: 1697865
Depends on: 1698942
Depends on: 1698944
Depends on: 1698946
Depends on: 1698947
Depends on: 1698951
Depends on: 1698954
No longer depends on: 1698946
No longer depends on: 1698947
Depends on: 1698732
Depends on: 1700523
Depends on: 1701788
Depends on: 1701791
Depends on: 1701794
Depends on: 1701796
Depends on: 1701802
Depends on: 1709383
Depends on: 1711545
Depends on: 1711551
Depends on: 1711553
Assignee: jmathies → nobody
Depends on: 1721850
Depends on: 1722073
No longer depends on: 1657041
Depends on: 1736605
Depends on: 1740362
Assignee: nobody → gpascutto
Status: NEW → ASSIGNED
Severity: normal → S4
Hardware: Unspecified → All
No longer depends on: segmenter

I'm removing bug 1696387 as a blocker.
We originally thought it would block because it blocks other improvements to the sandbox, however we have not seen any signs of the issue.
Additionally it would normally be seen (according to chromium comments) because the connection to the DWrite cache would be made during start-up with more permissions and then fail to reconnect if the connection was lost for some reason after lowering the sandbox. With win32k lockdown we are enabling from process start, so the issue would present itself immediately.

No longer depends on: 1696387

It's time to graduate Win32k lockdown from Nightly Experiments to default on
Nightly.

Pushed by cmartin@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c55b23ccde73
Enable Win32k Lockdown by default in Nightly r=preferences-reviewers,fluent-reviewers,Gijs

Backed out changeset c55b23ccde73 (Bug 1381019) for causing mochitest failures on test_bug360437.xhtml.
Backout link
Push with failures
Failure Log

Flags: needinfo?(gpascutto)
Assignee: gpascutto → cmartin
Flags: needinfo?(gpascutto)
Flags: needinfo?(cmartin)
Pushed by cmartin@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c467b50beb6f
Enable Win32k Lockdown by default in Nightly r=preferences-reviewers,fluent-reviewers,Gijs
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 98 Branch
Flags: needinfo?(cmartin)

Per Sebastian's request: Backed out changeset c467b50beb6f (Bug 1381019) for beaking content tabs with win32k lockdown enabled a=backout (bug 1719212) at least on Windows 8.1

Status: RESOLVED → REOPENED
Flags: needinfo?(cmartin)
Resolution: FIXED → ---
Target Milestone: 98 Branch → ---
Backout by nerli@mozilla.com:
https://hg.mozilla.org/mozilla-central/rev/7a69711e1364
Backed out changeset c467b50beb6f for beaking content tabs with win32k lockdown enabled a=backout

bug 1719212

I'm not sure this one is correlated to third party DLL's, might be dual graphics (from a very brief look at reports).

Depends on: 1750742

Can you please use bug 1750742 for enabling this in Nightly the next time. This should make it easier to to track.

No longer depends on: 1750742
Depends on: 1750742
Depends on: 1751012
Depends on: 1751039

Thanks, Tom. Will use bug 1750742 from now on :)

:bobowen and I are investigating the regressions now

Flags: needinfo?(cmartin)
Depends on: 1751494
No longer depends on: 1751012
Depends on: 1751964
Depends on: 1755979
Attachment #9250199 - Attachment is obsolete: true
Depends on: 1757406
No longer depends on: 1757406
Depends on: 1759168
Depends on: 1759171
Depends on: 1759167
Depends on: 1763156
Depends on: 1766468
Depends on: 1769811
Depends on: 1770098
No longer depends on: 1770098
Regressions: 1770098
Attachment #9259132 - Attachment is obsolete: true

Should this ticket be closed now?

Flags: needinfo?(gpascutto)

There's a few old/out-of-date Windows version where we could likely support this but currently do not. We're still looking at that in bug 1759167.

Flags: needinfo?(gpascutto)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: