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: <alpine.LNX.2.00.1606231429280.6874@cbobk.fhfr.pm>
Date:	Thu, 23 Jun 2016 14:47:03 +0200 (CEST)
From:	Jiri Kosina <jikos@...nel.org>
To:	Torsten Duwe <duwe@....de>
cc:	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, 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.

I am planning to ask our performance team to measure the impact this'd 
have.

Thanks,

-- 
Jiri Kosina
SUSE Labs