From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Daniele Buono <dbuono@linux.vnet.ibm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [PATCH] meson: Stop if cfi is enabled with system slirp
Date: Mon, 8 Mar 2021 11:19:37 +0000 [thread overview]
Message-ID: <YEYISUuI49rphmDe@redhat.com> (raw)
In-Reply-To: <771f3a7b-f42d-fbd9-5bdc-bce5d354278a@linux.vnet.ibm.com>
On Fri, Mar 05, 2021 at 11:53:07AM -0500, Daniele Buono wrote:
> On 3/4/2021 5:37 AM, Daniel P. Berrangé wrote:
> > Is there work being done, or at least an active plan, for fixing this ?
> >
> > Distros generally won't want to static link slirp to QEMU when there is
> > a shared slirp available. It increases the security burden to maintain
> > slirp twice, especially as slirp has a history of CVEs.
> >
> > IOW, the inability to use shared slirp may well prevent CFI from being
> > used in distros.
>
> Daniel,
> Adoption is a very good point. We don't want to have multiple versions
> of the same library hanging around the O.S., unless strictly necessary.
>
> The problem (if I wear my security hat) is that, as you pointed out,
> slirp is known to have a history of CVEs, and it also rely heavily on
> callbacks and function pointers. So it would be one of the best
> candidates for CFI support.
>
> A (long-term) solution could be to compile libslirp as a shared library,
> WITH Control-Flow Integrity. Clang does have an experimental support for
> Cross-DSO CFI. However, it is not viable at the moment because:
> 1. It is still considered Experimental
> 2. It is not compatible with pointer type generalization (which we need
> because of Glib and other uses in QEMU).
> Cross-DSO CFI also have some performance implications but I think that
> would be a very small price to pay, and only in corner-case conditions.
My concern is that libslirp is just showing us one known example of
the problem. QEMU links to many more external libraries, which might
exhibit similar issues. If we need to rebuild all the dependancies
with CFI too, to be confident that the combined work will operate
correctly, then this is quite a significant implication. Overall I
think this is going to be a problem for the changes of distros adopting
the use of CFI, especially if they're not using CLang as their toolchain.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2021-03-08 11:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-04 2:59 [PATCH] meson: Stop if cfi is enabled with system slirp Daniele Buono
2021-03-04 10:37 ` Daniel P. Berrangé
2021-03-04 10:56 ` Paolo Bonzini
2021-03-05 16:52 ` Daniele Buono
2021-03-05 17:18 ` Paolo Bonzini
2021-03-08 15:05 ` Daniele Buono
2021-03-05 16:53 ` Daniele Buono
2021-03-08 11:19 ` Daniel P. Berrangé [this message]
2021-03-08 11:27 ` Paolo Bonzini
2021-03-08 14:58 ` Daniele Buono
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YEYISUuI49rphmDe@redhat.com \
--to=berrange@redhat.com \
--cc=dbuono@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).