[VRP] Add constant for checking allowed platforms by PauloVLB · Pull Request #5450 · google/clusterfuzz

PauloVLB · 2026-09-03T15:02:25Z

b/556677120

Problem

Long-lived bots currently exit with a fatal error whenever they encounter an untrusted testcase (trusted=False). However, there are existing testcases in Datastore marked as untrusted that belong to non-Linux jobs (e.g. Windows, Mac). Since uworker execution only runs in Linux containers, non-Linux tasks have no other way to execute and are completely blocked.

This was not caught during dev testing due to the lack of non-Linux VMs in the dev environment. This change does not affect the VRP security model because untrusted external fuzzers are strictly restricted to Linux jobs.

Proposed Solution

Defined PLATFORMS_SUPPORTING_UNTRUSTED_WORKLOADS = {'linux'} in uworker_io.py.
Added helper is_untrusted_testcase_allowed_on_bot(testcase) in uworker_io.py to check if the testcase's job platform is outside PLATFORMS_SUPPORTING_UNTRUSTED_WORKLOADS.
Updated check_handling_testcase_safe in uworker_io.py to allow execution on long-lived bots for non-Linux jobs.

Testing

Added unit tests in uworker_io_test.py verifying that untrusted testcases on non-Linux platforms (Windows, Mac, Android) pass on long-lived bots, while Linux jobs raise SystemExit.
Verified unit tests pass: python butler.py py_unittest -t core -p uworker_io_test.py
Verified code passes linting: python butler.py lint

dylanjew

Is this only a temporary problem? Will all of the Testcases scheduled for Mac/windows eventually be trusted=True?

dylanjew · 2026-09-03T15:08:09Z

+  allowed_platforms = [
+      p.strip().lower()
+      for p in enable_untrusted_flag.string_value.split(',')
+      if p.strip()


does this handle if there is just one platform? do you stil need to lower() the input allowed_platforms?

Yes, this handles cases where string_value is, for example, 'MAC', resulting in allowed_platforms = ['mac']. The lower() call is included as a safety measure in case the value was incorrectly set using uppercase letters.

dylanjew · 2026-09-03T15:23:03Z

Is this only a temporary problem? Will all of the Testcases scheduled for Mac/windows eventually be trusted=True?

I guess what I'm getting at is that the point of having the is trusted check is to prevent these untrusted testcases from appearing on these bots. Is our only solution instead to ensure that untrusted fuzzers are never scheduled on non-linux bots? Is that enforced in any way when trying to configure the fuzzer jobs?

Do we need to go through and backfill the Testcases.trusted field from fuzzers that are enabled on windows and mac?

ViniciustCosta · 2026-09-03T16:56:32Z

I guess what I'm getting at is that the point of having the is trusted check is to prevent these untrusted testcases from appearing on these bots. Is our only solution instead to ensure that untrusted fuzzers are never scheduled on non-linux bots? Is that enforced in any way when trying to configure the fuzzer jobs?

Do we need to go through and backfill the Testcases.trusted field from fuzzers that are enabled on windows and mac?

Just to highlight that the issue is that there is no untrusted worker logic for windows/mac/android platforms. All testcases and fuzzers for these platforms must be "trusted" in the sense of being able to run on long-lived privileged bots (that's the current state).

I think testcases uploaded to clusterfuzz are marked as untrusted. And there are codepaths that are blocked by the testcase not being marked as trusted which are not really related to bot execution, so we should keep the trusted=false even though they can still run on bots for that platform. If we remove this, we should understand the impact for most use cases. @PauloVLB may add more details about that

ViniciustCosta · 2026-09-03T17:14:41Z

  SWARMING_MAX_PENDING_TASKS = 'swarming_max_pending_tasks'

  ENABLE_FUZZ_FOR_BOTS = 'enable_fuzz_for_bots'
+  ENABLE_UNTRUSTED_TESTCASES_FOR_BOTS = 'enable_untrusted_testcases_for_bots'


I think this name is not very clear, without context it is difficult to understand. It should have something related to platforms that support the trusted/untrusted model.

Also, I think we should set it as a global var instead of a feature flag. This will be true for android/mac/windows until there are significant architectural changes and not a feature that we can simply enable/disable. Wdyt?

Agreed. I changed the name to PLATFORMS_SUPPORTING_UNTRUSTED_WORKLOADS and removed the feature flag.

PauloVLB · 2026-09-03T21:20:20Z

All testcases and fuzzers for these platforms must be "trusted" in the sense of being able to run on long-lived privileged bots (that's the current state).

Exactly. Since we are not yet able to run test cases for non-Linux platforms in ephemeral environments, we are obligated to run them on long-lived bots.

I think testcases uploaded to clusterfuzz are marked as untrusted.

Yes. In create_user_uploaded_testcase, we set all user-uploaded testcases as untrusted:

clusterfuzz/src/clusterfuzz/_internal/datastore/data_handler.py

Line 1446 in d937566

testcase.trusted = False

And there are codepaths that are blocked by the testcase not being marked as trusted which are not really related to bot execution

Indeed:

clusterfuzz/src/clusterfuzz/_internal/bot/tasks/utasks/progression_task.py

Lines 430 to 431 in d937566

    
           if not testcase.trusted: 
        
             logs.warning('Not saving untrusted testcase to regression corpus.')

I agree that we should not backfill non-Linux testcases as trusted = True, as that status is used for purposes beyond just bot execution eligibility.

ViniciustCosta · 2026-09-04T12:28:18Z

+
+
+def is_untrusted_testcase_allowed_on_bot(testcase) -> bool:
+  """Returns True if the untrusted testcase is on a platform that does not


nit: go/pystyle#function-docs - although this is not nearly close to be enforced on clusterfuzz legacy code, usually it is better to have a one-liner docstring followed by a more detailed description after a blank line.

ViniciustCosta · 2026-09-04T12:32:23Z

+def is_untrusted_testcase_allowed_on_bot(testcase) -> bool:
+  """Returns True if the untrusted testcase is on a platform that does not
+  support the untrusted execution model (so it must run on a long-lived bot)."""
+  job = data_types.Job.query(data_types.Job.name == testcase.job_type).get()


Why not use testcase.platform()? Can you check if this field is filled in the database?

Add feature flag for checking allowed platforms

fb1bb99

PauloVLB marked this pull request as ready for review September 3, 2026 15:02

PauloVLB requested a review from a team as a code owner September 3, 2026 15:02

dylanjew reviewed Sep 3, 2026

View reviewed changes

ViniciustCosta reviewed Sep 3, 2026

View reviewed changes

Remove feature flag and change name

c9d495d

PauloVLB changed the title ~~[VRP] Add feature flag for checking allowed platforms~~ [VRP] Add constant for checking allowed platforms Sep 3, 2026

ViniciustCosta reviewed Sep 4, 2026

View reviewed changes

Navigation Menu

Uh oh!

[VRP] Add constant for checking allowed platforms - #5450

[VRP] Add constant for checking allowed platforms#5450
PauloVLB wants to merge 2 commits into
masterfrom
vrp-enable-untrusted-testcases-execution

PauloVLB commented Sep 3, 2026 •

edited

Loading

Uh oh!

dylanjew left a comment

Uh oh!

dylanjew Sep 3, 2026

Uh oh!

PauloVLB Sep 3, 2026

Uh oh!

dylanjew commented Sep 3, 2026

Uh oh!

ViniciustCosta commented Sep 3, 2026 •

edited

Loading

Uh oh!

ViniciustCosta Sep 3, 2026

Uh oh!

ViniciustCosta Sep 3, 2026

Uh oh!

PauloVLB Sep 3, 2026

Uh oh!

PauloVLB commented Sep 3, 2026

Uh oh!

ViniciustCosta Sep 4, 2026

Uh oh!

ViniciustCosta Sep 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants



		def is_untrusted_testcase_allowed_on_bot(testcase) -> bool:
		"""Returns True if the untrusted testcase is on a platform that does not

Uh oh!

Conversation

PauloVLB commented Sep 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Proposed Solution

Testing

Uh oh!

dylanjew left a comment

Choose a reason for hiding this comment

Uh oh!

dylanjew Sep 3, 2026

Choose a reason for hiding this comment

Uh oh!

PauloVLB Sep 3, 2026

Choose a reason for hiding this comment

Uh oh!

dylanjew commented Sep 3, 2026

Uh oh!

ViniciustCosta commented Sep 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ViniciustCosta Sep 3, 2026

Choose a reason for hiding this comment

Uh oh!

ViniciustCosta Sep 3, 2026

Choose a reason for hiding this comment

Uh oh!

PauloVLB Sep 3, 2026

Choose a reason for hiding this comment

Uh oh!

PauloVLB commented Sep 3, 2026

Uh oh!

ViniciustCosta Sep 4, 2026

Choose a reason for hiding this comment

Uh oh!

ViniciustCosta Sep 4, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

PauloVLB commented Sep 3, 2026 •

edited

Loading

ViniciustCosta commented Sep 3, 2026 •

edited

Loading