On Mon, Mar 01, 2021 at 03:39:42PM -0500, Daniele Buono wrote: > Hi Daniel, > > On 3/1/2021 10:08 AM, Daniel P. Berrangé wrote: > > What are the unique failure scenarios for CFI that these jobs are > > likely to expose ? Is it likely that we'll have cases where > > CFI succeeds in say, x86_64 target, but fails in aarch64 target ? > > For CFI to fail (even if it shouldn't) you'll need code that is calling a > function pointer that was not well defined at compile time. Although > unlikely, that could happen everywhere in the code.
What does "was not well defined" mean here ? > > So by just testing one (or few) targets we are are not covering the code in > the TCG frontend used to compile the target ISA to tcg ops, which should be > the in target/, and the architecture-dependent code in linux-user. > > That code seems unlikely (at least to me) to cause a false positive with > CFI. Examples that I've seen in QEMU so far are: > - Calling code that was JIT-ed at runtime > - Callbacks to functions that were loaded from shared libraries > - Signal Handlers > And none of those should happen there IMHO. But you know, corner cases are > still possible, and it's quite difficult to predict what new code may bring. > > We could also consider always testing one or two targets, and keep an > optional job to test them all when deemed necessary. I'm thinking for > example full testing when code in target/ or linux-user/ is considered, or > for testing pre-release code. Would be nice to have this automated but I am > not sure that's possible. > > Regards, > Daniele > 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 :|
