linux-kernel - Re: [PATCH v3 04/12] powerpc: Prepare func_desc

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: <c06fb573-d133-11d5-c56a-0766f8f7e401@csgroup.eu>
Date:   Mon, 14 Feb 2022 10:30:01 +0000
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Kees Cook <keescook@...omium.org>
CC:     Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
        Helge Deller <deller@....de>, Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
        "linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH v3 04/12] powerpc: Prepare func_desc_t for refactorisation



Le 11/02/2022 à 01:54, Kees Cook a écrit :
> On Sun, Oct 17, 2021 at 02:38:17PM +0200, Christophe Leroy wrote:
>> In preparation of making func_desc_t generic, change the ELFv2
>> version to a struct containing 'addr' element.
>>
>> This allows using single helpers common to ELFv1 and ELFv2.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@...roup.eu>
>> ---
>>   arch/powerpc/kernel/module_64.c | 32 ++++++++++++++------------------
>>   1 file changed, 14 insertions(+), 18 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
>> index a89da0ee25e2..b687ef88c4c4 100644
>> --- a/arch/powerpc/kernel/module_64.c
>> +++ b/arch/powerpc/kernel/module_64.c
>> @@ -33,19 +33,13 @@
>>   #ifdef PPC64_ELF_ABI_v2
>>   
>>   /* An address is simply the address of the function. */
>> -typedef unsigned long func_desc_t;
>> +typedef struct {
>> +	unsigned long addr;
>> +} func_desc_t;
>>   
>>   static func_desc_t func_desc(unsigned long addr)
>>   {
>> -	return addr;
>> -}
>> -static unsigned long func_addr(unsigned long addr)
>> -{
>> -	return addr;
>> -}
>> -static unsigned long stub_func_addr(func_desc_t func)
>> -{
>> -	return func;
>> +	return (func_desc_t){addr};
> 
> There's only 1 element in the struct, so okay, but it hurt my eyes a
> little. I would have been happier with:
> 
> 	return (func_desc_t){ .addr = addr; };
> 
> But of course that also looks bonkers because it starts with "return".
> So no matter what I do my eyes bug out. ;)
> 
> So it's fine either way. :)
> 
> Reviewed-by: Kees Cook <keescook@...omium.org>

I am going for:

  static func_desc_t func_desc(unsigned long addr)
  {
+       func_desc_t desc = {
+               .addr = addr,
+       };
+
+       return desc;
  }


Thanks
Christophe