Re: [PATCH] meson: Stop if cfi is enabled with system slirp

[Daniele Buono <dbuono@linux.vnet.ibm.com>]

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.

I don't want to bore anyone too much with the details of the 
implementation... Yet. I'd be happy to explain the Cross-DSO mechanism 
implemented by Clang if it is considered interesting here.
The details can also be found here:
https://clang.llvm.org/docs/ControlFlowIntegrity.html#shared-library-support
And
https://clang.llvm.org/docs/ControlFlowIntegrityDesign.html
(Section "Shared library support")

I think this would be the best long-term solution to improve security
because it would allow to use CFI virtually on every library we consider 
security-sensitive, but not on the others. But it would require some
help and work from/to the Clang community.

In the short term, we should work out something similar to Paolo's
approach. I'll add a few comments to his email.