linux-kernel - Re: Collecting both remote and "local" coverage with KCOV

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAeHK+wxupr3kqnr69QphciLLp13+A_7CgU+o_J7xBBxnRdbMg@mail.gmail.com>
Date:   Mon, 16 Nov 2020 18:05:32 +0100
From:   Andrey Konovalov <andreyknvl@...gle.com>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Alexander Bulekov <alxndr@...edu>,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Collecting both remote and "local" coverage with KCOV

On Mon, Nov 16, 2020 at 9:35 AM Dmitry Vyukov <dvyukov@...gle.com> wrote:
>
> On Mon, Nov 16, 2020 at 3:39 AM Alexander Bulekov <alxndr@...edu> wrote:
> >
> > Hello,
> > I'm trying to collect coverage over the syscalls issued by my process,
> > as well as the kthreads spawned as a result of these syscalls
> > (eg coverage over vhost ioctls and the worker kthread). Is there a way
> > to collect coverage with both KCOV_REMOTE_ENABLE(with common_handle) and
> > KCOV_ENABLE, simultaneously?
> >
> > Based on the code it seems that these two modes are mutually
> > exclusive within a single task, but I don't think this is mentioned in
> > the Documentation, so I want to make sure I'm not missing something.
>
> Hi Alex,
>
> Yes, it's probably not supported within a single task. The easiest way
> to verify is to try it ;)
>
> It is possible to collect both coverages, but you will need 2 threads
> (one just to set up remote KCOV).
>
> Unless I am missing any fundamental limitations, I would say it would
> be reasonable to support this within a single task as well.

I think the reason we did that initially, is because we don't care
about normal coverage for USB emitting pseudo-syscalls. Filed a bug
for this: https://bugzilla.kernel.org/show_bug.cgi?id=210225