linux-kernel - Re: [PATCHv2] Introduced new tracing mode KCOV_MODE

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] [day] [month] [year] [list]

Date:   Sat, 23 Oct 2021 09:01:19 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Alexander Lochmann <info@...xander-lochmann.de>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Andrey Konovalov <andreyknvl@...il.com>,
        Jonathan Corbet <corbet@....net>,
        Andrew Klychkov <andrew.a.klychkov@...il.com>,
        Miguel Ojeda <ojeda@...nel.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Johannes Berg <johannes@...solutions.net>,
        Ingo Molnar <mingo@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Jakub Kicinski <kuba@...nel.org>,
        Aleksandr Nogikh <nogikh@...gle.com>,
        kasan-dev@...glegroups.com, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCHv2] Introduced new tracing mode KCOV_MODE_UNIQUE.

On Sat, 23 Oct 2021 at 00:03, Alexander Lochmann
<info@...xander-lochmann.de> wrote:
>
> Maybe Dmitry can shed some light on this. He actually suggested that
> optimization.
>
> - Alex
>
> On 29.09.21 10:33, Peter Zijlstra wrote:
> > On Mon, Sep 27, 2021 at 07:33:40PM +0200, Alexander Lochmann wrote:
> >> The existing trace mode stores PCs in execution order. This could lead
> >> to a buffer overflow if sufficient amonut of kernel code is executed.
> >> Thus, a user might not see all executed PCs. KCOV_MODE_UNIQUE favors
> >> completeness over execution order. While ignoring the execution order,
> >> it marks a PC as exectued by setting a bit representing that PC. Each
> >> bit in the shared buffer represents every fourth byte of the text
> >> segment.  Since a call instruction on every supported architecture is
> >> at least four bytes, it is safe to just store every fourth byte of the
> >> text segment.
> >
> > I'm still trying to wake up, but why are call instruction more important
> > than other instructions? Specifically, I'd think any branch instruction
> > matters for coverage.,
> >
> > More specifically, x86 can do a tail call with just 2 bytes.

Hi Peter, Alex,

The calls are important here because we only use PCs that are return
PCs from a callback emitted by the compiler. These PCs point to the
call of the callback.

I don't remember exactly what's the story for tail calls of the
callback for both compilers, ideally they should not use tail calls
for this call, and I think at least one of them does not use tail
calls.

But even with tail calls, the callback is emitted into every basic
block of code. So it should be (call, some other instructions, call)
and at least the first call is not a tail call.