[libvirt PATCH 6/6] ci: Enable address and undefined behavior sanitizers

[Tim Wiederhake]

On Mon, 2021-05-03 at 14:16 +0200, Pavel Hrdina wrote:
> On Mon, May 03, 2021 at 12:01:46PM +0200, Tim Wiederhake wrote:
> > meson supports the following sanitizers: "address" (e.g. out-of-
> > bounds
> > memory access, use-after-free, etc.), "thread" (data races),
> > "undefined"
> > (e.g. signed integer overflow), and "memory" (use of uninitialized
> > memory). Note that not all sanitizers are supported by all
> > compilers,
> > and that more sanitizers exist.
> > 
> > Not all sanitizers can be enabled at the same time, but "address"
> > and
> > "undefined" can. Both thread and memory sanitizers require an
> > instrumented
> > build of all dependencies, including libc.
> > 
> > gcc and clang use different implementations of these sanitizers and
> > have proven to find different issues. Create CI jobs for both.
> > 
> > Signed-off-by: Tim Wiederhake <twiederh at redhat.com>
> > ---
> >  .gitlab-ci.yml | 35 +++++++++++++++++++++++++++++++++++
> >  1 file changed, 35 insertions(+)
> > 
> > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > index 8b7df68f47..aa537e65fb 100644
> > --- a/.gitlab-ci.yml
> > +++ b/.gitlab-ci.yml
> > @@ -71,6 +71,26 @@ stages:
> >          rpmbuild --nodeps -ta build/meson-dist/libvirt-*.tar.xz;
> >        fi
> >  
> > +.sanitizer_build_job:
> > +  stage: builds
> > +  image: $CI_REGISTRY_IMAGE/ci-ubuntu-2004:latest
> > +  needs:
> > +    - x64-ubuntu-2004-container
> 
> Any specific reason for using Ubuntu 20.04? I would guess that we
> want
> to always use the latest compiler. It that's true I'm not sure which
> distribution to pick:
> 
>     - Fedora $LATEST - we would need to change it every 6 months
> 
>     - Fedora rawhide - may be unstable and randomly fail if the
>       gcc/clang are broken
> 

I chose Ubuntu 20.04 for no particular reason other than "the image
already has the sanitizers installed and need no change".

Fedora 33 and Rawhide both require additional packages installed
(libasan and libubsan).

libvirt fails to build on Fedora Rawhide with gcc over what I believe
to be a bug somewhere in the build chain. Output from one instance of
the issue:

```
In file included from /usr/include/string.h:519,
                 from ../source/src/internal.h:28,
                 from ../source/src/rpc/virnettlscontext.h:23,
                 from ../source/src/rpc/virnetclient.h:23,
                 from ../source/src/rpc/virnetclient.c:27:
In function ‘memcpy’,
    inlined from ‘virNetClientCallDispatchReply’ at
../source/src/rpc/virnetclient.c:1156:5,
    inlined from ‘virNetClientCallDispatch’ at
../source/src/rpc/virnetclient.c:1324:16,
    inlined from ‘virNetClientIOHandleInput’ at
../source/src/rpc/virnetclient.c:1497:23:
/usr/include/bits/string_fortified.h:29:10: error: ‘__builtin_memcpy’
offset [148, 167] from the object at ‘client’ is out of the bounds of
referenced subobject ‘prog’ with type ‘unsigned int’ at offset 144 [-
Werror=array-bounds]
   29 |   return __builtin___memcpy_chk (__dest, __src, __len,
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   30 |                                  __glibc_objsize0 (__dest));
      |                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../source/src/rpc/virnetmessage.h:23,
                 from ../source/src/rpc/virnetclient.h:24,
                 from ../source/src/rpc/virnetclient.c:27:
../source/src/rpc/virnetclient.c: In function
‘virNetClientIOHandleInput’:
src/rpc/virnetprotocol.h:48:15: note: subobject ‘prog’ declared here
   48 |         u_int prog;
      |               ^~~~
cc1: all warnings being treated as errors
```

Notice that source and destination of the memcpy referenced above are
of type `virNetMessage`:
```
    memcpy(&thecall->msg->header, &client->msg.header, sizeof(client-
>msg.header));
```

Using clang, libvirt builds just fine on Fedora Rawhide, but half of
the tests fail with:

```
==58582==ERROR: AddressSanitizer failed to allocate 0x0 (0) bytes of
SetAlternateSignalStack (error code: 22)
(...)
==58582==AddressSanitizer CHECK failed:
../lib/sanitizer_common/sanitizer_common.cpp:54 "((0 && "unable to
mmap")) != (0)" (0x0, 0x0)
    <empty stack>
```

On Fedora 33 (with libasan and libubsan installed manually), libvirt
builds and tests fine with both clang and gcc, but find no additional
issues in the code base.


I cannot make a statement on the differences between the versions of
(clang's) libasan and libubsan found in Ubuntu 20.04 and Fedora, but
https://github.com/llvm/llvm-project/commits/main/compiler-rt/lib/asan 
and 
https://github.com/llvm/llvm-project/commits/main/compiler-rt/lib/ubsan/
 suggest that not too many new features are added to sanitizers lately.

Cheers,
Tim
> 
> > +  rules:
> > +    - if: "$TEMPORARILY_DISABLED"
> > +      allow_failure: true
> > +    - when: on_success
> > +  cache:
> > +    paths:
> > +      - ccache/
> > +    key: "$CI_JOB_NAME"
> > +  before_script:
> > +    - *script_variables
> > +  script:
> > +    - meson build --werror -Db_lundef=false
> > -Db_sanitize="$SANITIZER"
> > +    - ninja -C build;
> > +    - ninja -C build test;
> > +
> >  # Jobs that we delegate to Cirrus CI because they require an
> > operating
> >  # system other than Linux. These jobs will only run if the
> > required
> >  # setup has been performed on the GitLab account (see
> > ci/README.rst).
> > @@ -517,6 +537,21 @@ mingw64-fedora-rawhide:
> >      NAME: fedora-rawhide
> >      CROSS: mingw64
> >  
> > +# Sanitizers
> > +
> > +sanitize-gcc:
> > +  extends: .sanitizer_build_job
> > +  variables:
> > +    ASAN_OPTIONS: verify_asan_link_order=0
> > +    CC: gcc
> > +    SANITIZER: address,undefined
> > +
> > +sanitize-clang:
> > +  extends: .sanitizer_build_job
> > +  variables:
> > +    CC: clang
> > +    SANITIZER: address,undefined
> > +
> >  
> >  # This artifact published by this job is downloaded by libvirt.org
> > to
> >  # be deployed to the web root:
> > -- 
> > 2.26.3
> >