1769811 - Broken Chinese/Japanese fonts with win32k Lockdown enabled

Status: RESOLVED INCOMPLETE

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

Description

[[e-mail]]

Attachment: 2022-05-18_012121.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

A few days ago, my Firefox updata to 100, all text become to square.
After checking, I found

security.sandbox.content.win32k-experiment.enrollmentStatus

This option will make my text square，force a font also symbol error.

My approach is to delete the corresponding line in prefs.js before each startup, but after the update, the deletion is no longer effective.

（Sorry, my english is terrible, and I'm not familiar with how to report bugs. My language environment is Chinese or Japanese, those squares are these languages.）

Actual results:

After trying, modify it to 1. But it will still be set to 2 every time.

Expected results:

Don't re-enable or normal display.

Comment 1

[[e-mail]]

p.s. I have turned on webrender, and it's still the same.

Comment 2

[Gian-Carlo Pascutto [:gcp]]

A workaround would be to flip security.sandbox.content.win32k-disable to false. We rolled this out to all users so the experiment settings are no longer relevant.

We need to figure out what breaks this though. Can you provide the contents of about:support and about:third-party?

Comment 3

[Gian-Carlo Pascutto [:gcp]]

p.s. I have turned on webrender, and it's still the same.

To clarify: win32k lockdown won't activate if you don't have WebRender, so if you say that you "turned on WebRender", what exactly did you do and what was happening before?

Comment 4

[[e-mail]]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #3)

p.s. I have turned on webrender, and it's still the same.

To clarify: win32k lockdown won't activate if you don't have WebRender, so if you say that you "turned on WebRender", what exactly did you do and what was happening before?

didn't do anything.

I found that Status 2 is related to WebRender, and then went to open it.
Also, I have tried security.sandbox.content.win32k-disabletofalse, but it still fails.

Comment 5

[[e-mail]]

Attachment: about-support.txt

Comment 6

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

:bobowen, since you are the author of the regressor, bug 1767999, could you take a look?
For more information, please visit auto_nag documentation.

Comment 7

[[e-mail]]

Attachment: prefs normal.js

This is the available prefs.js

Comment 8

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

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 9

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

The severity field for this bug is set to S3. However, the bug is marked as tracked for firefox102 (nightly), tracked for firefox101 (beta) and tracked for firefox100 (release).
:gcp, could you consider increasing the severity of this tracked bug?

For more information, please visit auto_nag documentation.

Comment 10

[Gian-Carlo Pascutto [:gcp]]

From your about:support:
"contentWin32kLockdownState": "Win32k Lockdown disabled -- user in Control Group"

This matches your observation:

Also, I have tried security.sandbox.content.win32k-disable to false, but it still fails.

The first message is a bit weird because there is no Control Group for win32k - it's enabled by default for everyone. But maybe this is caused by manually changing the experiment preferences. I don't know enough about what the values mean here.

It does look like win32k Lockdown is now disabled for you, but you still have the problem. So perhaps the problem is actually unrelated, this is not very clear to me.

At this point, it might be best to create a fresh profile (see https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles) which will have the default settings (and no add-ons!) and check whether the problem reproduces there or not. If it does, I'd be interested in the about:support from that profile.

p.s. I have turned on webrender, and it's still the same.
didn't do anything.
I found that Status 2 is related to WebRender, and then went to open it.

Sorry but I really do not understand what happened:

• What does "went to open it" mean?
• I don't understand how to align "I have turned on webrender" against "didn't do anything"

I see in your about:support:

          "name": "WEBRENDER",
          "description": "WebRender",
      ==> "status": "force_enabled", <==
          "log": [
            {
              "type": "default",
              "status": "available"
            },
            {
              "type": "user",
              "status": "force_enabled",
              "message": "Force enabled by pref"
            }

Which seems to indicate that at some point WebRender was explicitly forced on by modifying the settings. That could also be a cause of this problem, which is why checking on a profile with the default would be good at this point in tracking this down. Right now there's too much uncertainty about the state of this config...

Another point of confusion for me is that I gather from your comments is that you saw some message that related win32k Lockdown status to WebRender being disabled, but the above about:support implies (I think?) WebRender would have been enabled by default even without the force-enable. This is another thing a fresh profile would clarify.

Comment 11

[Gabi Cheta [:Gabi] Desktop QA]

I was not able to reproduce the issue with Windows 10x 64 Firefox 100.0.1 build ID 20220513165813 where security.sandbox.content.win32k-disable is enabled.
We've tried a few Firefox release update scenarios as well where zh-Cn language was set as the environment language.
I also tried using the attached prefs.js file with Firefox zh-CN and JP builds and I was still unable to reproduce this issue.

Comment 12

[[e-mail]]

1、only update 100＝problem
2、create a new profile＝problem
3、create a new profile & disable sync ＝problem with second start
4、create a new profile & copy earliest prefs.js
5、comparing prefs.js with Beyond Compare , repeatedly start FireFox
6、find

user_pref("app.normandy.startupRolloutPrefs.security.sandbox.content.win32k-experiment.enrollmentStatus", 2);

7、delete and start＝normal display
8、restart, appearing again
9、search by google, find webrender,setgfx.webrender.all to true＝problem
10、delete this line for every boot.
11、update 100.0.1＝problem＝delete is useless
12、try to set 1＝normal display, but exit FireFox still be set to 2
13、report bugs

Comment 13

[[e-mail]]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #10)

From your about:support:
"contentWin32kLockdownState": "Win32k Lockdown disabled -- user in Control Group"

This matches your observation:

Also, I have tried security.sandbox.content.win32k-disable to false, but it still fails.

The first message is a bit weird because there is no Control Group for win32k - it's enabled by default for everyone. But maybe this is caused by manually changing the experiment preferences. I don't know enough about what the values mean here.

It does look like win32k Lockdown is now disabled for you, but you still have the problem. So perhaps the problem is actually unrelated, this is not very clear to me.

At this point, it might be best to create a fresh profile (see https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles) which will have the default settings (and no add-ons!) and check whether the problem reproduces there or not. If it does, I'd be interested in the about:support from that profile.

p.s. I have turned on webrender, and it's still the same.
didn't do anything.
I found that Status 2 is related to WebRender, and then went to open it.

Sorry but I really do not understand what happened:

• What does "went to open it" mean?
• I don't understand how to align "I have turned on webrender" against "didn't do anything"

I see in your about:support:

          "name": "WEBRENDER",
          "description": "WebRender",
      ==> "status": "force_enabled", <==
          "log": [
            {
              "type": "default",
              "status": "available"
            },
            {
              "type": "user",
              "status": "force_enabled",
              "message": "Force enabled by pref"
            }

Which seems to indicate that at some point WebRender was explicitly forced on by modifying the settings. That could also be a cause of this problem, which is why checking on a profile with the default would be good at this point in tracking this down. Right now there's too much uncertainty about the state of this config...

Another point of confusion for me is that I gather from your comments is that you saw some message that related win32k Lockdown status to WebRender being disabled, but the above about:support implies (I think?) WebRender would have been enabled by default even without the force-enable. This is another thing a fresh profile would clarify.

look up

add

1.1、Firefox 99、Waterfox is normal
9.1、setsecurity.sandbox.content.win32k-disable to false＝still have problem
9.2、upgrade the graphics card driver＝still have problem

Comment 14

[Bob Owen (:bobowen) (PTO until 17th Apr)]

Thanks for reporting this and sorry for the frustration caused.

Would you mind trying the following steps (I know they are a bit similar to what you have tried, but they should help rule some things out):

• Create a new profile and start Firefox 100.0.1 with it
• If you still see a problem, then in about:config set security.sandbox.content.win32k-disable to false
• Restart the browser and see if the problem is still there
• Upload the current configuration text from about:support

Comment 15

[Gian-Carlo Pascutto [:gcp]]

Thank you very much for your patience, the steps that were outlined in comment 12 do clarify and explain what happened. The preference you were trying to flip back is controlled by the update server (and not intended to be set manually), so each time you made a fresh profile it "worked", until it got updated, and the updated value then got applied on restart, which you edited, which got updated again, and so on...

Please follow Bob's steps above (specifically using a new, fresh profile) to get us the required information to further diagnose.

Comment 16

[[e-mail]]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #15)

Thank you very much for your patience, the steps that were outlined in comment 12 do clarify and explain what happened. The preference you were trying to flip back is controlled by the update server (and not intended to be set manually), so each time you made a fresh profile it "worked", until it got updated, and the updated value then got applied on restart, which you edited, which got updated again, and so on...

Please follow Bob's steps above (specifically using a new, fresh profile) to get us the required information to further diagnose.

Sorry, I've been a little busy these days

Updata to 100.0.2 security.sandbox.content.win32k-disable : false is useful , the problem disappears.

Comment 17

[Bob Owen (:bobowen) (PTO until 17th Apr)]

Thanks for testing that.
Please would you try the following steps, so we can try and further isolate the problem:

• in about:config make sure security.sandbox.content.win32k-disable is still false (which fixes the problem)
• also set gfx.font_rendering.directwrite.use_gdi_table_loading to false
• restart the browser and see if the problem returns

This will use the same code path (that we think might be causing the problem) as when win32k lockdown is enabled.

Comment 18

[[e-mail]]

(In reply to Bob Owen (:bobowen) from comment #17)

Thanks for testing that.
Please would you try the following steps, so we can try and further isolate the problem:

• in about:config make sure security.sandbox.content.win32k-disable is still false (which fixes the problem)
• also set gfx.font_rendering.directwrite.use_gdi_table_loading to false
• restart the browser and see if the problem returns

This will use the same code path (that we think might be causing the problem) as when win32k lockdown is enabled.

not return.

Comment 19

[Bob Owen (:bobowen) (PTO until 17th Apr)]

(In reply to [e-mail] from comment #18)
...

This will use the same code path (that we think might be causing the problem) as when win32k lockdown is enabled.

not return.

Thanks for testing, that is confusing.
I think there is only one other area in which we directly change the code path with win32k locked down, but I don't think that should affect these fonts.
To try and rule that out I've created a build that will use that different code path even with win32k lockdown disabled.
Please would you:

• Download this build.
• Install it (you might want to select a custom install and use a different path).
• Run the build with a new profile, which should display the same issue.
• As before in about:config set security.sandbox.content.win32k-disable to false.
• Restart this install of Firefox with the same profile and let us know if the problem is still there.

Comment 20

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

Set release status flags based on info from the regressing bug 1767999

Comment 21

[Ryan VanderMeulen [:RyanVM]]

Not going to fix in v101 at this point.

Comment 22

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:gcp, since the bug has high priority and recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 23

[Suhaib Mujahid [:suhaib]]

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.

Comment 24

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

A needinfo is requested from the reporter, however, the reporter is inactive on Bugzilla. Closing the bug as incomplete.

For more information, please visit BugBot documentation.