linux-kernel - Re: [PATCH 0/2] tools/nolibc: riscv: Fix up compile error for rv32

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Sat, 20 May 2023 22:31:54 +0800
From:   Zhangjin Wu <falcon@...ylab.org>
To:     w@....eu
Cc:     aou@...s.berkeley.edu, falcon@...ylab.org,
        linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
        linux@...ssschuh.net, palmer@...osinc.com,
        paul.walmsley@...ive.com, paulmck@...nel.org
Subject: Re: [PATCH 0/2] tools/nolibc: riscv: Fix up compile error for rv32

Hi Willy,

> Hi Zhangjin,
> 
> On Fri, May 19, 2023 at 01:00:18AM +0800, Zhangjin Wu wrote:
> ...
>
> > * To let it compile for rv32, we still need to apply one of such actions:
> >     * Revert the kernel commit d4c08b9776b3 ("riscv: Use latest system call ABI"),
> >       but it is not the right direction, that commit has removed all of the time32 syscalls,
> >       and let C lib (e.g. glibc) provide the same C APIs based on the other time64 syscalls
> > 
> >     * If not really use any of the time32 syscalls, defining __ARCH_WANT_TIME32_SYSCALLS
> >       macro will let it compile, but this is buggy for the current implmentations are based
> >       on time32 syscalls!
> > 
> >     * Really implement the C APIs for rv32, based on the time64 syscalls, just like glibc.
> >       This commit c8ce48f06503 ("asm-generic: Make time32 syscall numbers optional") shows
> >       us which functions should be re-implemented.
> > 
> > So, the work todo for rv32 is:
> > 
> > * Rebasing all of the old time32 syscalls based C APIs on the new time64 syscalls,
> >   but they are not simply mapped one by one, glibc is a good reference.
> > 
> > * Add standalone rv32 test support in tools/testing/selftests/nolibc/
> 
> I'm not the right one to judge how to best support rv32 but at least I just
> don't want to go backwards. I'm just having a probably stupid question, but
> how relevant is rv32 ? I mean, all the boards I've seen to date were based
> on rv64 even the smallest embedded ones, so I'm sincerely wondering if there
> exists at all any rv32 devices capable of running Linux. Because if that's
> not the case, maybe we should instead declare that we only support rv64 ?
> If such devices exist however, I'm all for us supporting them well.
>

Firstly, as the commit c8ce48f06503 ("asm-generic: Make time32 syscall
numbers optional") shows:

    We don't want new architectures to even provide the old 32-bit time_t
    based system calls any more, or define the syscall number macros.

So, this is not rv32 specific, more and more architectures are trying to
use the generic unistd.h (include/uapi/asm-generic/unistd.h), but rv32
may be the first new architecture variant who have no time32 syscalls.

Second, I did search some rv32 socs/boards from two companies, they are
bl602/bl616/bl702, esp32-c2/c3/c6, some of them even have 532KB sRAM which is
enough for nolibc-based app + linux kernel, I have gotten 334K rv64 vmlinuz
(+nolibc hello.c) in the tinylinux work for riscv, the future work may be
running linux on such a real rv32 board ;-)

Best regards,
Zhangjin Wu

> Thanks,
> Willy