linux-kernel - Re: [v3,1/8] powerpc: Create a helper for getting the kernel toc value

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: <56E9F332.1070206@gmail.com>
Date:	Thu, 17 Mar 2016 10:58:42 +1100
From:	Balbir Singh <bsingharora@...il.com>
To:	Jiri Kosina <jikos@...nel.org>,
	Michael Ellerman <mpe@...erman.id.au>
Cc:	linuxppc-dev@...abs.org, pmladek@...e.com, jeyu@...hat.com,
	linux-kernel@...r.kernel.org, rostedt@...dmis.org,
	kamalesh@...ux.vnet.ibm.com, duwe@....de,
	live-patching@...r.kernel.org, mbenes@...e.cz
Subject: Re: [v3,1/8] powerpc: Create a helper for getting the kernel toc
 value



On 15/03/16 12:27, Jiri Kosina wrote:
> On Mon, 14 Mar 2016, Michael Ellerman wrote:
>
>>> Move the logic to work out the kernel toc pointer into a header. This is
>>> a good cleanup, and also means we can use it elsewhere in future.
>>>
>>> Reviewed-by: Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>
>>> Reviewed-by: Torsten Duwe <duwe@...e.de>
>>> Signed-off-by: Michael Ellerman <mpe@...erman.id.au>
>>> Tested-by: Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>
>> Series applied to powerpc next.
>>
>> https://git.kernel.org/powerpc/c/a5cab83cd3d2d75d3893276cb5
> Thanks Michael; this is an excellent basis for ppc live patching, but FYI 
> I am not merging that one to my tree just yet.
>
> The solution (*) for functions with non-trivial argument list is not there 
> yet, and it's my requirement for this to be taken care of in a way that's 
> not prone to easily-done human errors on the patch-producer side.
>
> (*) both "making it work" or "making it so broken that it's guaranteed 
>     that noone would ever produce a patch that brings the kernel down" is 
>     okay, but I really don't feel that just documenting the limitation is
>     sufficient and safe in this case; kudos to Torsten here for
>     idenfitfying the problem before it actually became The Problem
To be honest I think my v6 works well, but I don't have complete confidence due to the lack of proper testing. livepatch samples plus some others I wrote and I one Petr wrote all work (calling patched from within patched), but we need more confidence with good tests or an alternative approach that is easier to review and be satisfied with
>
> Thanks,
>