linux-kernel - Re: Fix issue with alternatives/paravirt patches

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] [day] [month] [year] [list]

Date:	Thu, 21 Jul 2016 10:48:24 +0200 (CEST)
From:	Miroslav Benes <mbenes@...e.cz>
To:	Jessica Yu <jeyu@...hat.com>
cc:	Josh Poimboeuf <jpoimboe@...hat.com>,
	Petr Mladek <pmladek@...e.com>, Jiri Kosina <jikos@...nel.org>,
	Chris J Arges <chris.j.arges@...onical.com>,
	Eugene Shatokhin <eugene.shatokhin@...alab.ru>,
	live-patching@...r.kernel.org, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Fix issue with alternatives/paravirt patches

On Thu, 21 Jul 2016, Jessica Yu wrote:

> +++ Miroslav Benes [12/07/16 14:06 +0200]:
> > 
> > Is there a problem when you need to generate a dynrela for paravirt code?
> > I mean one does not know during the build of a patch module if paravirt
> > would or would not be applied. If such code needs to be relocated it could
> > be a problem for kpatch-build. Is this correct or am I missing something?
> 
> In kpatch-build, "special" sections like .parainstructions and
> .altinstructions are into consideration. These sections are included
> in the final patch module if they reference any of the new replacement
> code. Like with any other section, kpatch-build will convert any relas
> from .rela.parainstructions (for example) to dynrelas if it is
> necessary.  And with this patch we apply all "dynrelas" (which are now
> actual relas in .klp.rela sections) first before applying any
> paravirt/alternatives patches in arch_klp_init_object_loaded(), which
> is the correct order.

Ah, right. So it should be ok.

> > Now the other architectures we support. s390 should be ok. There is
> > nothing much in module_finalize() there. powerpc is different though. It
> > is quite similar to x86_64 case. And also arm64 needs to be handled in
> > future.
> 
> Yeah, I think we are OK for s390, arm64 looks fairly straightforward
> (just a call to apply_alternatives()), powerpc looks slightly more
> involved but I haven't thoroughly dug into it yet.
> 
> So other arches will need to have arch_klp_init_object_loaded()
> implemented eventually (if needed), but I think it is fine for now to
> fix this issue on x86 first, since that's where the original bug
> cropped up.

Agreed.

Miroslav