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: <20160627083254.GB24334@amd>
Date:	Mon, 27 Jun 2016 10:32:54 +0200
From:	Pavel Machek <pavel@....cz>
To:	Jiri Kosina <jikos@...nel.org>
Cc:	Torsten Duwe <duwe@....de>, 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 Mon 2016-06-27 10:26:58, Jiri Kosina wrote:
> On Mon, 27 Jun 2016, Pavel Machek wrote:
> 
> > > > I thought that in such case, person creating the live patch should
> > > > notice and adjust patch appropriately, at assembly level if
> > > > neccessary..?
> > > 
> > > Yes, that still holds; a lot of things could be automated though, and 
> > > creating the automation tools is one of the big TODO items.
> > 
> > So the patch is not a bugfix, it is just something that slows down
> > kernel to make stuff easier for the person doing the live patching...?
> 
> Well, up to the last week noone realized the implications IPA-RA has for 
> live patches. Now that we know about this, we have to deal with it 
> somehow; as currently gcc doesn't provide easy way for us to obtain the 
> information (non-existing -fdump-ipa-ra), disabling the optimization on 
> CONFIG_LIVEPATCH-enabled kernels is a sensible workaround before we're 
> able to get the information from gcc.

You can still build the whole kernel with the patch applied, and look
for code differences in all the functions, then analyzing them... no?

> > What you actually want is "whenever source of function A influenced code 
> > in function B, I want to be notified", right?
> > 
> > If gcc can eliminate an if() brach in function B, because it can tell 
> > reading function A it can not happen, you need to know. Maybe that's 
> > limited to ABI today, but...
> 
> Yeah; dead code elimination is also a thing to watch for.

That was supposed to be just an example.

I believe you want "whenever source of function A influenced code in
function B, I want to be notified", and I believe it should be
documented as such.

gcc might produce new and interesting optimalizations in future. I
believe you want --dont-let-function-influence-function switch to gcc,
not growing list of --no-optimalization-A, --no-optimalization-B...

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