linux-kernel - Re: [RFC PATCH 3/3] objtool/mcount: Add powerpc specific functions

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]

Date:   Tue, 29 Mar 2022 17:32:18 +0000
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Michael Ellerman <mpe@...erman.id.au>,
        Josh Poimboeuf <jpoimboe@...hat.com>
CC:     Peter Zijlstra <peterz@...radead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "aik@...abs.ru" <aik@...abs.ru>,
        Sathvika Vasireddy <sv@...ux.ibm.com>,
        "naveen.n.rao@...ux.vnet.ibm.com" <naveen.n.rao@...ux.vnet.ibm.com>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [RFC PATCH 3/3] objtool/mcount: Add powerpc specific functions



Le 29/03/2022 à 14:01, Michael Ellerman a écrit :
> Josh Poimboeuf <jpoimboe@...hat.com> writes:
>> On Sun, Mar 27, 2022 at 09:09:20AM +0000, Christophe Leroy wrote:
>>> Second point is the endianess and 32/64 selection, especially when
>>> crossbuilding. There is already some stuff regarding endianess based on
>>> bswap_if_needed() but that's based on constant selection at build time
>>> and I couldn't find an easy way to set it conditionaly based on the
>>> target being built.
>>>
>>> Regarding 32/64 selection, there is almost nothing, it's based on using
>>> type 'long' which means that at the time being the target and the build
>>> platform must both be 32 bits or 64 bits.
>>>
>>> For both cases (endianess and 32/64) I think the solution should
>>> probably be to start with the fileformat of the object file being
>>> reworked by objtool.
>>
>> Do we really need to detect the endianness/bitness at runtime?  Objtool
>> is built with the kernel, why not just build-in the same target
>> assumptions as the kernel itself?
> 
> I don't think we need runtime detection. But it will need to support
> basically most combinations of objtool running as 32-bit/64-bit LE/BE
> while the kernel it's analysing is 32-bit/64-bit LE/BE.

Exactly, the way it is done today with a constant in 
objtool/endianness.h is too simple, we need to be able to select it 
based on kernel's config. Is there a way to get the CONFIG_ macros from 
the kernel ? If yes then we could use CONFIG_64BIT and 
CONFIG_CPU_LITTLE_ENDIAN to select the correct options in objtool.


> 
>>> What are current works in progress on objtool ? Should I wait Josh's
>>> changes before starting looking at all this ? Should I wait for anything
>>> else ?
>>
>> I'm not making any major changes to the code, just shuffling things
>> around to make the interface more modular.  I hope to have something
>> soon (this week).  Peter recently added a big feature (Intel IBT) which
>> is already in -next.
>>
>> Contributions are welcome, with the understanding that you'll help
>> maintain it ;-)
>>
>> Some years ago Kamalesh Babulal had a prototype of objtool for ppc64le
>> which did the full stack validation.  I'm not sure what ever became of
>> that.
> 
>  From memory he was starting to clean the patches up in late 2019, but I
> guess that probably got derailed by COVID. AFAIK he never posted
> anything. Maybe someone at IBM has a copy internally (Naveen?).
> 
>> FWIW, there have been some objtool patches for arm64 stack validation,
>> but the arm64 maintainers have been hesitant to get on board with
>> objtool, as it brings a certain maintenance burden.  Especially for the
>> full stack validation and ORC unwinder.  But if you only want inline
>> static calls and/or mcount then it'd probably be much easier to
>> maintain.
> 
> I would like to have the stack validation, but I am also worried about
> the maintenance burden.
> 
> I guess we start with mcount, which looks pretty minimal judging by this
> series, and see how we go from there.
> 

I'm not sure mcount is really needed as we have recordmcount, but at 
least it is an easy one to start with and as we have recordmount we can 
easily compare the results and check it works as expected.

Then it should be straight forward to provide static calls.

Then I'd like to go with uaccess blocks checks as suggested by Christoph 
at 
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/a94be61f008ab29c231b805e1a97e9dab35cb0cc.1629732940.git.christophe.leroy@csgroup.eu/, 
thought it might be less easy.


Christophe