From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 013F7C433E0 for ; Mon, 1 Feb 2021 15:29:27 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5939664D9E for ; Mon, 1 Feb 2021 15:29:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5939664D9E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:57256 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l6b8n-0006Yk-D6 for qemu-devel@archiver.kernel.org; Mon, 01 Feb 2021 10:29:25 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37992) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l6b7P-0004yw-Fp for qemu-devel@nongnu.org; Mon, 01 Feb 2021 10:28:00 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:45895) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1l6b7K-0006Sy-Un for qemu-devel@nongnu.org; Mon, 01 Feb 2021 10:27:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612193272; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+0ilT53hkZpySuFB+rwGxLMi9hVHWVmpfYC0UqC1vFI=; b=MfadR0CJylvnv8d1ASjkmDNq4+qtvN9QbxPkXOXYs4T4r2VBqJRskCtdVM2+2ZlJxSVjvK +wWQgS8cjsEX2nlcJ2IdzFD9g8wxcgpGXsqBa/w9ScREdy4qmY/Bx+dJojBsYVO7PnU71H CxRCwpdpgv8g1zgUbdlFadsc6HlBi8o= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-336--i98PW7zMw6iD-Ucrq8xYQ-1; Mon, 01 Feb 2021 10:27:47 -0500 X-MC-Unique: -i98PW7zMw6iD-Ucrq8xYQ-1 Received: by mail-wm1-f70.google.com with SMTP id r13so801488wmq.9 for ; Mon, 01 Feb 2021 07:27:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=txJeRMsHhQRGpcSbMyTjj6TxuH17zGi6S/lK4IEkkXs=; b=mdItSZurqUmsx7fjkfS05zyahbSLYebxVd5PfYZA+kCFIb/M5uDn8r1uiF7wzUCKtu Fpp2MSyMoqOk1BYG0GNDtTWMn8mOdr/YeYJUqeNQvOcEpKbV/0fvXC2V6C90E0K1KLzz X34yShcIzPNJSzLjtdcwq5txaYjcpMFTzOey2xDBm9J1wrWz5Cx2ucv394HKwxVlOH3k DakYvilwR4Y0Ag0pPXs1rRNsDLUzDFGJ8r1GV1soMA3B7VhA4PYL7jPUuPwlzuzGvkpq rs2z5q21xIC/SUgqhpnNDefRYC24TWtYZRmoqpYmeDrwuQrimyWJInw23b/Z1KgYcic+ Il7Q== X-Gm-Message-State: AOAM531mXeXR4l6yH1VKItLOmzn89jdY68kFl09QW6IHiyDUQz7kukZO nCllRSOde+9RV3DyKCOYbZb01Ndm1M+uP1ZAAXQ6X5khKgPZ8WhzGimXynrf9T3ovXbmUkbw9Cg pJiOb0zF8oC4/8Cw= X-Received: by 2002:a5d:5502:: with SMTP id b2mr18840563wrv.245.1612193266005; Mon, 01 Feb 2021 07:27:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJwJWWWzzhrzhYwSezkd+J0BeEHhA6cHmxpZ7VZX0FXUzE2nYqWhH6mS7OIX+gSANuw/M7H8VQ== X-Received: by 2002:a5d:5502:: with SMTP id b2mr18840540wrv.245.1612193265725; Mon, 01 Feb 2021 07:27:45 -0800 (PST) Received: from ?IPv6:2a01:e0a:466:71c0:4dc8:c97f:f933:8921? ([2a01:e0a:466:71c0:4dc8:c97f:f933:8921]) by smtp.gmail.com with ESMTPSA id n9sm27574326wrq.41.2021.02.01.07.27.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Feb 2021 07:27:44 -0800 (PST) From: Christophe de Dinechin Message-Id: <05C58667-D9BA-49E2-897D-2286B243E802@redhat.com> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: vnc clipboard support Date: Mon, 1 Feb 2021 16:27:43 +0100 In-Reply-To: <20210129143252.GE4008275@redhat.com> To: =?utf-8?B?IkRhbmllbCBQLiBCZXJyYW5nw6ki?= References: <20210128171224.exbklnwtyb232oe2@sirius.home.kraxel.org> <20210129080323.xuvokq5kytoomx6j@sirius.home.kraxel.org> <8E05F8C9-A60D-45A9-AFCB-79D866F57660@redhat.com> <20210129110814.GF4001740@redhat.com> <0F802343-19F8-487C-8BBE-5BBE2014BA1C@redhat.com> <20210129143252.GE4008275@redhat.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=cdupontd@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="Apple-Mail=_C6BA6564-9519-4CFA-90F1-B945BD456A65" Received-SPF: pass client-ip=63.128.21.124; envelope-from=cdupontd@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -30 X-Spam_score: -3.1 X-Spam_bar: --- X-Spam_report: (-3.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.351, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Gerd Hoffmann , qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --Apple-Mail=_C6BA6564-9519-4CFA-90F1-B945BD456A65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 29 Jan 2021, at 15:32, Daniel P. Berrang=C3=A9 w= rote: >=20 > On Fri, Jan 29, 2021 at 03:19:45PM +0100, Christophe de Dinechin wrote: >>=20 >>=20 >>> On 29 Jan 2021, at 12:08, Daniel P. Berrang=C3=A9 = wrote: >>>=20 >>> On Fri, Jan 29, 2021 at 11:50:10AM +0100, Christophe de Dinechin wrote: >>>>=20 >>>>=20 >>>>> On 29 Jan 2021, at 09:03, Gerd Hoffmann wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>>>> (1) Have some guest agent (spice does it that way). >>>>>>> Advantage: more flexible, allows more features. >>>>>>> Disadvantage: requires agent in the guest. >>>>>>=20 >>>>>> What about running the option to relay data to a VNC server in the >>>>>> guest if there is one running? In other words, using an existing >>>>>> VNC server as an agent, with the option of having a stripped-down, >>>>>> clipboard only VNC server as a later optimization. >>>>>=20 >>>>> Well, if you run Xvnc in the guest anyway why use the qemu vnc server >>>>> in the first place? >>>>=20 >>>> I assume that if you use the qemu VNC, it's because you you don't want= to >>>> run Xvnc on some external network, or care about accessing the guest >>>> before Xvnc can be launched. There can be many reasons. >>>>=20 >>>> Again, I want to make it clear that my suggestion is _not_ simply to a= ccess >>>> the existing Xvnc as is, but rather to stick with some VNC server code= to handle >>>> the clipboard if / when possible. >>>>=20 >>>> Let me try to imagine a scenario, where I'll use a macOS guest intenti= onally >>>> to clarify what I was thinking about. >>>>=20 >>>> - During early boot, there is no in-guest VNC server, so to address th= at, >>>> you connect to the qemu VNC. At this stage, all screen refresh is hand= led >>>> by the qemu VNC, and the best you can do if you want to support any >>>> kind of copy-paste is to convert it to virtual keystrokes. The same wo= uld >>>> be true for Linux on a text console. >>>>=20 >>>> - Then comes up you macOS guest, and it still has no VNC port open, >>>> so you are stuck with qemu-vnc doing all the work. But now you can >>>> enable screen sharing, and that launches the Apple-maintained macOS >>>> VNC server. >>>>=20 >>>> - Let's assume for illustration that this listens on some private netw= ork >>>> that qemu can access, but that is not visible externally. In this case= , >>>> you could not VNC to the guest, but you can still VNC to qemu. >>>>=20 >>>> - What I'm suggesting is that qemu-vnc could then switch to simply >>>> relaying VNC traffic to that in-guest server. You'd get the smart upda= te >>>> algorithm that Apple has put in place to deal with transparency and th= e >>>> like, as well as a level of guest OS integration that would otherwise = be >>>> much harder to replicate. >>>=20 >>> IMHO that's an awful lot of complexity to add to the system >>> that isn't especially useful and this opens up new attack >>> vectors for the guest to exploit the host. >>>=20 >>> If people have VNC/RDP/whatever configured inside their guest >>> OS, then there's really little to no reason for them to want >>> to connect to the QEMU VNC server, as viewing initial bootup >>> phase is not required in normal case. The only time such >>> people will need to use the QEMU VNC server is if the guest >>> OS has broken in some way before it fully booted and thus failed >>> to start the guest VNC server. There is no guest VNC server >>> to hand off to in this scenario. >>=20 >> It's a matter of what you want to do with that qemu vnc. >>=20 >> If it's only a backup when there's nothing in the guest to help, >> then maybe trying to support copy-paste is not a good idea. >>=20 >> If it's a standard go-to access point for connecting to your >> guest, then making it smart is hard, but useful. >>=20 >>>=20 >>> The value of the QEMU host side VNC server is that it works >>> for all possible guest OS, no matter whether they are running >>> normally or broken, regardless of what the guest admin has >>> configured in terms of guest level remote desktop. >>=20 >> Understood. >>=20 >> The downside is that there are things it can't do. It cannot correctly >> determine the keyboard map, because that's controlled in software >> in the guest. >=20 > There is no need for the remote desktop server to care about the > keymap. The remote client takes scancodes and passes them to the > server, which then passes them to the guest. Aren't we talking about pasting clipboard data here? I assume that clipboard data is not encoded as scancodes. >=20 > The person connected to the remote server simply has to configure > their guest OS keymap to match the physical keyboard they currently > have plugged in. >=20 > The only reason a remote server would need to know the keymap is > if it was trying to translate from keycodes back into scancodes. > This is what VNC protocol had to do originally, but VNC was since > extended to pass raw scancodes instead of keycodes, precisely to > avoid needing to care about keymaps. >=20 >>> IOW, if you have a guest remote desktop solution you'll just >>> use that 99% of the time. If you don't have that, then you'll >>> use QEMU VNC/SPICE server, and there won't be anything in the >>> guest for that to proxy to/from. >>=20 >> If really the assumption is there is nothing in the guest to help >> us, then I'd say "paste" should come up with a warning "do you want >> me to try and translate that into keystrokes", and I don't see how to >> implement copy from a graphical display without OCR=E2=80=A6 >=20 > I'm not saying we can't use stuff in the guest, just that we should be > pragmatic about what we interact with in the guest and degrade nicely. > I don't think that proxying from a host VNC server to a guest VNC server > is sensible, but making use of a guest agent of some kind is not > unreasonable, especially if we can use one that already exists. >=20 >=20 > Regards, > Daniel > --=20 > |: https://berrange.com -o- https://www.f= lickr.com/photos/dberrange :| > |: https://libvirt.org -o- http= s://fstop138.berrange.com :| > |: https://entangle-photo.org -o- htt= ps://www.instagram.com/dberrange :| --Apple-Mail=_C6BA6564-9519-4CFA-90F1-B945BD456A65 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 29 Jan 202= 1, at 15:32, Daniel P. Berrang=C3=A9 <berrange@redhat.com> wrote:

On Fri, Jan 29, 2021 at 03:19:45PM +0100, Christophe de Dinechin wrot= e:


On 29 Jan 2021,= at 12:08, Daniel P. Berrang=C3=A9 <berrange@redhat.com> wrote:

On Fri, Jan 29, 2021 at 11:50:10AM +0100, Christophe de Dinechin wrote:<= br class=3D"">


On 29 Jan 2021, at 09:03, Gerd H= offmann <kraxel@redhat.c= om> wrote:

Hi,

(1) Have some guest agent (spice does it that way).
&nb= sp; Advantage: more flexible, allows more features.
&nbs= p; Disadvantage: requires agent in the guest.

What about running the option to relay data to a VNC serv= er in the
guest if there is one running? In other words, usin= g an existing
VNC server as an agent, with the option of havi= ng a stripped-down,
clipboard only VNC server as a later opti= mization.

Well, if you run Xvnc i= n the guest anyway why use the qemu vnc server
in the first p= lace?

I assume that if you use th= e qemu VNC, it's because you you don't want to
run Xvnc on so= me external network, or care about accessing the guest
before= Xvnc can be launched. There can be many reasons.

Again, I want to make it clear that my suggestion is _not_ simply to = access
the existing Xvnc as is, but rather to stick with some= VNC server code to handle
the clipboard if / when possible.<= br class=3D"">
Let me try to imagine a scenario, where I'll u= se a macOS guest intentionally
to clarify what I was thinking= about.

- During early boot, there is no in-gu= est VNC server, so to address that,
you connect to the qemu V= NC. At this stage, all screen refresh is handled
by the qemu = VNC, and the best you can do if you want to support any
kind = of copy-paste is to convert it to virtual keystrokes. The same would
be true for Linux on a text console.

-= Then comes up you macOS guest, and it still has no VNC port open,
so you are stuck with qemu-vnc doing all the work. But now you canenable screen sharing, and that launches the Apple-maintained m= acOS
VNC server.

- Let's assume = for illustration that this listens on some private network
th= at qemu can access, but that is not visible externally. In this case,
you could not VNC to the guest, but you can still VNC to qemu.

- What I'm suggesting is that qemu-vnc could then= switch to simply
relaying VNC traffic to that in-guest serve= r. You'd get the smart update
algorithm that Apple has put in= place to deal with transparency and the
like, as well as a l= evel of guest OS integration that would otherwise be
much har= der to replicate.

IMHO that's an = awful lot of complexity to add to the system
that isn't espec= ially useful and this opens up new attack
vectors for the gue= st to exploit the host.

If people have VNC/RDP= /whatever configured inside their guest
OS, then there's real= ly little to no reason for them to want
to connect to the QEM= U VNC server, as viewing initial bootup
phase is not required= in normal case. The only time such
people will need to use t= he QEMU VNC server is if the guest
OS has broken in some way = before it fully booted and thus failed
to start the guest VNC= server. There is no guest VNC server
to hand off to in this = scenario.

It's a matter of what y= ou want to do with that qemu vnc.

If it's only= a backup when there's nothing in the guest to help,
then may= be trying to support copy-paste is not a good idea.

If it's a standard go-to access point for connecting to your
guest, then making it smart is hard, but useful.


The value of t= he QEMU host side VNC server is that it works
for all possibl= e guest OS, no matter whether they are running
normally or br= oken, regardless of what the guest admin has
configured in te= rms of guest level remote desktop.

Understood.

The downside is that there are t= hings it can't do. It cannot correctly
determine the keyboard= map, because that's controlled in software
in the guest.

Ther= e is no need for the remote desktop server to care about the
keymap. The remote client takes scanc= odes and passes them to the
server, which then passes them to the guest.

Aren= 't we talking about pasting clipboard data here?
I assume that cl= ipboard data is not encoded as scancodes.



The person connected to the= remote server simply has to configure
their guest OS keymap to match the physical keyboard they c= urrently
have plugged i= n.

The only reason a remote server would need to know the k= eymap is
if it was tryi= ng to translate from keycodes back into scancodes.
This is what VNC protocol had to do originally,= but VNC was since
exte= nded to pass raw scancodes instead of keycodes, precisely to
avoid needing to care about keymaps.<= /span>

IOW, if y= ou have a guest remote desktop solution you'll just
use that = 99% of the time. If you don't have that, then you'll
use QEMU= VNC/SPICE server, and there won't be anything in the
guest f= or that to proxy to/from.

If real= ly the assumption is there is nothing in the guest to help
us= , then I'd say "paste" should come up with a warning "do you want
me to try and translate that into keystrokes", and I don't see how to=
implement copy from a graphical display without OCR=E2=80=A6=

I= 'm not saying we can't use stuff in the guest, just that we should be
pragmatic about what we inte= ract with in the guest and degrade nicely.
I don't think that proxying from a host VNC server to a= guest VNC server
is s= ensible, but making use of a guest agent of some kind is not
unreasonable, especially if we can us= e one that already exists.

= Regards,
Daniel<= /span>
-- 
|: ht= tps://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-  &n= bsp;         https://fstop138.berrange.com :|
|: ht= tps://entangle-photo.org&n= bsp;   -o-    https://www.instagram.com/dberrange :|

--Apple-Mail=_C6BA6564-9519-4CFA-90F1-B945BD456A65--