linux-kernel - Re: [PATCH v3 5/6] x86/ftrace: Use text

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: <alpine.LSU.2.21.2001221052331.15957@pobox.suse.cz>
Date:   Wed, 22 Jan 2020 11:09:56 +0100 (CET)
From:   Miroslav Benes <mbenes@...e.cz>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
cc:     Peter Zijlstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Joe Lawrence <joe.lawrence@...hat.com>,
        Jessica Yu <jeyu@...nel.org>, x86@...nel.org,
        linux-kernel@...r.kernel.org, mhiramat@...nel.org,
        bristot@...hat.com, jbaron@...mai.com,
        torvalds@...ux-foundation.org, tglx@...utronix.de,
        mingo@...nel.org, namit@...are.com, hpa@...or.com, luto@...nel.org,
        ard.biesheuvel@...aro.org, live-patching@...r.kernel.org,
        Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH v3 5/6] x86/ftrace: Use text_poke()

> > > At this point, I only see downsides of -flive-patching, at least until
> > > we actually have real upstream code which needs it.
> > 
> > Can you explain this? The option makes GCC to avoid optimizations which 
> > are difficult to detect and would make live patching unsafe. I consider it 
> > useful as it is, so if you shared the other downsides and what you meant 
> > by real upstream code, we could discuss it.
> 
> Only SLES needs it right?  Why inflict it on other livepatch users?  By
> "real upstream code" I mean there's no (documented) way to create live
> patches using the method which relies on this flag.  So I don't see any
> upstream benefits for having it enabled.

I'd put it differently. SLES and upstream need it, RHEL does not need it. 
Or anyone using kpatch-build. It is perfectly fine to prepare live patches 
just from the source code using upstream live patching infrastructure. 
After all, SLES is nothing else than upstream here. We were creating live 
patches manually for quite a long time and only recently we have been 
using Nicolai's klp-ccp automation (https://github.com/SUSE/klp-ccp).

So, everyone using upstream directly relies on the flag, which seems to be 
a clear benefit to me. Reverting the patch would be a step back.

Also I think we're moving in the right direction to make the life of 
upstream user easier with a proposal of klp-ccp and Petr's patch set to 
split live patch modules. It is a path from inconvenient to comfortable 
and not from impossible to possible.

Miroslav