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.0 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 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 21CA4C433DB for ; Fri, 29 Jan 2021 14:21:34 +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 37B2964DF1 for ; Fri, 29 Jan 2021 14:21:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 37B2964DF1 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]:56870 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l5UeS-0005fv-6T for qemu-devel@archiver.kernel.org; Fri, 29 Jan 2021 09:21:32 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41332) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l5Ucu-0004rs-Rl for qemu-devel@nongnu.org; Fri, 29 Jan 2021 09:19:56 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:53284) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1l5Ucs-0006Tj-HC for qemu-devel@nongnu.org; Fri, 29 Jan 2021 09:19:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611929993; 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=ugptNDrAHvincwgwWOXRzYr/MfEMQEDsXOOn3budy0s=; b=Dw//SzaID1gPhpj4B2voNc2aUHPBrcYOKHBg8hAOWpBEkyphCIwkhgtbG6waDyeSIp+SiG Jz26G6Y7Hay2CUyEhipMbW01itzy0VqtU3nGRfP1IoeGsDQrXYkszNO93y6Bjo5b6lmqc+ ykYF60cievlZBDpLZzFelp5K12ATMkQ= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-4-iSRGINF4OIOHHmnO-hnAGA-1; Fri, 29 Jan 2021 09:19:50 -0500 X-MC-Unique: iSRGINF4OIOHHmnO-hnAGA-1 Received: by mail-wr1-f72.google.com with SMTP id n15so5207149wrv.20 for ; Fri, 29 Jan 2021 06:19:50 -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=UwbUVRtdlvkwGmsnOelrmgbyBhI3Pzf/jdfCTwxbZ+g=; b=mi65rBevB+lJLdyb3y04rQly4wE4jIifGfUuOGpfKsOo1sq3I928uU+IiMongiNnj3 DXGEIz7SHrduaGyTFX9ZgA+3XepHQ/moYs8enJUIKonSbj5e97QXnAhoDhu3MfQhuChA daJwS5wF8TYvT/8iGWet2h4ysGE4HXruuNwNFZO/8GT7kb0aVzgc402WOyy5PLAug9CR RqQuXn8ibKkBo0Z2fv7Z5e1dDx3aaZ3uuxWn7tLvxn4oJxeIYxhzjANO1LDD66fuVhGE NnUP2DiwHkFVLRr4EYPoWVgmxqhe5EHZ/stoIk0Tx9bpTs+jTCHWBapIct82GBkjqEsk fTNw== X-Gm-Message-State: AOAM53288DqW3pobss+NKuyWZPlQI/tfvYXjaCXEsF1YvPJHFnmHXQXh cZnOKU/LhHzNcinN2SGxtibhGaBgCndEfl1BM+4WdGVWNi8a5cWAj36XKZBW8HwhetTrCYsGc5b VakU30ATptPJRbCY= X-Received: by 2002:a1c:1f58:: with SMTP id f85mr3787823wmf.82.1611929988954; Fri, 29 Jan 2021 06:19:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJxfjYmBb67BIlzc3X0PXuMUggCd9sv/vmfrZHI9PN6KGYm4MTQsXVfLTZGAo9MBl8TaZA+t1g== X-Received: by 2002:a1c:1f58:: with SMTP id f85mr3787806wmf.82.1611929988675; Fri, 29 Jan 2021 06:19:48 -0800 (PST) Received: from ?IPv6:2a01:e0a:466:71c0:b806:f900:b9dc:9b2b? ([2a01:e0a:466:71c0:b806:f900:b9dc:9b2b]) by smtp.gmail.com with ESMTPSA id n5sm8857343wmq.7.2021.01.29.06.19.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jan 2021 06:19:47 -0800 (PST) From: Christophe de Dinechin Message-Id: <0F802343-19F8-487C-8BBE-5BBE2014BA1C@redhat.com> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: vnc clipboard support Date: Fri, 29 Jan 2021 15:19:45 +0100 In-Reply-To: <20210129110814.GF4001740@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> 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=_409A7FEA-59A1-4B26-8B47-7E30A71E670F" Received-SPF: pass client-ip=170.10.133.124; envelope-from=cdupontd@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.249, 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, 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=_409A7FEA-59A1-4B26-8B47-7E30A71E670F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 29 Jan 2021, at 12:08, Daniel P. Berrang=C3=A9 w= rote: >=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 t= o >> 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 acc= ess >> the existing Xvnc as is, but rather to stick with some VNC server code t= o handle >> the clipboard if / when possible. >>=20 >> Let me try to imagine a scenario, where I'll use a macOS guest intention= ally >> to clarify what I was thinking about. >>=20 >> - During early boot, there is no in-guest VNC server, so to address that= , >> you connect to the qemu VNC. At this stage, all screen refresh is handle= d >> 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 woul= d >> 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 networ= k >> 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 update >> algorithm that Apple has put in place to deal with transparency and the >> 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. It's a matter of what you want to do with that qemu vnc. 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. If it's a standard go-to access point for connecting to your guest, then making it smart is hard, but useful. >=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. Understood. 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. Unless we para-virtualize the keyboard? >=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. 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 Cheers Christophe --Apple-Mail=_409A7FEA-59A1-4B26-8B47-7E30A71E670F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 29 Jan 202= 1, 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 wrot= e:


On 29 Jan 2021,= at 09:03, Gerd Hoffmann <kraxel@redhat.com> wrote:

Hi,

(1) Have some guest agent (spice does it that way).   Advantage: more flexible, allows more feature= s.
   Disadvantage: requires agent in the gues= t.

What about running the option = to relay data to a VNC server in the
guest if there is one ru= nning? In other words, using an existing
VNC server as an age= nt, with the option of having a stripped-down,
clipboard only= VNC server as a later optimization.

Well, if you run Xvnc in the guest anyway why use the qemu vnc server=
in the first place?

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 t= he guest
before Xvnc can be launched. There can be many reaso= ns.

Again, I want to make it clear that my sug= gestion is _not_ simply to access
the existing Xvnc as is, bu= t rather to stick with some VNC server code to handle
the cli= pboard if / when possible.

Let me try to imagi= ne a scenario, where I'll use a macOS guest intentionally
to = clarify what I was thinking about.

- During ea= rly boot, there is no in-guest VNC server, so to address that,
you connect to the qemu VNC. At this stage, all screen refresh is handled=
by the qemu VNC, and the best you can do if you want to supp= ort any
kind of copy-paste is to convert it to virtual keystr= okes. 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 t= he work. But now you can
enable screen sharing, and that laun= ches the Apple-maintained macOS
VNC server.
- Let's assume for illustration that this listens on some priva= te network
that qemu can access, but that is not visible exte= rnally. 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 tra= ffic to that in-guest server. You'd get the smart update
algo= rithm that Apple has put in place to deal with transparency and the
like, as well as a level of guest OS integration that would otherwis= e be
much harder to replicate.
IMHO that's an awful lot of comp= lexity to add to the system
that isn't especially useful and this opens up new attack
vectors for the guest to exploit t= he host.

If people have VNC/RDP/whatever configured inside = their guest
OS, then th= ere's really little to no reason for them to want
to connect to the QEMU VNC server, as viewing in= itial bootup
phase is n= ot required in normal case. The only time such
people will need to use the QEMU VNC server is if t= he guest
OS has broken = in some way before it fully booted and thus failed
to start the guest VNC server. There is no gues= t VNC server
to hand of= f to in this scenario.
<= /blockquote>

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

If it's only a back= up when there's nothing in the guest to help,
then maybe trying t= o 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 the QEMU host side VNC se= rver is that it works
f= or all possible guest OS, no matter whether they are running
normally or broken, regardless of wha= t the guest admin has
c= onfigured in terms of guest level remote desktop.

Under= stood.

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.
<= br class=3D"">
Unless we para-virtualize the keyboard?
=
<= br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 1= 8px; font-style: normal; font-variant-caps: normal; font-weight: normal; le= tter-spacing: normal; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0p= x; text-decoration: none;" class=3D"">IOW, if you have a guest remot= e 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, a= nd there won't be anything in the
guest for that to proxy to/from.

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


Cheers
Christophe=

--Apple-Mail=_409A7FEA-59A1-4B26-8B47-7E30A71E670F--