1812264 - MinGW builds of TestDllInterceptor fail to recognize the Windows version after 8, likely missing an app executable manifest

Status: RESOLVED FIXED

(Firefox Build System :: General: Unsupported Platforms, defect)

Description

[Yannis Juglaret [:yannis]]

As highlighted by bug 1811613, MinGW builds of the TestDllInterceptor executable for Windows seem to identify the running version as Windows 8 when running on Windows 10 or 11 (and likely Windows 8.1). The Firefox executable itself is likely affected as well (to be confirmed). Failing to recognize the proper version of Windows can lead to undesirable behaviors, such as not activating security mitigations which are only compatible with most recent versions.

The code that identifies the Windows version relies on the VerifyVersionInfoW Win32 API. The documentation for VerifyVersionInfoW states the following, which is very likely the root cause of this problem:

Note: This function has been deprecated for Windows 10. See targeting your applications for Windows for more information.

Windows 10: VerifyVersionInfo returns false when called by applications that do not have a compatibility manifest for Windows 8.1 or Windows 10 if the lpVersionInfo parameter is set so that it specifies Windows 8.1 or Windows 10, even when the current operating system version is Windows 8.1 or Windows 10. Specifically, VerifyVersionInfo has the following behavior:

• If the application has no manifest, VerifyVersionInfo behaves as if the operation system version is Windows 8 (6.2).
• If the application has a manifest that contains the GUID that corresponds to Windows 8.1, VerifyVersionInfo behaves as if the operation system version is Windows 8.1 (6.3).
• If the application has a manifest that contains the GUID that corresponds to Windows 10, VerifyVersionInfo behaves as if the operation system version is Windows 10 (10.0).

The Version Helper functions use the VerifyVersionInfo function, so the behavior IsWindows8Point1OrGreater and IsWindows10OrGreater are similarly affected by the presence and content of the manifest.

To manifest your applications for Windows 8.1 or Windows 10, see Targeting your application for Windows.

The Targeting your application for Windows page states the following:

In Windows 8.1 and later, the GetVersion and GetVersionEx functions have been deprecated. As of Windows 10, the VerifyVersionInfo function is also deprecated. You can still call the deprecated functions, but if your application doesn't specifically target Windows 8.1 or later, then the functions will return the Windows 8 version (6.2).

In order for your app to target Windows 8.1 or later, you'll need to include an app (executable) manifest for the app's executable. Then, in the <compatibility> section of the manifest, you'll need to add a <supportedOS> element for each Windows version you want to declare that your app supports.

Normal builds of TestDllInterceptor (and Firefox) recognize the running Windows version with success, so they are probably doing the right thing and can likely serve as a basis to fix this problem for MinGW builds.

Note: Not related to MinGW but potentially concerning, the page also mentions the following:

GetVersion, GetVersionEx, VerifyVersionInfo, and the Version Helper functions are for desktop apps only. Universal Windows apps can use the AnalyticsInfo.VersionInfo property for telemetry and diagnostic logs.

I'm not sure about the definition of desktop app above, in particular whether our MSIX builds are considered a desktop app or a universal Windows app. It might be worth double checking that they recognize the running Windows version properly as well just to be sure.

Comment 1

[Yannis Juglaret [:yannis]]

With the help of [:mhowell] and [:cmartin] (thanks!):

• We need these lines to be embedded in the binary to have proper version checking.
• It is the case for firefox.exe and TestDllInterceptor.exe in normal builds, and for firefox.exe in MinGW builds. Only TestDllInterceptor.exe seems to be missing this, and only in MinGW builds.
• There is a dedicated manifest for TestDllInterceptor.exe, but it doesn't seem to reach the binary in MinGW builds.

This confirms that the problem only exists in the test and not in Firefox itself which is great relief.

Comment 2

[Molly Howell (she/her) (no longer active)]

Also, to answer your question about MSIX builds, those are indeed desktop apps for the purposes of API support. There are a number of limitations on the Win32 API surface available to apps built on the UWP framework, but taking an existing Win32 app and simply packaging it into an MSIX file does not subject us to those limitations.

I'll note also that the document you referenced was likely written in the early Windows 8 days, before MSIX or even the old Desktop App Converter existed; it wouldn't have been as confusing at the time.

Comment 3

[Yannis Juglaret [:yannis]]

Thanks Molly!

Regarding the manifest for TestDllInterceptor.exe, it was actually intentionally removed in bug 1657863, which explains the current bug.

Comment 4

[Yannis Juglaret [:yannis]]

So here's what likely happened:

• Bug 1656141 added manifests to MinGW binaries.
• This caused TestDllInterceptor.exe to now realize it's not running on Windows 8, thus it can run the tests that make use of the ACG mitigation.
• However ACG was broken in MinGW builds, causing perma bug 1657863, which led to removing the manifest for TestDllInterceptor.exe.
• The problem with using ACG in MinGW builds was figured out with bug 1766432 comment 4, and fixed accordingly.
• But we are left with a missing manifest for TestDllInterceptor.exe.

So I believe we may simply have to revert the change from bug 1657863 and we'll be good to go.

Comment 5

[Yannis Juglaret [:yannis]]

Attachment: Bug 1812264 - Add manifests automatically on mingw builds. r=glandium

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c0814570d48e
Add manifests automatically on mingw builds. r=glandium

Comment 7

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/c0814570d48e