linux-kernel - Re: [RFC PATCH 0/5] pgo: Add PGO support for module profile data

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]

Message-ID: <2164227.uJ0V1KJIEf@hyperiorarchmachine>
Date:   Tue, 15 Jun 2021 01:27:28 +0300
From:   jarmo.tiitto@...il.com
To:     Jarmo Tiitto <jarmo.tiitto@...il.com>,
        Kees Cook <keescook@...omium.org>
Cc:     Sami Tolvanen <samitolvanen@...gle.com>,
        Bill Wendling <wcw@...gle.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        clang-built-linux@...glegroups.com, linux-kernel@...r.kernel.org,
        morbo@...gle.com
Subject: Re: [RFC PATCH 0/5] pgo: Add PGO support for module profile data

Kees Cook wrote tiistaina 15. kesäkuuta 2021 0.57.46 EEST:
> On Sat, Jun 12, 2021 at 06:24:21AM +0300, Jarmo Tiitto wrote:
> > [...]
> > The patches itself are based on Kees/for-next/clang/features tree
> > where I have two of my bug fix patches already in. :-)
> 
> BTW, due to the (soon to be addressed) requirements of noinstr[1],
> I've removed PGO from my -next tree, and moved it into its own tree in
> "for-next/clang/pgo".
> 
> -Kees
> 
> [1] https://lore.kernel.org/lkml/202106140921.5E591BD@keescook/
> 
> --
> Kees Cook

Yeah, I noticed that. Actually, I think we really should wait for that noinstr 
stuff since:

> There is an lockup that only occurs during bare metal run after +15min, so I 
> haven't been able to catch it in VM.
> I suspect this is caused by the RCU locking I added such that it results in 
> recursive calls into __llvm_profile_instrument_target()

That basically means LLVM is instrumenting code that I call from
__llvm_profile_instrument_target() resulting in nice cycle of doom.
Sigh...

I wrote fix for this but it would be nice to be sure the compiler
doesn't pull the rug under my toes. :-)
--
Jarmo