On 3/8/2021 6:19 AM, Daniel P. Berrangé wrote:
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.
In my opinion, there's no need to rebuild everything with CFI. There will be libraries that will benefit more from CFI, such as libslirp IMHO. But that still doesn't even mean that we need a CFI-enabled version to operate correctly. From a functional point of view, there are plenty of ways to have a CFI- enabled binary work with shared libraries that do not support CFI (or cross-dso CFI). From a security point of view it will be a trade-off. So I think we should study it on a per-library case to find out the best way forward. I believe in most cases, an approach like the one discussed with Paolo will be more than enough to get a good security level in QEMU, especially if the feature provided by the library is not used at runtime.
Regards, Daniel
