linux-kernel - Re: [PATCH] Disable non-ABI-compliant optimisations for live patching

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: <20160623100550.GB31609@lst.de>
Date:	Thu, 23 Jun 2016 12:05:51 +0200
From:	Torsten Duwe <duwe@....de>
To:	Miroslav Benes <mbenes@...e.cz>
Cc:	Josh Poimboeuf <jpoimboe@...hat.com>,
	Jiri Kosina <jkosina@...e.cz>, matz@...e.de,
	live-patching@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Disable non-ABI-compliant optimisations for live
	patching

On Thu, Jun 23, 2016 at 09:45:48AM +0200, Miroslav Benes wrote:
> 
> Hi,
> 
> On Wed, 22 Jun 2016, Josh Poimboeuf wrote:
> 
> > On Wed, Jun 22, 2016 at 04:24:41PM +0200, Torsten Duwe wrote:
> > > Live patching, as we use it, deliberately disrupts the fabric of
> > > compile units; thus all assumptions a compiler can make about the
> > > control flow may be invalid. As an example, it could analyse that a
> > > callee does not touch a caller-saved register at all, so why waste
> > > memory bandwidth saving it? The register allocations for the live
> > > patch replacement function may however be quite different.
> 
> But this exact situation should not be possible. Ftrace stub should (and 
> it does on x86_64) save the caller-saved registers for us. Otherwise we 

I haven't looked at the fentry solution, but the code I'm involved in saves
the registers so that ftrace, live patch and friends can work freely. But
then it restores all regs and _then_ calls the replacement, so ftrace
saving all regs is no gain at all.

> would have seen problems with kGraft already.

IMHO these problems are rare to trigger. I'm afraid some problems are already
lurking.

> > > Starting with this example, disable all compiler optimisations that
> > > do not strictly comply with the established calling conventions.
> 
> It think it is too rough and I'd like to avoid it if possible.

I'm not too happy either, but function calling conventions are there
for a reason. And if you exchange one function with another version,
the convention is all you can rely on.

[ ... slightly out of context ...:]
> 
> This could surely be avoided if one can prove that the new patching 
> function is optimized in the same way by gcc.

I guess that is what it boils down to in general, and I'd rather avoid that,
as it sometimes requires the whole compile unit to get the same result; and
then we haven't even made the changes we wanted to live patch in the first
place.

My main intention was to create the awareness and offer one possible
solution. I'd be happy if there was a better way.

	Torsten