linux-kernel - Re: [PATCH] riscv: add asm/unistd.h UAPI header

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:   Wed, 07 Nov 2018 18:10:09 -0800 (PST)
From:   Palmer Dabbelt <palmer@...ive.com>
To:     Arnd Bergmann <arnd@...db.de>
CC:     david.abdurachmanov@...il.com, aou@...s.berkeley.edu,
        linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
        marcin.juszkiewicz@...aro.org, linux@...ck-us.net
Subject:     Re: [PATCH] riscv: add asm/unistd.h UAPI header

On Wed, 07 Nov 2018 13:09:39 PST (-0800), Arnd Bergmann wrote:
> On Wed, Nov 7, 2018 at 7:30 PM David Abdurachmanov
> <david.abdurachmanov@...il.com> wrote:
>> On Wed, Nov 7, 2018 at 1:08 AM Palmer Dabbelt <palmer@...ive.com> wrote:
>> > On Mon, 05 Nov 2018 12:56:15 PST (-0800), Arnd Bergmann wrote:
>
>> > The target is still the next glibc release (Feb 1st) for a stable RV32I ABI.
>> > That's progressing well, with one last blocking issue related to some of our
>> > floating-point emulation routines before we can submit the port.  This should
>> > give us ample time to line up the ABIs correctly so everything works.
>> >
>> > So I think the correct answer here is to drop __ARCH_WANT_STAT64 from RISC-V.
>> >
>>
>> Then if you agree I could do and send v2:
>>
>> +#ifdef __LP64__
>> +#define __ARCH_WANT_NEW_STAT
>> +#endif /* __LP64__ */
>
> Looks good to me.

This is a bit pedantic, but I'm not sure what the right answer is here: 
"-march=rv64gc -mabi=ilp32d" will not define __LP64__, but will define 
"__riscv_xlen == 64".  I actually don't know enough about how an rv64gc/ilp32d 
ABI would work to answer this: would we have "long long" all over our syscalls?

Probably not worth worrying about for now, as we'll have to go audit all of 
these if we ever end up with an ilp32 ABI.  So just go for it and we'll throw 
this on the pile to deal with later :)