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: <20160626223956.GD21026@amd>
Date:	Mon, 27 Jun 2016 00:39:56 +0200
From:	Pavel Machek <pavel@....cz>
To:	Jiri Kosina <jikos@...nel.org>
Cc:	Torsten Duwe <duwe@....de>, Miroslav Benes <mbenes@...e.cz>,
	Josh Poimboeuf <jpoimboe@...hat.com>, 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 2016-06-23 14:47:03, Jiri Kosina wrote:
> On Thu, 23 Jun 2016, Jiri Kosina wrote:
> 
> > > 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.
> > 
> > You're right, thanks for bringing this up.
> > 
> > In principle we should be able to modify the trampoline so that it 
> > performs its own register saving (in ftrace_regs_caller) and restoring 
> > (*), completely shielding the new function from any optimization gcc might 
> > have done on registers, shouldn't we?
> > 
> > (*) we'll have to piggy-back on ftrace_epilogue on that, i.e. making the 
> >     return to the original code go through trampoline as well (the same 
> >     way graph tracer works)
> 
> Okay, after looking more about how ftrace implements the return 
> trampolines for graph caller, it'd be rather difficult to implement in a 
> way that we neither interfere with ftrace graph tracer (the 
> ftrace_ret_stack in task_struct) nor introduce a serious performance 
> overhead or stack usage pressure.
> 
> I am pretty sure the overhead we'd be adding would be much worse than just 
> really simply turning the IPA-RA off in CONFIG_LIVEPATCH-enabled kernels 
> is the easiest way to go.
> 
> After talking to Jan Hubicka, I'd actually suggest turning off most/all 
> the IPA optimizations; they are supposed to be of questionable benefit for 
> kernel anyway, and they might be causing serious issues for us.

Lets compile kernel with -O0, and sacrifice few lambs....?

Would it be possible to document which kind of guarantees live
patching needs from compiler?

I always assumed that whoever is preparing the patch does manual
investigation to see what needs to be changed and how, but apparantly
that's not the case, so documentation would be good.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html