On Fri, Mar 07, 2025 at 04:22:46PM +0100, Martin Kletzander wrote:
On Tue, Feb 18, 2025 at 02:16:05PM +0400, marcandre.lureau@xxxxxxxxxx wrote:From: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx> Hi, This patch series offers an out-of-process Remote Desktop Protocol (RDP) server solution utilizing QEMU's -display dbus interface, offering improved modularity and potential security benefits compared to built-in server. This initiative was spearheaded by Mihnea Buzatu during the QEMU Summer of Code 2023. The project's goal was to develop an out-of-process RDP server using the -display dbus interface, implemented in Rust. Given that the IronRDP crate lacked some server support at the time, investments in IronRDP were required. I finally released an initial v0.1 version of qemu-rdp on crates.io (https://crates.io/crates/qemu-rdp). That should allow more people to review and evaluate the state of this work. On unix systems, with cargo/rust toolchain installed, it should be as easy as running "cargo install qemu-rdp", apply this patch series for libvirt, set the "rdp_tls_x509_cert_dir" location for your TLS certificates, and configure a VM with both dbus & rdp graphics (run "virsh domdisplay DOMAIN" to get the display connection details). Thanks for the reviews & feedback! v2: thanks to Daniel review - drop extra error report from "qemu: report an error for unsupported graphics" - replace g_return pre-conditions with ATTRIBUTE_NONNULL - improve "qemu/dbus: keep a connection to the VM D-Bus" to also reconnect - use domainLogContext for logging (for virtiofs as well) - check for qemu-rdp availabilty for setting 'rdp' capability - make dbus-addr qemu-rdp capability mandatory - rebased - add r-b tags Marc-André Lureau (21): build-sys: drop -Winline when optimization=g build: fix -Werror=maybe-uninitialized qemu-slirp: drop unneeded check for OOM util: annotate non-null arguments for virGDBusCallMethod() qemu: fall-through for unsupported graphics qemu: add rdp state directory qemu: add qemu RDP configuration conf: parse optional RDP username & password conf: generalize virDomainDefHasSpiceGraphics qemu: use virDomainDefHasGraphics qemu: add RDP ports range allocator qemu: limit to one <graphics type='rdp'> qemu/virtiofs: use domainLogContext qemu/dbus: keep a connection to the VM D-Bus qemu/dbus: log daemon stdout/err, use domainLogContext qemu: validate RDP configuration qemu: add qemu-rdp helper unit qemu: pass virQEMUDriverConfig to capabilities qemu: add 'rdp' capability if qemu-rdp is available qemu: add RDP support tests: add qemu <graphics type='rdp'/> testWithout testing it (yet, I want to try it next week), without deep knowledge of D-Bus details and ideally with the teeny tiny details adjusted: Reviewed-by: Martin Kletzander <mkletzan@xxxxxxxxxx>
So I tried testing it and I found a couple of issues. Those might be on
my side, maybe caused by misunderstanding of it all. First of all
<graphics type='dbus'/> fails with these patches for me even without
<graphics type='rdp'/>. That might be the source of all other issues,
but since I was not sure whether to use p2p='yes' or
address='unix:path=...' I tried both. When address is specified qemu
tries to connect to it, so that's not the right approach. When I
specify p2p='yes' then the VM starts. If I add the RDP graphics I get a
"confusing" error message:
error: unsupported configuration: qemu-rdp support requires a D-Bus bus
graphics device.
which should probably say "qemu-rdp support requires a non-p2p dbus
graphics device" instead since it is looking for a p2p='no' dbus
graphics.
If I delay the checking of qemu-rdp running I find out that it fails
right away. It cannot connect to the unix socket, so I tried just
running qemu VM with dbus graphics and qemu-rdp manually, but that
failed on the missing certificate files. That could be checked before
blindly passing it down to the helper, too (even though I was running it
manually this time it reminded me of that possibility).
Ideally some handshake could confirm it is actually running. If not a
handshake, then maybe waiting whether it listens on where it is supposed
to or some other indication of it being started while checking that the
PID exists, so that it is not a dumb delay.
Even running it manually I cannot verify it works, but that's probably a
client-side issue?
Server output when trying rdesktop:
Waiting for org.qemu...
Starting RDP server, args: ServerArgs { bind_address: 0.0.0.0:3389, cert: None, key: None, remotefx: Disable }
Cert: "/home/nert/.config/qemu-rdp/server-cert.pem", Key: "/home/nert/.config/qemu-rdp/server-key.pem"
2025-03-11T13:21:00.350891Z ERROR ironrdp_server::server: Connection error error=[no credentials while doing credssp] general error
2025-03-11T13:21:00.352401Z ERROR ironrdp_server::server: Connection error error=accept_begin failed
Caused by:
[failed to negotiate security protocol] general error
sdl-freerdp client output (no error on the server side reported):
[14:24:35:046] [449399:0006db7b] [ERROR][com.freerdp.core.transport] - [transport_default_write]: BIO_should_retry returned a system error 32: Broken pipe
rdesktop client output:
Failed to initialize NLA, do you have correct Kerberos TGT initialized ?
Core(error): rcp_recv(), connection closed by peer
===
Anyway, I'm clearly doing something wrong, but there are some issues in
the code as well and from the greater picture it should not be this
complicated to test it out, should it? I can test out other patches
from you if you want, and I am open to hearing tips on what I'm doing
wrong.
Have a nice day,
Martin
Attachment:
signature.asc
Description: PGP signature
