I'm seeing SIGSYS crash reports about SysV semaphores with fglrx in the stack, which is a situation we try to detect, but this seems to be failing because the GPU vendor string isn't "ATI Technologies Inc." but rather "0x1002".

(My local /usr/share/misc/pci.ids file, which is what lspci uses, maps 1002 to Advanced Micro Devices, Inc. [AMD/ATI] with a comment indicating it was previously ATI Technologies, Inc..)

We could add that, but we'd want to make sure that it won't accidentally detect the amdgpu Mesa driver, only the proprietary one.

We can't just match on 0x1002. Consider bp-a550d048-6cb1-42bf-8f54-1ea0f0190808 and bp-0f9f0367-9a0f-4251-8fcd-b7feb0190808, where the vendorId is "0x1002", but the driverVendor starts with mesa/ and the description has terms like DRM and LLVM that indicate it really is Mesa/Gallium.

In contrast, bp-615ae493-d5fc-4121-8fec-600fd0190731 and bp-a40e0923-c5a9-4eaf-a30c-bfd000190730 have driverVendor: "ati/unknown" and don't mention any of those things (and clearly have fglrx on the stack).

But that string comes from this code which is using… the GL vendor string, which is what we're using, except actually no, because GfxDriverInfo::GetDeviceVendor will override it with the "0x1002" we're seeing.

There have been recent changes to that code. Bug 1548911 added the ati/unknown string on 2019-05-29 in 69, and bug 1294232 appears to be why we now get a stringified numeric ID instead of the vendor string, on 2019-03-18 in 68.

So, to fix 70 and 69, we can check for driverVendor starting with ati/… maybe. I've found some reports like bp-8504ee44-4f8f-4a51-84b9-893490190709 which are ati/unknown (and no Mesa indications in the telemetry env) but the stack has amdgpu_dri.so, which I thought meant Mesa, and no frames from fglrx libraries. So that needs more investigation.

And for 68 ESR we'd have to find some other indicator or else also uplift bug 1548911.

What should the Linux sandboxing code be doing to detect when an ATI/AMD proprietary GPU driver is in use? Specifically, we want to distinguish it from the open-source Mesa-based drivers for ATI/AMD GPUs, which don't need this particular hole in the sandbox, including on older versions of Mesa. (If it matters, this is happening on the main thread in the parent process, before the first content process is launched.)

So is this the reason I need to force-enable WebGL after installing AMDGPU-Pro 19.30?
The computer here is a Linux Mint 19.2 running on Ryzen 3 2200G, and WebGL stuff is running fine in Firefox without any crash.

User Agent Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
OS Linux 5.0.0-25-generic
...
GPU #1
Active Yes
Description AMD Radeon Graphics
Vendor ID 0x1002
Device ID AMD Radeon Graphics
Driver Version 5.0.73.0
RAM 0MB

Some more data from about:support

WebGL 1 Driver WSI Info GLX 1.4
GLX_VENDOR(client): AMD
GLX_VENDOR(server): AMD
Extensions: GLX_ARB_create_context GLX_ARB_create_context_profile GLX_ARB_fbconfig_float GLX_ARB_framebuffer_sRGB GLX_ARB_get_proc_address GLX_ARB_multisample GLX_EXT_import_context GLX_EXT_visual_info GLX_EXT_visual_rating GLX_EXT_framebuffer_sRGB GLX_EXT_create_context_es2_profile GLX_MESA_copy_sub_buffer GLX_MESA_swap_control GLX_OML_swap_method GLX_OML_sync_control GLX_SGI_make_current_read GLX_SGI_swap_control GLX_SGI_video_sync GLX_SGIS_multisample GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGIX_visual_select_group GLX_EXT_texture_from_pixmap GLX_INTEL_swap_event GLX_ARB_context_flush_control
WebGL 1 Driver Renderer ATI Technologies Inc. -- AMD Radeon Graphics
WebGL 1 Driver Version 4.6.13572 Compatibility Profile Context 5.0.73
...
WebGL 2 Driver WSI Info -
WebGL 2 Driver Renderer WebGL creation failed:

• Refused to create WebGL2 context because of blacklist entry: FEATURE_FAILURE_OLD_FGLRX

So after going to https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html?version=1.0.4
It's not conforming :-(
Passed 896/912 tests (98.25%), 64556/64580 subtests (99.96%) Failed 7/912 tests (0.77%), 15/64580 subtests (0.02%) Timeout 9/912 tests (0.99%)

You can see the ~first AMDGPU-PRO driver glxinfo here: https://www.phoronix.com/scan.php?page=article&item=amd-gpu-pro&num=1
And the latest super duper modded fglrx release info here: https://opengl.gpuinfo.org/displayreport.php?id=2703
(build numbers should be mostly correct, but I could not swear not having touched a digit of the build number to experiment)

I'm not sure when you could consider the two things to have diverged enough to be considered different, but it shouldn't really be rocket science to detect.

Closing because no crashes reported for 12 weeks.