Three findings from the round on the wake-gate commits, all the same shape: the
gate made "what was asked for" and "what was produced" diverge, and two places
still trusted the first.
CI built the unattended-wayland deb with `--features ...,drm` and then packaged
it with `--skip-cargo`. build.py appends `drm-wake` for `--drm`, but skipping
cargo means whatever that explicit line compiled is what ships, so the deb had
no wake code in it at all while being named and documented as the variant that
has it. The feature list has to be complete on the line that actually builds.
The marker assertion that catches exactly this class only guarded one of the two
packaging paths. `build_deb_from_folder` asserts that the staged binary carries
the libdrmtap dlopen path before it takes the unattended-wayland name; the
flutter path did not, and `--skip-cargo` reaches that one. A stock binary could
therefore be packaged under a name that conflicts with and replaces the stock
package, and then never capture. Hoisted the check to module level and called it
from both, before the bundle is renamed.
And the security doc described the synthetic input injection as an unconditional
property of a drm build. It is behind its own compile feature and a runtime
option, which is exactly what an operator auditing the deb needs to know.
- the scanout dma-buf fd is duplicated with F_DUPFD_CLOEXEC. `dup(2)`
never copies close-on-exec, so this fd was inherited by every child
the ROOT service forks (it forks synchronously for the loginctl
active-uid lookup) - and what this fd names is the live screen
contents. this is the SAME defect already closed on the `_drm`
socket fd in ipc/drm.rs; fixing that one and not grepping for the
siblings is how this survived. there is exactly one dup in the drm
path now and it is this one, verified by grep. measured that
F_DUPFD_CLOEXEC sets FD_CLOEXEC and preserves the O_RDONLY access
mode the read-only export depends on; SCM_RIGHTS delivery is
unaffected since the receiver gets its own descriptor.
- Desktop::refresh resolves HOME on the login-Wayland path too, since
the drm build now starts a --server as the greeter uid there and a
child with no HOME has nowhere to put its config. the compositor
variables stay blank deliberately: the drm path talks to the root
service and a render node, never to the compositor or the portal,
which is why it works at a login screen at all. reasoned, not
measured: a current GDM runs its greeter as `gdm-greeter`, which
`is_gdm_user` does not match, so that path is not reachable on our
hardware - measured there, the greeter server gets a fully populated
environment through the branch below.
- the glibc-floor step globs into an array and asserts the count, like
its sibling assert step. that sibling was fixed two rounds ago and
this one was left behind.
- the .so contract and deb assertions no longer pipe into grep. under
`set -o pipefail`, `producer | grep -q` reports a FALSE FAILURE once
the producer outruns the 64 KB pipe buffer: grep -q exits at the
first match, the producer dies on SIGPIPE, and pipefail makes that
the pipeline's status - so a library that HAS the symbol is reported
as missing it and the step fails on a good build. measured on a real
EGL-enabled .so (101 KB of strings, both markers present): the piped
form reported both missing. this was introduced by the strictness
fix two rounds ago and only passes today because a release-sized .so
fits in the buffer. NOTE the obvious repair does not work either -
materializing the output and piping the variable keeps the pipe and
fails identically (measured), so these now match with bash's own
pattern operator and no subprocess at all. verified with positive
and negative controls.
- warm_availability decides X11 for itself, inside its retry loop,
with the UNMEMOISED `scrap::is_x11()`. this is the same one-shot-at
-startup bug the pre-warm had, in its sibling call site, left behind
when that one was fixed: the check ran during startup, where
loginctl cannot yet name the seat0 session and the answer defaults
to "x11", so a Wayland host that came up slowly skipped the warm for
the life of the process and got back the cold-probe "No displays"
symptom the warm exists to remove. the memoised form would have
moved the bug rather than fixed it, since it latches its first
answer.
- the grab_desc SAFETY comment says what the frame protocol actually
is instead of promising a release on every return path: traced in
the C, a failing grab_desc leaves nothing to release (-EINVAL
returns before allocating, a failed inner grab has already cleaned
up, and -ENOTSUP releases the frame itself), so releasing on those
paths would be a double free.
an adversarial sweep over the whole batch, aimed at the failure that
kept recurring here (a hazard identified and only some instances
fixed), found that two changes made on review advice were themselves
defects. both are reverted with the trace written down so they do not
get "fixed" again:
- the hotplug renumbering probe reads the pushed list at the CLIENT
index again, not the service one. `bound_to` is an IDENTITY,
(device, crtc_id), so comparing it against a slot is not a
cross-index-space comparison; and `swap_available_displays` installs
that same list as DRM_STATE two lines later, which IS the client
space - display_service re-advertises it, input is mapped through
it, the next rebuild reads `expected` out of it. Probing the service
index answered a question nothing downstream consumes and went quiet
in exactly the case the guard exists for: a stream whose wire_idx
differs from its client index kept running while that index came to
mean another monitor, so the client rendered monitor A believing it
was monitor B and routed every click accordingly.
- the pipewire-fallback guard compares raw sizes again. BOTH sides are
physical: `Display::width()` on the wayland variant returns
`physical_width()`, and `try_fix_logical_size` only repairs the
capturable's separate logical_size field. Scaling the drm side
therefore compared logical against physical and rejected the valid
stream on precisely the scaled outputs it was meant to rescue. The
single-display carve-out now needs BOTH sides to be single, since a
monitor on a card the service cannot open is missing from the drm
list while the compositor still drives it.
also from the sweep:
- a capture build whose index is out of range of the advertised list
now fails instead of falling back to the raw index, which the wake
can have grown the service list back past - that bound a second
video service to a monitor already being served and recorded its
health under the wrong identity.
- the security doc no longer claims the privileged process never loads
GL. That is true of the DEFAULT path and measured there, but the CPU
fallback converts in-process, and a tiled scanout can only be
decoded through the GPU, so libdrmtap dlopens libEGL in the calling
process when the frame needs it. The doc now says which property
belongs to the path and which to the process, and bounds the cases
instead of overclaiming.
- the wake latch is described honestly: it self-clears when the
display is next driven by anything, but nothing retries it, so a
transient failure can leave it latched on an unattended host.
- the wake's uinput device DECLARES two axes and BTN_LEFT (libinput
ignores a device that does not look like a mouse) while EMITTING
only the net-zero axis round trip. the doc said one axis and no
keys, describing the emit as if it were the declaration.
- the drm CI never ran for a change to the root Cargo.toml, where the
top-level `drm` feature is defined, or to Cargo.lock, which every
`--locked` build here resolves against. both triggers list them now.
- the deb assertion checks the packaged BINARY carries the libdrmtap
dlopen path, not just that the library was staged beside it.
- the /dev/dri gate returns the CANONICAL path instead of a bool, and
both callers open that value. answering yes/no meant the caller
handed the original string to libdrmtap, which re-resolved every
symlink component after the check - a check-then-use window, in the
root service. this is the whole point of the gate, so it should
never have been able to hand back an unresolved path.
- `--package <folder> --drm` builds the capture library instead of
demanding it inside the bundle. no build path puts libdrmtap in a
bundle folder (the flutter deb builds it straight into the staged
deb), so that check made the flag combination impossible to satisfy.
the safety property it stood in for is now asserted directly and
better: the staged BINARY must carry the drm dlopen path, so a stock
binary can never be packaged under the consent-bypass name. a bundle
that does carry a .so keeps its existing EGL assertion, and the
variant naming keys on the explicit request rather than on what
happened to be staged.
- the deb assert step globs into an array and asserts the count: under
set -e `ls` aborted before its own `test -n` could report, and
several matches produced a multi-line value whose mv failed with an
unrelated error.
- strict mode on the remaining two assert steps of the drm workflow
(the deb-contents assert and the glibc-floor measurement): same
masking pattern as the .so contract step fixed last round - without
set -e only the last command's status counts and the mid-script
checks were decorative. the floor extraction gets an explicit rescue
so a no-match grep still reaches the `test -n` reporter.
- the security doc states the whole accepted version window (exactly
the pinned minor with a patch floor; a NEWER minor is refused too,
because the mirrored struct layouts are only verified against the
pinned one), and the auditing section carries the command matching
its leftover-object comment.
- the uinput-missing warning literal lost the embedded space runs a
reflow had left in it (it is the sole, once-per-process diagnostic
for that failure and it read as a run-on line with gaps).
- the geometry-mismatch path in frame() hands the taken buffer back to
the recycler before erroring; dropping it made every rebuild cycle
re-allocate a scanout-sized buffer.
- the .so contract check in the drm workflow runs under strict mode:
without set -e the trailing ::notice echo returned 0 and masked the
`test "$missing" -eq 0` assertion, so the step passed even with a
missing loader symbol or a CPU-only stub. the two extraction
pipelines get an explicit rescue so a zero-match grep still reaches
the ::error guard that explains WHY instead of dying silently.
- the pipewire-fallback geometry guard no longer compares the physical
drm size against the portal rect on a single-display host: the rect
is the compositor's LOGICAL size, so on a scaled output the two
legitimately disagree (2880x1800 vs 1440x900) and the guard rejected
the one valid fallback, restart-looping the display instead of
degrading. on a single-display host the whole-desktop stream is that
display by construction, so only the position has to agree; the size
check stays on multi-monitor hosts, where it is what tells one
connector apart from the full-desktop rect.
- the renumbering probe in the DrmDisplaysChanged handler now reads the
pushed list at wire_idx, the slot our monitor held in the service's
index space, instead of at the index the client chose. the pushed
list shares the handshake list's construction, so probing the client
index compared two different index spaces whenever a wake or hotplug
had renumbered entries - tearing down a healthy stream or missing a
real renumbering.
- both message-body reads (cpu frame, cursor pixels) now run under a
deadline. only the header read re-checked `stop`, so a producer dying
between a header and its body pinned the receive thread forever and
every rebuild leaked a thread plus its render context.
- the drm cursor cache gets a size ceiling (drm ids are derived from
the shape's content, so an animated pointer minted a new key per
shape and the map grew for the life of the service; x11 ids come
from a small serial set, so the ceiling is gated and the stock build
is untouched).
- has_non_drm_backed_display reads a two-scalar accessor instead of
cloning and geometry-augmenting the whole display list on every
cursor tick.
- the libdrmtap pin validation moved out of import time into
build_libdrmtap_so(), so leftover DRMTAP_* environment variables or a
malformed sha cannot fail a stock build that never touches libdrmtap.
- reworded a workflow comment whose literal expression marker broke
actionlint.
libc::dup() does not copy the close-on-exec flag, so the dup'd _drm socket fd
was inherited by every child this process forks. This process is the ROOT
service and it does fork synchronously elsewhere (the loginctl active-uid
lookup), and that fd is an ALREADY-AUTHORIZED channel to the one thing on the
box that hands out scanout dma-bufs. F_DUPFD_CLOEXEC instead. Measured the
difference rather than assuming it: dup() leaves FD_CLOEXEC clear,
F_DUPFD_CLOEXEC sets it.
Also the last two artifact sources without the stub check:
- --package + --drm stages the .so straight out of a bundle somebody else
produced, with no _assert_so_has_egl. Third source, same exposure as
DRMTAP_PREBUILT_DIR, now asserted like the other two. All three artifact
paths are covered.
- the workflow triggers omitted src/server.rs, src/server/input_service.rs and
src/platform/linux.rs, which all carry DRM wiring (warm_availability, the
cursor path in run_cursor, the producer start and get_cursor/get_cursor_data),
so a PR touching only those skipped the entire drm verification. Added to
BOTH mirrored lists and asserted equal (15 == 15).
I built UinputRefreshGuard INSIDE the spawned closure, so it only covered
paths where the closure ran. thread::spawn panics on EAGAIN after the swap,
so no guard existed and the flag stayed set for the process lifetime, which
is the exact failure the guard was introduced to prevent. I then wrote
RefreshSlot correctly - constructed before the spawn, moved in - two hours
later and did not go back to fix its sibling. Both are right now, and the
spawn is fallible in both.
Also from the review:
- DRMTAP_PREBUILT_DIR returned before the EGL-stub assertion, so the check
only guarded the source build. That is backwards: prebuilt-dir is the
widest override (no fetch, no sha check, an object this script never sees),
the likeliest to hand over a stub, and the path our aarch64 cross-build
actually uses. Verified the assertion accepts a real .so and rejects one
built with -Degl=disabled.
- convert() bounded only the frame libdrmtap returns, not the descriptor going
in. offsets/pitches address plane ranges inside the dma-buf, so those are
what a malformed pair would reach past. Bounded per populated plane, the
same way the export side is. Defense in depth (the producer is
root-authenticated and libdrmtap validates against the fd since 0.4.12),
but the two halves should agree before the C sees the data, not after.
- the flutter patch step used '[[ test ]] && git apply' as its last command,
so the step would FAIL rather than skip the first time FLUTTER_VERSION
moves off 3.24.5. Explicit if/else, and the values now come from the
environment instead of ${{ }} interpolation, which also clears zizmor's
template-injection warning. Checked both branches.
Declined: the cursor id/cache-key convergence finding. Both accessors use one
selection over one map, so they can only disagree across a publish race, and
state.hcursor is already set to the id ACTUALLY served (drm_served_id), which
is the sync the finding asks for - added in an earlier round.
The workflow already said in a comment that this deb is a verification build
with a higher glibc floor than the release debs, because it builds on the
runner rather than in the ubuntu18.04 container the stock job uses. A comment
in this file is not visible to whoever downloads the artifact from the Actions
UI, and the name was a bare rustdesk-unattended-wayland-x86_64.deb, so it read
like something installable anywhere.
The floor is now read off the built object with objdump and goes into the
artifact name, so the constraint travels with the file. Measured rather than
stated: a hardcoded number would drift the next time the runner image moves.
Verified the pipeline against a real deb here (2.39).
Restoring the container build is the other option and is cheap to do -- the
recipe including the two 18.04 traps is still in this repo's history -- but it
belongs with a deb that is actually distributed, not with a job whose contents
are already asserted in-place.
The one that matters: the display-cache refresh worker was the THIRD copy of
the wedged-flag hazard. catch_unwind covered only the enumeration, and
thread::spawn panics on EAGAIN after RUNNING was already swapped true, so
either path parked the flag for the process lifetime and every later refresh
- including every udev hotplug - returned early forever. Same ownership
guard as UINPUT_REFRESH_BUSY (the flag is handed back and re-taken mid-loop,
so an unconditional RAII release would clear a replacement worker's flag),
plus a fallible spawn whose failure drops the closure and releases the slot.
DRM_PROBE_IN_FLIGHT, UINPUT_REFRESH_BUSY, now this: the lesson stays
'grep for every site with the shape', and twice was not enough.
Two findings had been flagged in an earlier round and escaped the ledger:
- an unrecognized convert-output fourcc fell through to 'present as BGRA'
with a debug log, where every sibling validation in that function is a
hard error that lets the caller fall back to PipeWire. A 64bpp output
passes the stride check and encodes garbage. Hard error now.
- the trust-boundary validation constants (fourccs, MAX_DIM,
MAX_FRAME_BYTES) were declared independently on both sides of the split.
Hoisted into drm_reader, imported by the converter, so the two halves
cannot drift apart about what data they will touch.
The rest:
- the CI symbol extraction dropped any loader symbol containing a digit and
degraded to a pass-with-zero-iterations no-op if the b"..." literals were
ever refactored; digits allowed, count asserted, notice de-hardcoded.
- 'drm' in features was a substring test on the comma-joined string, so a
future drm-lease feature would have shipped the consent-bypass deb
without --drm. Exact membership now.
- the security doc claimed the deb is built on an ubuntu18.04 container;
the only deb job runs on ubuntu-24.04. The 18.04 sentence now says what
is true: 2.4.95 is an API floor, the binary floor is the build host's.
- DRM_DISPLAY_CACHE poison handling was recover-in-the-writer,
panic-in-the-readers; both readers now recover like the writer.
- the producer prewarm ran on X11 where no consumer can connect, the same
inconsistency just fixed for warm_availability. The listener still starts
(the service outlives sessions; a later Wayland login must find the
socket), only the prewarm is skipped.
The uinput refresh worker released UINPUT_REFRESH_BUSY on its two normal
exits only. The body locks several process-wide mutexes and does a Wayland
roundtrip, so an unwind there left the flag set for the process lifetime,
and every later hotplug then skipped the spawn and never reapplied the
uinput ABS range: the stale-range, wrong-output symptom the refresh exists
to prevent. This file already had the answer for the probe flag, one screen
away, and the hazard is called out in wayland.rs. Fixing one site and not
the other is the same miss as the hotplug maps.
The slot is deliberately handed back and re-taken mid-loop, so the guard
tracks ownership rather than releasing unconditionally: a plain RAII drop
would clear a flag a replacement worker owns.
drm_reader bounded only the destination (w*4*h) while the row loop reads up
to (h-1)*stride + w*4, so a large stride read past the mapping and could
overflow usize in y*stride. drm_render::convert already bounds stride*h;
the privileged half must not be the weaker of the two.
Also give the drm CI jobs a timeout, so a hung meson or vcpkg step fails in
an hour instead of six.
From the second review bot on our fork. Two of these are real and one of them is
mine from earlier today.
A raw body read had no deadline. Only the header was bounded, and drm_read_full
loops on readable() until it has the exact length, so a producer that wrote a
header and then stopped (crashed, stopped, wedged) pinned the consumer receive
thread forever. That thread is also the one that observes the stop flag, so every
capturer rebuild would have stranded another thread and its render context. The
whole body is bounded now, and an overrun is a hard error because the header is
already consumed and the frame cannot be resumed.
get_capturer_info collapsed an unknown connector identity to the empty string and
then read and wrote the health map under it, so two unidentifiable displays shared
one entry and one could demote the other. That is exactly the aliasing frame()
refuses to take part in; I fixed one side of it this morning and left the other.
The key is an Option now and both blocks skip when it is None: a display with no
identity simply carries no health.
Also from the same pass, smaller:
- build.py validates the shape of DRMTAP_SHA and DRMTAP_REPO before they reach a
shell command. Both are env-overridable and get interpolated, and beyond the
injection argument, an abbreviated sha would defeat the point of pinning while
failing in a much less obvious place.
- the workflow's push path list is now identical to the pull_request one. It was
missing four paths, so a push to master touching only those would have skipped
re-verification.
- the checkouts set persist-credentials: false, so the token does not stay in
.git/config for the rest of the job.
- a concurrency group supersedes a stale PR run, but never cancels a master run,
whose whole purpose is to record that a commit was verified.
Not taken: reading VCPKG_COMMIT_ID and FLUTTER_VERSION from a shared .env. There
is no .env at the repo root, and the stock ci.yml and flutter-build.yml hardcode
those same two values, so this matches what is already there.
101 tests pass, both configs build.
CodeQL flagged the new workflow for not declaring permissions, which is fair:
every job here only checks out, builds and tests, and the artifact up/download
in the deb job authenticates with the runtime token rather than this one, so
contents: read is the whole requirement. Declared at the workflow level so the
reusable bridge workflow it calls inherits the same bound.
The stock workflows do not declare it either, but they are upstream's and this
feature does not touch them; a new file can start out right.
The root --service must never load libEGL/libGLESv2: the point of the split is
that it exports the scanout dma-buf and the unprivileged --server converts. Two
paths could still break that, both because the loader accepted a library too
old to export.
drm_prewarm() called grab() when the loaded .so had no drmtap_grab_desc, and
grab() maps and detiles, so the privileged process pulled in the vendor GL stack
at startup, before any consumer had asked for a frame. The per-connection
capture loop then did the same for every frame, through the CPU fallback.
The version guard could not prevent it: it compared the ABI major only, and this
library is still 0.x, so every release it has ever made passed. Add a floor at
0.4.9, where the split entry points landed, and require the three split symbols,
which also rejects a build that reports a new enough version without carrying
them. That is not hypothetical: a pre-release stamped 0.4.15 shipped without the
multi-GPU accessors. Both refusals fall back to PipeWire/portal and say which
file and which symbols, at warn level.
The split symbols are no longer Options, so the type system carries the
guarantee instead of a convention. What is left of the CPU path is only what it
was meant to be: the consumer has no render node of its own, or the seat exports
no transferable dma-buf. Both are facts about the hardware, with no alternative
that keeps the stream, and neither is a property of which file was on the load
path.
Verified against the real library on i915. With 0.4.15 the export path captures
a tiled XR30 scanout and libEGL stays out of /proc/self/maps, while the old
grab() branch maps it, so the finding reproduces. A stub reporting 0.4.8 and a
stub reporting 0.4.15 without the split symbols are both refused, each with its
own diagnostic. The mirrored repr(C) layouts are unchanged across 0.4.9 to
0.4.15, checked field by field against include/drmtap.h at both ends, so the
floor costs no compatibility that was real.
The service binds a stream to (device, crtc_id), which survives a topology change.
Everything on the consumer side addressed it by list index, which does not:
drm_enumerate_all_displays concatenates per-card lists, so plugging or unplugging a
monitor renumbers every display after it. Two consequences, one live and one
remembered.
Live: a running stream kept sending monitor A while the advertised list, and so the
client layout and the injected-input rect, had come to mean monitor B. It only
resolved if the stream happened to fail on its own. The stream now records what it
was bound to and ends itself when its index stops meaning that, which routes the
change through the rebuild the video service already does.
Remembered: the zero-frame failure counts and the prefer-cpu verdicts were keyed by
index too, so after a renumbering one monitor could inherit another's demotion or be
forced onto the CPU convert path for a mismatch that was never its own. Both are now
keyed by device plus connector name. The reasoning was already written down for one
of these, in the comment above the prefer-cpu clear, and applied only there.
That bulk clear is gone with it. It existed to limit the damage of index aliasing;
with identity keys it would instead throw away a correct verdict, which costs a real
convert failure to relearn, on every unrelated hotplug.
Also fixes the drm workflow to skip the two tests the stock CI already skips. Both
need a display server and fail on any headless runner, so the job would have gone
red for a reason that has nothing to do with this feature. Verified by running the
exact command: 88 tests, including the size_of::<Data>() assertion that the old
name filter was hiding.
flutter-build.yml goes back to upstream byte for byte. Three separate changes to
the stock release path disappear with it: the drm variant built inside the release
container, the snapshot and restore of the stock flutter bundle that existed only
to keep the drm relink out of the archlinux package, and the narrowing of the
publish glob to keep the consent-free deb off the public release.
The deb now builds in the drm workflow instead, which also removes the failure
mode the old placement forced: the whole block had to run in a subshell ending in
`|| echo WARN` so a drm-only breakage could not abort the stock publish steps,
which meant every failure in it, from the fetch to meson to packaging, kept the
job green and silently stopped producing the deb. A separate job can just fail.
The bridge generator is a reusable workflow, so this calls the stock one rather
than duplicating the codegen.
The deb is asserted rather than trusted: build.py can exit 0 without producing a
package, so the job checks the file exists and that it carries both the real
libdrmtap object and its soname symlink. It stays an artifact and never a release
deliverable, and it is built on the runner rather than in the old container the
stock debs use, so its glibc floor is higher than a released package.
The instruction was that nothing outside the feature should change while the
feature is off, and the runtime code honors that, but the build plumbing did not.
Start undoing that.
ci.yml goes back to upstream byte for byte. The drm test step it carried now lives
in a new workflow that only fires when a drm path changes, so a PR that does not
touch this backend pays nothing for it.
That new workflow also runs the whole rustdesk-crate test set with the feature on
rather than filtering by the `_drm` test names, because the name filter skipped
the sibling assertion that bounds `size_of::<Data>()`, which the new DmabufDesc
variant grows.
It gains a second job that fetches libdrmtap at the pinned commit, builds the .so
and then asserts the contract the runtime depends on: every symbol the loader
resolves, derived from the loader source so the two cannot drift, plus evidence
that the EGL detile path is really compiled in. libdrmtap degrades to a CPU-only
stub when the egl/glesv2 pkg-config files are absent on a build host, and nothing
downstream noticed. Note the check looks for the dlopen target name and the import
call, not for DT_NEEDED: EGL is loaded lazily on purpose so the privileged process
never links the vendor GL stack, so an ELF-level check reports a false negative on
a correct library.
libs/scrap/Cargo.toml keeps only the added feature: the unrelated blank line before
[dependencies.hwcodec] is restored, and the comment no longer describes DRMTAP_REF,
which no longer exists. The feature is now drm = ["wayland"] because all three drm
modules live inside the wayland arm of common/mod.rs, so scrap/drm alone compiled
nothing; it worked only because the root crate always enables scrap/wayland.
Point the DRM capture build at the libdrmtap v0.4.14 release commit
(816766dedaba3140c613712ce97aa2614e8899e7) instead of v0.4.13, in build.py and
the flutter-build workflow, and correct the scrap Cargo.toml note to describe
the actual DRMTAP_SHA anchor. 0.4.14 keeps the same public API, so the dlopen
consumer needs no change.
The _drm unit tests are behind the opt-in drm feature, which the default workspace
test job does not build, so they would sit in the tree unrun -- no better than no
tests. Add a Linux step to the per-PR ci.yml that runs them with the feature on,
alongside the existing ipc/auth tests. drm is a pure runtime-dlopen backend with no
link-time deps (no libdrm/EGL/gbm) and the tests are pure userspace (socketpair
framing, SCM_RIGHTS, the peer-auth/admission decisions), so this needs no GPU and no
extra system packages. The main build/test stays on default features, so the shipped
drm-off config remains the primary verified one.
The dlopened .so is loaded into the CAP_SYS_ADMIN root service, so it should come
from the maintainer-owned repo, not a personal fork. rustdesk-org/libdrmtap main is
already synced to the exact commit we pin (c9cf0938 = v0.4.13) but carries no release
tag, so point both build.py and the CI job at rustdesk-org and track main with the
immutable commit pinned via DRMTAP_SHA. The post-clone sha check makes this
fail-closed: main moving off the pinned commit fails the build instead of silently
swapping the .so. The CI ref guard now accepts a vX.Y.Z tag or main (a loose branch is
still rejected). Switch DRMTAP_REF to a tag if rustdesk-org later publishes one.
3.1: snapshot the stock flutter bundle before the CI drm relink and restore it
before makepkg, so the official Arch package ships the stock cdylib, not the
drm-enabled one. 4.2: wrap the drm block in a failure-tolerant subshell so a
drm-only failure no longer aborts the stock deb/rpm/arch publish. 4.3: narrow the
publish glob to rustdesk-[0-9]*.deb so the consent-bypass unattended-wayland deb
stays an artifact, not on the public release. 4.4: rewrite the three stale
DRM_CAPTURE_SECURITY.md statements to the split (default path passes a read-only
scanout dma-buf fd over SCM_RIGHTS with an import-once cache; export validation is
metadata-only; BGRA-over-the-wire is the fallback) and document that grab_desc's
fd is O_RDONLY (DRM_RDWR dropped upstream, dup preserves it). 4.7: only
short-circuit to the DRM cursor when it is authoritative (visible, or hidden in a
pure-DRM session); fall through to the normal cursor path in a mixed
DRM+PipeWire session. minors: thread the deb variant by feature not glob; TODO
for the ld.so.conf.d system path; drop a stray blank line. All gated or
whitespace so the drm-off build stays byte-identical.
the CI .so-prebuild step used the same bare 'drmtap' meson target that is
ambiguous since libdrmtap became both_libraries (0.4.11); ask for
drmtap:shared_library, matching build.py.
do not let an inherited DRMTAP_SHA override the verified commit in CI, so the
tag/commit pair is immutable there. build.py keeps the env override for local
forks.
1- verify the commit-SHA pin on a reused checkout too, not only on a fresh clone:
a stale or mismatched third_party/libdrmtap (e.g. from a failed clone) is now
removed and the build fails instead of silently reusing unpinned source.
2- default DRMTAP_REPO to the fork that actually publishes the pinned tag, so a
clean git clone --branch v0.4.13 resolves (and to the expected commit) instead of
failing on a repo that does not carry the tag.
1- make PipeWire init atomic: build every per-display capturer into owned staging
first and publish them to CAP_DISPLAY_INFO only after all succeed, so a mid-loop
Capturer::new failure neither leaves partial entries (which the next check_init
would treat as already-initialized) nor leaks the raw pointers already created.
2- pin the immutable libdrmtap commit, not just the tag: git clone --branch
follows a mutable tag, so verify the cloned HEAD equals DRMTAP_SHA in both the CI
workflow and build.py, failing on a moved/compromised tag.
3- drop the stale comment claiming a libdrmtap-sys crate pin (the drm backend has
no such dependency).
1- do not depend on the libdrmtap-sys crate for the pin: its build.rs statically
compiles the whole libdrmtap C tree and a CAP_SYS_ADMIN helper and links
-ldrm/-lseccomp/-lcap, which defeats the runtime-dlopen model. keep drm a pure
dlopen backend and pin the .so by the build.py DRMTAP_REF release tag, guarded by
a strict vX.Y.Z regex. drops the now-moot Cargo.lock freshness CI checks.
2- render-node-less consumers no longer lose the stream: the --server signals
need_cpu on DrmStart when it cannot open a convert context, and the --service
streams the CPU-converted frame path for that connection instead of a dma-buf fd
the consumer cannot detile (which used to fall through to a PipeWire path nobody
can approve on an unattended seat).
3- mark PipeWire initialized only after every per-display capturer is created, so
a partial failure retries instead of the flag falsely reporting a complete init.
4- reject a degenerate (zero width/height) or short CPU frame before it reaches
PixelBuffer::new (which derives stride as data.len()/height, dividing by zero).
5- keep the export-ledger epoch at DRM_DISPLAY_GENERATION so a hotplug invalidates
cached buffers (elision stays off until the recycled-fb_id inode case is handled).
6- validate the udev uevent source (kernel nl_pid, multicast) with recvmsg so a
local process cannot unicast a spoofed drm-change event to the root listener.
move the egl detile and rgba pack out of the root --service and into the
unprivileged --server. the root now calls only drmtap_open + drmtap_grab_desc
and exports a raw dma-buf fd; the fd rides the _drm channel over SCM_RIGHTS with
a small descriptor (geometry, per-plane offsets/pitches, modifier, hdr) instead
of the full rgba frame, dropping the per-frame copy. the --server imports the fd
with drmtap_open_render + drmtap_convert_dmabuf, keyed by the import-once egl
cache, and the render context is created and dropped on the recv thread.
the _drm transport moves off Framed<BytesCodec> (which cannot carry a fd) to a
bespoke sendmsg/recvmsg framing (DrmConn) that attaches one SCM_RIGHTS cmsg only
when a fd is present and rejects a truncated ancillary message. the split
symbols are bound optionally so an older libdrmtap still loads the cpu path, and
the whole thing degrades to the cpu BGRA path or PipeWire when no render node is
available. pins libdrmtap-sys to =0.4.13 with the Cargo.lock checksum. folds in
the DP-MST, ldconfig-restart and per-display PipeWire-fallback review fixes and a
udev hotplug refresh.
adds an opt-in `drm` feature for unattended remote access on Wayland: it
captures below the compositor via libdrmtap, so there is no
xdg-desktop-portal consent dialog and it works at the login screen.
off by default. when the feature is off the build is byte-identical.
everything is gated behind feature = "drm" or lives only in the separate
rustdesk-unattended-wayland deb, whose package name is the informed consent.
architecture (agreed with the maintainer): the capture runs inside the root
--service, which already holds the privilege it needs, and streams frames to
the user --server over a service-scoped _drm ipc channel. libdrmtap is loaded
with dlopen at runtime (no link-time dependency, so the base build is
unchanged and it still runs on ubuntu 18), and the .so is built in ci from the
rustdesk-org/libdrmtap fork and shipped only in the drm deb. no setcap helper.
- service: DrmReader reads scanout directly via the dlopen loader; an
IpcDrmCapturer serves _drm consumers with a per-connection capture worker;
durable availability cache + pre-warm to avoid enumerate/re-probe restarts
- capture: multi-display (targets the selected crtc), hardware cursor over
_drm, transient-errno retry with a bounded stall, rejects non-32bpp scanouts
before the frame copy
- robustness: only active, crtc-bound outputs are offered (an unbound
crtc_id=0 connector is filtered and a client-selected 0 is refused, both
fall back to pipewire); a per-display rapid-rebuild guard demotes a flapping
display to pipewire; per-display (not global) zero-frame failure tracking
- root-service hardening: bounded frame allocation and a concurrent-connection
cap so a malformed scanout or a buggy consumer cannot OOM or thread-exhaust
the service; a negative availability verdict expires so displays that appear
after startup recover without a --server restart; exactly-one .so selection
in the packaging so a stale object is never silently shipped
- build: libdrmtap.so cloned at build time from rustdesk-org/libdrmtap main
and bundled only for the --drm deb; ci builds a separate
rustdesk-unattended-wayland deb (incl. an ubuntu 18.04 container)
- DRM_CAPTURE_SECURITY.md: threat model and hardening notes
* fix: ci: macos: allow signed but not notarized dmg
Signed-off-by: Zhenyu FU <ysfcore@outlook.com>
* fix: ci: macos: add pre-check for macos identity
Signed-off-by: Zhenyu FU <ysfcore@outlook.com>
* merge notarize checking to existing steps
Signed-off-by: Zhenyu FU <ysfcore@outlook.com>
* harden wf_cliprdr.c
* fix copilot review
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* fix review
* fix review
* condense hardening comments, fix style in wf_cliprdr.c
Comment-only cleanup of the review-justification comments; also move
the mutex wait result declaration to the top of the block and fix
continuation-line indentation. No behavior change.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* add invariant tests for file contents request/response hardening
Cover the zeroed optional request fields, stream ID filtering,
oversized/NULL response rejection and the zero-byte EOF path.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* address copilot review findings in wf_cliprdr.c
- Reject a negative FILECONTENTS_SIZE result: m_lSize is unsigned, so a
negative value became a huge bogus stream size that keeps reads going.
- Use a unique per-stream counter as the CLIPRDR streamId instead of a
truncated IStream pointer, which could collide or be reused after free
(and leaked heap addresses to the peer).
- Add req_f_request_mutex to serialize whole file-contents request/response
cycles, enforcing the previously assumed one-outstanding-request
invariant when multiple streams are read concurrently. Bounded acquire
so a wedged request fails the read instead of hanging a consumer.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* serialize file-contents request state and poison streams after timeout
- Extract lock_mutex() for the WAIT_OBJECT_0/WAIT_ABANDONED idiom shared by
take_req_fdata, the request-serialization acquire, and the response handler.
- Collapse the acquire/send/take/release cycle into
cliprdr_request_filecontents_sync(), used by CliprdrStream_Read and the size
probe in CliprdrStream_New.
- Publish req_f_stream_id_expected/req_f_size_requested under req_f_mutex in the
sender and read them under the same lock in the response handler, removing the
cross-thread data race on those fields.
- Poison a stream (m_failed) after a request fails/times out, so a late response
carrying a previous offset's bytes cannot satisfy a later same-stream read.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* key the responder stream cache on connID as well as streamId
Per-stream ids restart from 1 in each peer process, so two connections can
emit the same streamId. The process-static pStreamStc cache keyed only on
streamId could then serve one peer the IStream cached for another peer (a
different file), silently returning wrong-file bytes. Add connID to the key.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* harden the format-data path against late/duplicate responses
The format-data rendezvous had the same single-slot race the file-contents
path just fixed: the channel thread rewrote clipboard->hmem with no lock while
explorer-thread consumers read/freed it, nothing serialized concurrent
requests, and no flag told an expected response from a stray one.
- Add format_request_mutex (serializes the whole request/response cycle) and
hmem_mutex (guards the hmem hand-off and formatDataRespExpected).
- cliprdr_send_data_request now takes ownership of the response buffer under
hmem_mutex and returns it to the caller, so a later response cannot touch a
buffer a consumer is using. All three consumers (GetData, WM_RENDERFORMAT,
DELAYED_RENDERING) and the WM_CLIPBOARDUPDATE cleanup use the returned/taken
handle instead of the shared slot.
- The response handler drops any response arriving while formatDataRespExpected
is clear (late/duplicate/unsolicited), consumes the flag on the first
response, and no longer dereferences a NULL clipboard in the SetEvent path.
Pre-existing issue, not introduced by this branch; generalizes the
file-contents hardening to the format-data path.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* remove the dedicated wf-cliprdr CI workflow
Drop .github/workflows/wf-cliprdr-ci.yml on this branch as requested.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* remove wf-cliprdr invariant tests
Drop tests/test_invariant_wf_cliprdr.c on this branch as requested.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor and simplify, remove mutex which is dangeours
* fix copilot false report
* fix review
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Add initial arm64 build logic
Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
* Upgrade Flutter to 3.44.0 and introduce Windows arm64 in CI
Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
* Bump bridge build to Flutter 3.44 as well
Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
* Fix install flutter step for Win arm64
* Bump install-llvm-action to v2 for arm64 support
* Fix libsodium logic to only install through vcpkg on win arm64
* Fix Flutter installations on Win
* Flutter XCode: only build the current arch as it defaults to universal
Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
* Ensure that we really have arm64 Dart + Flutter engine in CI
Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
* Enable hwcodec feature now that upstream supports building it
Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
* CI: improve logic for getting Flutter arm64 SDK
Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
* Apply PR feedback (only bump Flutter version on Win arm64)
* Exclude MSI build on arm64
* CI: build the MSI for Windows arm64 (WiX v4 ARM64 platform + native CustomActions)
* Address PR feedback
* Update Cargo.toml
* Update Cargo.lock
* Update Cargo.lock
* Add Flutter 3.44 DialogThemeData background colors
Signed-off-by: 21pages <sunboeasy@gmail.com>
---------
Signed-off-by: Dennis Ameling <dennis@dennisameling.com>
Signed-off-by: 21pages <sunboeasy@gmail.com>
Co-authored-by: RustDesk <71636191+rustdesk@users.noreply.github.com>
Co-authored-by: 21pages <sunboeasy@gmail.com>
