linux-kernel - Re: [syzbot] riscv/fixes test error: lost connection to test machine

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: <CACT4Y+a79F0SmG2KTZyYQ1ZTktY7zQ5ofZMdpkCKNq=SeNxbCw@mail.gmail.com>
Date:   Sat, 28 May 2022 10:26:44 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Alexandre Ghiti <alex@...ti.fr>
Cc:     Alexandre Ghiti <alexandre.ghiti@...onical.com>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        syzbot <syzbot+2c5da6a0a16a0c4f34aa@...kaller.appspotmail.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>
Subject: Re: [syzbot] riscv/fixes test error: lost connection to test machine

On Sat, 28 May 2022 at 10:03, Alexandre Ghiti <alex@...ti.fr> wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> syzbot found the following issue on:
> >>>>>>
> >>>>>> HEAD commit: c932edeaf6d6 riscv: dts: microchip: fix gpio1 reg property..
> >>>>>> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes
> >>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=1418add5f00000
> >>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=aa6b5702bdf14a17
> >>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=2c5da6a0a16a0c4f34aa
> >>>>>> compiler: riscv64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> >>>>>> userspace arch: riscv64
> >>>>>>
> >>>>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> >>>>>> Reported-by: syzbot+2c5da6...@...kaller.appspotmail.com
> >>>>> The CONFIG_KASAN_VMALLOC allows riscv kernel to boot, but now Go
> >>>>> processes started crashing with:
> >>>>>
> >>>>> 1970/01/01 00:06:55 fuzzer started
> >>>>> runtime: lfstack.push invalid packing: node=0xffffff5908a940 cnt=0x1
> >>>>> packed=0xffff5908a9400001 -> node=0xffff5908a940
> >>>>> fatal error: lfstack.push
> >>>>> runtime stack:
> >>>>> runtime.throw({0x30884c, 0xc})
> >>>>> /usr/local/go/src/runtime/panic.go:1198 +0x60
> >>>>> runtime.(*lfstack).push(0xdb3850, 0xffffff5908a940)
> >>>>> /usr/local/go/src/runtime/lfstack.go:30 +0x1a8
> >>>>>
> >>>>> Go runtime tries to shove some data into the upper 16 bits of pointers
> >>>>> assuming they are unused.
> >>>>> However, the original pointer node=0xffffff5908a940 suggest riscv now
> >>>>> has 56-bit users-space address space?
> >>>>
> >>>> Yes, sv57 was merged recently.
> >>>>
> >>>>> Documentation/riscv/vm-layout.rst claims 48-bit pointers:
> >>>>> "
> >>>>> The RISC-V privileged architecture document states that the 64bit addresses
> >>>>> "must have bits 63–48 all equal to bit 47, or else a page-fault exception will
> >>>>> occur.":
> >>>>
> >>>> Thanks for pointing that, I extracted that from the specification before sv57 was specified, I'll fix that.
> >>>>
> >>>> The current kernel code will use sv57 as it is supported and advertised by qemu, and to my knowledge, you can't downgrade to sv48 unless by re-compiling qemu using the following:
> >>>>
> >>>> diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> >>>> index 6dbe9b541f..a64b50ed75 100644
> >>>> --- a/target/riscv/csr.c
> >>>> +++ b/target/riscv/csr.c
> >>>> @@ -637,7 +637,7 @@ static const char valid_vm_1_10_64[16] = {
> >>>> [VM_1_10_MBARE] = 1,
> >>>> [VM_1_10_SV39] = 1,
> >>>> [VM_1_10_SV48] = 1,
> >>>> - [VM_1_10_SV57] = 1
> >>>> + [VM_1_10_SV57] = 0
> >>>> };
> >>>>
> >>>> /* Machine Information Registers */
> >>>>
> >>>>> ...
> >>>>> 0000000000000000 | 0 | 0000003fffffffff | 256 GB |
> >>>>> user-space virtual memory, different per mm
> >>>>> "
> >>> There is no kernel config to force SV48/39, right?
> >>
> >> No, we rely on what the hardware advertises, if it supports sv57, we'll go for sv57, if not, we'll try sv48...etc. I had some patches to force the downgrade by using the device tree but they never got merged though.
> > +original CC list
> >
> > FTR sent Go runtime change to support SV57:
> > https://go-review.googlesource.com/c/go/+/409055
>
>
> Thank you for that, I'll pull that into Ubuntu when merged. Do you know
> if any other programming language does the same and would need a fix too?

Nothing comes to mind right now.
But this is not only about language runtimes, it's about all software
out there. However, x86 has 5-level pages now as well, it should stomp
on these problems earlier... but somehow it did not happen for Go
runtime.