1483687 - Unify all DLL blocklists

Status: RESOLVED FIXED

(Firefox :: General, task, P2)

Description

[(No longer employed by Mozilla) Aaron Klotz]

I'm not sure how much of a perf gain we could get here, but I think it's worth testing.

Comment 1

[(No longer employed by Mozilla) Aaron Klotz]

I don't want to land this until the regression test is ready.

Comment 2

[(No longer employed by Mozilla) Aaron Klotz]

There appear to be slight xperf gains, but the most noticeable change is a much smaller standard deviation. I think that makes this worth landing.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Moving to p2 because no activity for at least 24 weeks.
See How Do You Triage for more information

Comment 4

[(No longer employed by Mozilla) Aaron Klotz]

Morphing this into the "blocklist unification" bug. The idea here is that I want a single in-tree location for blocklist descriptors of all types. We add a Python script to the build system that reads this unified descriptor file and generates the appropriate sources for each type. Each generated descriptor file will be sorted so that we can do a binary search.

Initial descriptor types:

• All process DLL Blocks
• Parent Process DLL Blocks
• Child Process DLL Blocks
• Winsock LSPs
• A11y clients (DLLs only)

(Note that the resulting lists generated by the script should contain the union of applicable descriptor types. eg the child process descriptors would be the union of the all process list and the child process list.)

Comment 5

[(No longer employed by Mozilla) Aaron Klotz]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=4bd142a726b176049135326fe13db63738da56fa

Comment 6

[(No longer employed by Mozilla) Aaron Klotz]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3f06032136b9f7de91f0d7c6f7713c6fc202ed27

Comment 7

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Bug 1483687: Part 1 - Use a build script to generate various DLL blocklist headers; r=bytesized!

(Adding build peers for the moz.build bits, Kirk for the script itself. Build
peers, please let me know if there's a better way to do this moz.build stuff -
I basically cribbed this from a script being used in a11y.)

As we are increasingly moving toward enabling new types of DLL blocking across
our various process types, we need to be able to generate various headers in
various distinct formats.

This script enables us to use a unified DLL blocklist input that generates
these distinct headers. From WindowsDllBlocklistDefs.in, we generate:

WindowsDllBlocklistA11yDefs.h - definitions for a11y
WindowsDllBlocklistLauncherDefs.h - definitions for the launcher process
WindowsDllBlocklistLegacyDefs.h - definitions for the legacy mozglue blocklist
WindowsDllBlocklistTestDefs.h - test-only definitions

These headers are then exported to mozilla.

Note that not all headers use the same format, as not all consumers of these
headers have identical workings. There will be additional header types added
in the future which diverge even more from the standard blocklist format. While
this work may seem a bit pointless at the moment, it will become more necessary
in the future. In particular, this work is a prerequisite for bug 1238735.

Comment 8

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Bug 1483687: Part 2 - Updates to WindowsDllBlocklistCommon.h macros; r=mhowell!

Depends on D36993

Comment 9

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Bug 1483687: Part 3 - Update DLL blocklist gtests to support the revised blocklist data structures; r=mhowell!

Depends on D36994

Comment 10

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Bug 1483687: Part 4 - Update the launcher process blocklist to use binary search; r=mhowell!

Depends on D36997

Comment 11

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Bug 1483687: Part 5 - Update the legacy DLL blocklist to support the revised data structure format; r=mhowell!

Depends on D36998

Comment 12

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Bug 1483687: Part 6 - Update a11y DLL blocking to use the new unified DLL blocklist; r=Jamie!

Even though a11y DLLs are not strictly "DLL blocking," I felt that it would
make sense to include them in our unified DLL blocklist. This patch delegates
much of that functionality to the unified blocklist code. Going forward, any
further blocklist entries for in-proc a11y DLLs should be added to
mozglue/build/WindowsDllBlocklistDefs.in via the A11yBlocklistEntry type.

Depends on D36999

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c0e1adc0859f
Part 1 - Use a build script to generate various DLL blocklist headers; r=bytesized
https://hg.mozilla.org/integration/autoland/rev/e8b597c78ba8
Part 2 - Updates to WindowsDllBlocklistCommon.h macros; r=mhowell
https://hg.mozilla.org/integration/autoland/rev/9c9292604ddd
Part 3 - Update DLL blocklist gtests to support the revised blocklist data structures; r=mhowell
https://hg.mozilla.org/integration/autoland/rev/8068c6996798
Part 4 - Update the launcher process blocklist to use binary search; r=mhowell
https://hg.mozilla.org/integration/autoland/rev/630c3c12aee9
Part 5 - Update the legacy DLL blocklist to support the revised data structure format; r=mhowell
https://hg.mozilla.org/integration/autoland/rev/71000a40a923
Part 6 - Update a11y DLL blocking to use the new unified DLL blocklist; r=Jamie

Comment 14

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/c0e1adc0859f
https://hg.mozilla.org/mozilla-central/rev/e8b597c78ba8
https://hg.mozilla.org/mozilla-central/rev/9c9292604ddd
https://hg.mozilla.org/mozilla-central/rev/8068c6996798
https://hg.mozilla.org/mozilla-central/rev/630c3c12aee9
https://hg.mozilla.org/mozilla-central/rev/71000a40a923