win: Issues launching subprocesses with LPAC sandbox enabled #3791
Comments
@Mellnik have you tested any other Windows versions? |
magreenblatt
changed the title
magreenblatt
changed the title
|
@magreenblatt |
|
I'm not able to reproduce this crash with cefclient 128.4.12+g1d7a1f9+chromium-128.0.6613.138 or 129.0.6+ga918aa7+chromium-129.0.6668.29 (64-bit builds). I have the same Windows 11 version. |
|
@Mellnik can you test if the crash reproduces for you on a different machine (different GPU/drivers)? |
|
Alright I had it tested by a friend. He's running the same Windows version as me tho. (23H2, 22631.4169). NVIDIA driver version 552.22 with an RTX 3060 Laptop GPU. My NVIDIA driver version: 561.09, GTX 1080 Ti To confirm I've compiled a fresh 129.0.6+ga918aa7+chromium-129.0.6668.29 which results in the same crash. I've also observed the same crash in another scenario last week. Unfortunately I don't have any more information on how to reproduce this other scenario. From the stacktrace that I posted it looks like the pointer Do you have any more information on what to try? Thank you. Edit: Using Visual Studio 2022 17.11.4 in case it matters. |
Where in the code is this NOTREACHED that you're referring to? NOTREACHED is fatal in Chromium starting with ~M127. See here for background. |
|
Sorry for the delay. Here is more information about the NOTREACHED.
So it looks like |
|
Thanks for the updated details. I'm not sure why this code path is triggering for you. However, the reason for this |
|
@Mellnik Can you post the full call stack for this NOTREACHED? What module is this code running in? Presumably it's not running in libcef.dll or |
|
The call stack from the original post is from cefclient.exe. The one I posted today is from my application that embeds CEF with OSR. |
|
Update: I've just downloaded You said boringssl was removed. I wonder how the capabilities, that are not well known capabilities, are supposed to be found if the code part is omitted. (The I also wonder if anybody else is able to reproduce this. |
|
Testing with Loaded https://webglsamples.org/aquarium/aquarium.html using the different command line options. The webgl demo loaded, ran for a while without issues. |
|
@Mellnik Does the crash reproduce for you when using the pre-built "Sample Application" from https://cef-builds.spotifycdn.com/index.html ? |
|
@amaitland Thank you for your testing. @magreenblatt No, just tested and it does not crash with the pre-built binaries. |
|
Just an update. After reinstalling Visual Studio and everything related to it, it still does not work. Will continue trying to find a solution. Gonna try it with a new Windows installation in a VM next and then further dig into the source code.... |
|
This appears to be a linker issue (either VS bug or problem with cef_sandbox.lib). I can reproduce with VS 17.9.2 on Windows 10 using the 129.0.11 x64 standard distribution. This is a Radeon Pro Vega 16 GPU.
This wouldn't be an issue with the "Sample Application" which is built as part of the Chromium build.
The odd part is "External Code" calling into AddCapability. This might just be optimization compiling out the callers, but it's the reason I suspect a linker issue. |
|
The BoringSSL dependency changes were made in M110/M111 timeframe, so I wouldn't expect those to start causing problems in M128. |
magreenblatt
changed the title
|
Thank you for testing and reproducing the issue yourself.
Last version without crash: First version where it crashes: Later stable version of M127, it crashes too. Maybe that helps finding what changed between those versions causing this. Regarding the BoringSSL dependency, it makes sense thinking that it's not because of it. Because in fact M126 and earlier works fine. |
Yes, good point. |
|
I've modified the source code. If it's a sandbox build I am now calculating the SHA256 with a different header only library. I don't have a deep knowledge of CEF/Chromium like you but I think it would be good to investigate why this code path is sometimes triggered and for other users not. If I can help with anything please let me know. I can also send you the source changes if you like so you can test it yourself. |
|
As background, the |
magreenblatt
changed the title
We would need to access this symbol via LoadLibrary to avoid any build/link-time dependencies on libcef. |
|
As for Windows CryptoAPI, here is an example for a working drop-in replacement for the original BoringSSL function, thanks to ChatGPT ^^ #define SHA256_DIGEST_LENGTH 32
bool SHA256(const uint8_t* InData, size_t InDataLen, uint8_t OutHash[SHA256_DIGEST_LENGTH])
{
HCRYPTPROV hProv = 0;
HCRYPTHASH hHash = 0;
if (!CryptAcquireContext(&hProv, nullptr, nullptr, PROV_RSA_AES, CRYPT_VERIFYCONTEXT))
{
return false;
}
if (!CryptCreateHash(hProv, CALG_SHA_256, 0, 0, &hHash))
{
CryptReleaseContext(hProv, 0);
return false;
}
if (!CryptHashData(hHash, InData, static_cast<DWORD>(InDataLen), 0))
{
CryptDestroyHash(hHash);
CryptReleaseContext(hProv, 0);
return false;
}
DWORD dwHashLen = SHA256_DIGEST_LENGTH;
if (!CryptGetHashParam(hHash, HP_HASHVAL, OutHash, &dwHashLen, 0))
{
CryptDestroyHash(hHash);
CryptReleaseContext(hProv, 0);
return false;
}
CryptDestroyHash(hHash);
CryptReleaseContext(hProv, 0);
return true;
} |
Nice. Any idea where this code is from originally, so we can verify license compatibility? EDIT: Some people suggest that ChatGPT-generated code is public domain. A quick internet search didn't find any substantially similar code in existing publicly discoverable projects. We'll probably go with public domain unless there is evidence to suggest otherwise. |
|
Looks like the Crypto API methods are deprecated and we should use CNG instead. There's a SHA256 example at https://learn.microsoft.com/en-us/windows/win32/seccng/creating-a-hash-with-cng |
|
We'll stick with Crypto API for now, as it's part of advapi32 (not a new link dependency). Attached is a small verification program for ChatGPT's implementation (rename to .cpp). |
The cef_sandbox build can't use the default BoringSSL implementation so we add an alternative implementation using the Crypto API.
|
Using a Debug x64 build of cefclient (binary distribution) at version 131.3.5+g573cec5+chromium-131.0.6778.205 on Win11 I'm occasionally seeing the following crash, which may be related: Looks to be hitting the DCHECK here after failing with SBOX_ERROR_CREATE_APPCONTAINER_ACCESS_CHECK here which links to https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/design/sandbox.md#lpac-file-system-permissions. This appears to be the same installer permissions (icacls) issue as #3725 (comment). The command-line for the process that it's trying to launch is: The call stack leading up to the process launch is: Looking at the logic in RequestGpuSupportedDirectXVersion, the process launch is delayed for 2 minutes after application start (unless After disabling the above there's another utility process launch via: This checks CanLaunchOnDeviceModelService and can be disabled by passing the Using just the |
magreenblatt
changed the title
|
I've observed the same/similar error. This now happens after we fixed
|
|
The network service is enabling an LPAC sandbox starting in ~M134, as a field trial. This crashes with "Network service crashed, restarting service." in Debug builds if LPAC ACLs are missing. You can disable the sandbox by passing The following shows in
We should update CEF sample apps to set LPAC ACLs as part of the GN/CMake build. See for example set_lpac_acls.py in Chromium. Also a shorter python example here (related commit here). Note that Example assigning ACLs for a local CEF/Chromium build: Reproduction steps with the M133 "Sample Application":
Closer look at step 4 (ACL assignment): |
Testing with a clean local build of CEF/Chromium at M133, the LPAC ACLs appear to be properly configured on the out\Debug_GN_x64 directory by default. |
Describe the bug
A crash happens when opening a specific website.
https://webglsamples.org/aquarium/aquarium.html
The website provides WebGL examples. The crash only happens with the specific example in the link above.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
No crash should happen. The website is a WebGL example.
Screenshots
Versions (please complete the following information):
Additional context
Reproducible with cefclient.exe and my embedded OSR application.
Not reproducible with Google Chrome.
The crash seems to happen by trying to add the capability "kLpacChromeInstallFiles" to so called "app container profile".
Full call stack:
The text was updated successfully, but these errors were encountered: