[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Whither qemu's ssh driver?
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] Whither qemu's ssh driver? |
Date: |
Mon, 08 Apr 2019 20:07:00 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
"Richard W.M. Jones" <address@hidden> writes:
> I don't know much about this patch which looks like internal qemu
> rearrangements so I guess fine. However I do have a few things to say
> about the ssh driver ...
>
> As you know I wrote this a few years ago, and it uses libssh2.
> libssh2 has not evolved as quickly as we'd like and it may be better
> to use libssh instead -- despite the names, these are two separate and
> unrelated libraries. libssh supports a wider range of SSH encryption
> and has more features. It's generally more likely to work against a
> random SSH server. It has also been through the FIPS process. Indeed
> Red Hat made the decision to switch exclusively to libssh in RHEL 8,
> if that carries any weight.
>
> Pino posted a libssh2 -> libssh conversion patch a while back, but it
> has been somewhat stuck in review. If I recall the latest concern was
> whether it performs as well as the libssh2 version.
>
> https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg07267.html
I doubt we'd need "as well as" for this driver. But Max observed a
factor of five with v4. Pino reported improvements with v5 ("no more
than 200%"), and some more with libssh master instead of 0.7, but didn't
quantify those. To make progress, we need a rebased patch with actual
performance numbers, I think.
> In the meantime I added libssh support to nbdkit. nbdkit can be used
> as a complete replacement for qemu's ssh driver.
>
> nbdkit ssh host=foo.example.com disk.img -U tmpdirXXXXXX/sock
> qemu -hda nbd:unix:tmpdirXXXXXX/sock
>
> In fact it's somewhat superior (IMHO) because all of the tricky code
> handling libssh runs outside qemu in a separate process, improving
> isolation and potentially allowing separate, restrictive security
> policies to be applied. For example it would no longer be necessary
> to give qemu permission to connect to remote SSH servers.
Good point.
> Could we make this really smooth somehow? nbdkit has a concept
> [https://www.mankier.com/1/nbdkit-captive] where we make it easy to
> manage external commands owned by nbdkit. Is there an equivalent
> feature of qemu where:
>
> qemu -object exec,id=nbd1,cmd='nbdkit -f -U $sock ssh ...' \
> -drive file.driver=nbd,file.socket=nbd1
>
> would run the command but also allocate a socket and kill the
> subcommand on exit (of qemu)?
I'm not aware of general infrastructure to run helper processes. But
I'm sure we could come up with something.
> Basically I'm trying to think about how to make this a reality:
>
> https://rwmj.files.wordpress.com/2018/10/drawing2-svg.png
Looks like you're also targeting curl.c's drivers. Any others?
Got a backward compatibility story other than "let's deprecate these
drivers"?
[Qemu-devel] [PATCH 07/15] hpet: Report warnings with warn_report(), not error_printf(), Markus Armbruster, 2019/04/08
[Qemu-devel] [PATCH 08/15] vfio: Report warnings with warn_report(), not error_printf(), Markus Armbruster, 2019/04/08
[Qemu-devel] [PATCH 15/15] monitor: Simplify how -device/device_add print help, Markus Armbruster, 2019/04/08
[Qemu-devel] [PATCH 09/15] s390x/kvm: Report warnings with warn_report(), not error_printf(), Markus Armbruster, 2019/04/08