linux-kernel - Re: [PATCH v3 3/5] arm64: vdso32: Fix compilation warning

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, 1 Oct 2019 15:41:31 +0100
From:   Vincenzo Frascino <vincenzo.frascino@....com>
To:     Will Deacon <will@...nel.org>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        ard.biesheuvel@...aro.org, ndesaulniers@...gle.com,
        catalin.marinas@....com, tglx@...utronix.de
Subject: Re: [PATCH v3 3/5] arm64: vdso32: Fix compilation warning

On 10/1/19 2:21 PM, Will Deacon wrote:
> On Thu, Sep 26, 2019 at 10:43:40PM +0100, Vincenzo Frascino wrote:
>> As reported by Will Deacon the following compilation warning appears
>> during the compilation of the vdso32:
>>
>> In file included from ./arch/arm64/include/asm/thread_info.h:17:0,
>>                  from ./include/linux/thread_info.h:38,
>>                  from ./arch/arm64/include/asm/preempt.h:5,
>>                  from ./include/linux/preempt.h:78,
>>                  from ./include/linux/spinlock.h:51,
>>                  from ./include/linux/seqlock.h:36,
>>                  from ./include/linux/time.h:6,
>>                  from .../work/linux/lib/vdso/gettimeofday.c:7,
>>                  from <command-line>:0:
>> ./arch/arm64/include/asm/memory.h: In function ‘__tag_set’:
>> ./arch/arm64/include/asm/memory.h:233:15: warning: cast from pointer to
>> integer of different size [-Wpointer-to-int-cast]
>>   u64 __addr = (u64)addr & ~__tag_shifted(0xff);
>>                ^
>> In file included from ./arch/arm64/include/asm/pgtable-hwdef.h:8:0,
>>                  from ./arch/arm64/include/asm/processor.h:34,
>>                  from ./arch/arm64/include/asm/elf.h:118,
>>                  from ./include/linux/elf.h:5,
>>                  from ./include/linux/elfnote.h:62,
>>                  from arch/arm64/kernel/vdso32/note.c:11:
>> ./arch/arm64/include/asm/memory.h: In function ‘__tag_set’:
>> ./arch/arm64/include/asm/memory.h:233:15: warning: cast from pointer to
>> integer of different size [-Wpointer-to-int-cast]
>>   u64 __addr = (u64)addr & ~__tag_shifted(0xff);
>>                ^
>>
>> This happens because few 64 bit compilation headers are included during
>> the generation of vdso32.
>>
>> Fix the issue redefining the __tag_set function.
>>
>> Note: This fix is meant to be temporary, a more comprehensive solution
>> based on the refactoring of the generic headers will be provided with a
>> future patch set. At that point it will be possible to revert this patch.
>>
>> Cc: Will Deacon <will@...nel.org>
>> Cc: Catalin Marinas <catalin.marinas@....com>
>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@....com>
>> ---
>>  arch/arm64/include/asm/memory.h | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> index b61b50bf68b1..c61b2eb50a3b 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -228,11 +228,14 @@ static inline unsigned long kaslr_offset(void)
>>  #define __tag_get(addr)		0
>>  #endif /* CONFIG_KASAN_SW_TAGS */
>>  
>> +#ifdef __aarch64__
>> +/* Do not attempt to compile this code with compat vdso */
>>  static inline const void *__tag_set(const void *addr, u8 tag)
>>  {
>>  	u64 __addr = (u64)addr & ~__tag_shifted(0xff);
>>  	return (const void *)(__addr | __tag_shifted(tag));
>>  }
>> +#endif
> 
> Sorry, but I'm not taking this.
> 
> I know you're trying to fix the issues I reported as quickly as you can (and
> thank you for that), but I'm sure that you agree this needs more thought to
> develop a proper solution to what is a much bigger issue than can be solved
> by sprinkling #ifdefs. I can live with the warning on the basis that a
> proper fix is in the pipeline, but in the meantime it can serve as a
> reminder that we're not done here.
>

This was my original preference as well, if we silence the warnings we tend to
forget about them. Since you reported the issue as urgent, I reacted with
something that fixes it temporarily, but I have not objections if you want to
wait for a more comprehensive solution.

> Will
> 

-- 
Regards,
Vincenzo