Re: riscv+KASAN does not boot
On Tue, Mar 9, 2021 at 8:49 PM Alex Ghiti wrote: > > Le 3/9/21 à 12:11 PM, Dmitry Vyukov a écrit : > > On Fri, Feb 19, 2021 at 11:26 PM 'Palmer Dabbelt' via syzkaller > > wrote: > >> > >> On Fri, 19 Feb 2021 10:53:43 PST (-0800), dvyu...@google.com wrote: > >>> On Fri, Feb 19, 2021 at 6:01 PM Alex Ghiti wrote: > > Hi Dmitry, > > Le 2/18/21 à 6:36 AM, Dmitry Vyukov a écrit : > > On Thu, Feb 18, 2021 at 8:54 AM Alex Ghiti wrote: > >> > >> Hi Dmitry, > >> > >>> On Wed, Feb 17, 2021 at 5:36 PM Alex Ghiti wrote: > > Le 2/16/21 à 11:42 PM, Dmitry Vyukov a écrit : > > On Tue, Feb 16, 2021 at 9:42 PM Alex Ghiti wrote: > >> > >> Hi Dmitry, > >> > >> Le 2/16/21 à 6:25 AM, Dmitry Vyukov a écrit : > >>> On Tue, Feb 16, 2021 at 12:17 PM Dmitry Vyukov > >>> wrote: > > On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov > wrote: > >> I was fixing KASAN support for my sv48 patchset so I took a > >> look at your > >> issue: I built a kernel on top of the branch riscv/fixes using > >> https://github.com/google/syzkaller/blob/269d24e857a757d09a898086a2fa6fa5d827c3e1/dashboard/config/linux/upstream-riscv64-kasan.config > >> and Buildroot 2020.11. I have the warnings regarding the use of > >> __virt_to_phys on wrong addresses (but that's normal since > >> this function > >> is used in virt_addr_valid) but not the segfaults you describe. > > > > Hi Alex, > > > > Let me try to rebuild buildroot image. Maybe there was > > something wrong > > with my build, though, I did 'make clean' before doing. But at > > the > > same time it worked back in June... > > > > Re WARNINGs, they indicate kernel bugs. I am working on setting > > up a > > syzbot instance on riscv. If there a WARNING during boot then > > the > > kernel will be marked as broken. No further testing will happen. > > Is it a mis-use of WARN_ON? If so, could anybody please remove > > it or > > replace it with pr_err. > > > Hi, > > I've localized one issue with riscv/KASAN: > KASAN breaks VDSO and that's I think the root cause of weird > faults I > saw earlier. The following patch fixes it. > Could somebody please upstream this fix? I don't know how to > add/run > tests for this. > Thanks > > diff --git a/arch/riscv/kernel/vdso/Makefile > b/arch/riscv/kernel/vdso/Makefile > index 0cfd6da784f84..cf3a383c1799d 100644 > --- a/arch/riscv/kernel/vdso/Makefile > +++ b/arch/riscv/kernel/vdso/Makefile > @@ -35,6 +35,7 @@ CFLAGS_REMOVE_vgettimeofday.o = > $(CC_FLAGS_FTRACE) -Os > # Disable gcov profiling for VDSO code > GCOV_PROFILE := n > KCOV_INSTRUMENT := n > +KASAN_SANITIZE := n > > # Force dependency > $(obj)/vdso.o: $(obj)/vdso.so > >> > >> What's weird is that I don't have any issue without this patch > >> with the > >> following config whereas it indeed seems required for KASAN. But > >> when > >> looking at the segfaults you got earlier, the segfault address is > >> 0xbb0 > >> and the cause is an instruction page fault: this address is the > >> PLT base > >> address in vdso.so and an instruction page fault would mean that > >> someone > >> tried to jump at this address, which is weird. At first sight, > >> that does > >> not seem related to your patch above, but clearly I may be wrong. > >> > >> Tobias, did you observe the same segfaults as Dmitry ? > > > > > > I noticed that not all buildroot images use VDSO, it seems to be > > dependent on libc settings (at least I think I changed it in the > > past). > > Ok, I used uClibc but then when using glibc, I have the same > segfaults, > only when KASAN is enabled. And your patch fixes the problem. I will > try > to take a look later to better understand the problem. > > > I also booted an image completely successfully including dhcpd/sshd > > start, but then my executable crashed in clock_gettime. The > > executable > > was build on linux/amd64 host with "riscv64-linux-gnu-gcc -static" > > (10.2.1). > > >
Re: riscv+KASAN does not boot
Le 3/9/21 à 12:11 PM, Dmitry Vyukov a écrit : On Fri, Feb 19, 2021 at 11:26 PM 'Palmer Dabbelt' via syzkaller wrote: On Fri, 19 Feb 2021 10:53:43 PST (-0800), dvyu...@google.com wrote: On Fri, Feb 19, 2021 at 6:01 PM Alex Ghiti wrote: Hi Dmitry, Le 2/18/21 à 6:36 AM, Dmitry Vyukov a écrit : On Thu, Feb 18, 2021 at 8:54 AM Alex Ghiti wrote: Hi Dmitry, On Wed, Feb 17, 2021 at 5:36 PM Alex Ghiti wrote: Le 2/16/21 à 11:42 PM, Dmitry Vyukov a écrit : On Tue, Feb 16, 2021 at 9:42 PM Alex Ghiti wrote: Hi Dmitry, Le 2/16/21 à 6:25 AM, Dmitry Vyukov a écrit : On Tue, Feb 16, 2021 at 12:17 PM Dmitry Vyukov wrote: On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov wrote: I was fixing KASAN support for my sv48 patchset so I took a look at your issue: I built a kernel on top of the branch riscv/fixes using https://github.com/google/syzkaller/blob/269d24e857a757d09a898086a2fa6fa5d827c3e1/dashboard/config/linux/upstream-riscv64-kasan.config and Buildroot 2020.11. I have the warnings regarding the use of __virt_to_phys on wrong addresses (but that's normal since this function is used in virt_addr_valid) but not the segfaults you describe. Hi Alex, Let me try to rebuild buildroot image. Maybe there was something wrong with my build, though, I did 'make clean' before doing. But at the same time it worked back in June... Re WARNINGs, they indicate kernel bugs. I am working on setting up a syzbot instance on riscv. If there a WARNING during boot then the kernel will be marked as broken. No further testing will happen. Is it a mis-use of WARN_ON? If so, could anybody please remove it or replace it with pr_err. Hi, I've localized one issue with riscv/KASAN: KASAN breaks VDSO and that's I think the root cause of weird faults I saw earlier. The following patch fixes it. Could somebody please upstream this fix? I don't know how to add/run tests for this. Thanks diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile index 0cfd6da784f84..cf3a383c1799d 100644 --- a/arch/riscv/kernel/vdso/Makefile +++ b/arch/riscv/kernel/vdso/Makefile @@ -35,6 +35,7 @@ CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os # Disable gcov profiling for VDSO code GCOV_PROFILE := n KCOV_INSTRUMENT := n +KASAN_SANITIZE := n # Force dependency $(obj)/vdso.o: $(obj)/vdso.so What's weird is that I don't have any issue without this patch with the following config whereas it indeed seems required for KASAN. But when looking at the segfaults you got earlier, the segfault address is 0xbb0 and the cause is an instruction page fault: this address is the PLT base address in vdso.so and an instruction page fault would mean that someone tried to jump at this address, which is weird. At first sight, that does not seem related to your patch above, but clearly I may be wrong. Tobias, did you observe the same segfaults as Dmitry ? I noticed that not all buildroot images use VDSO, it seems to be dependent on libc settings (at least I think I changed it in the past). Ok, I used uClibc but then when using glibc, I have the same segfaults, only when KASAN is enabled. And your patch fixes the problem. I will try to take a look later to better understand the problem. I also booted an image completely successfully including dhcpd/sshd start, but then my executable crashed in clock_gettime. The executable was build on linux/amd64 host with "riscv64-linux-gnu-gcc -static" (10.2.1). Second issue I am seeing seems to be related to text segment size. I check out v5.11 and use this config: https://gist.github.com/dvyukov/6af25474d455437577a84213b0cc9178 This config gave my laptop a hard time ! Finally I was able to boot correctly to userspace, but I realized I used my sv48 branch...Either I fixed your issue along the way or I can't reproduce it, I'll give it a try tomorrow. Where is your branch? I could also test in my setup on your branch. You can find my branch int/alex/riscv_kernel_end_of_address_space_v2 here: https://github.com/AlexGhiti/riscv-linux.git No, it does not work for me. Source is on b61ab6c98de021398cd7734ea5fc3655e51e70f2 (HEAD, int/alex/riscv_kernel_end_of_address_space_v2) Config is https://gist.githubusercontent.com/dvyukov/6af25474d455437577a84213b0cc9178/raw/55b116522c14a8a98a7626d76df740d54f648ce5/gistfile1.txt riscv64-linux-gnu-gcc -v gcc version 10.2.1 20210110 (Debian 10.2.1-6+build1) qemu-system-riscv64 --version QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-3) qemu-system-riscv64 \ -machine virt -smp 2 -m 2G \ -device virtio-blk-device,drive=hd0 \ -drive file=image-riscv64,if=none,format=raw,id=hd0 \ -kernel arch/riscv/boot/Image \ -nographic \ -device virtio-rng-device,rng=rng0 -object rng-random,filename=/dev/urandom,id=rng0 \ -netdev user,id=net0,host=10.0.2.10,hostfwd=tcp::10022-:22 -device virtio-net-device,netdev=net0 \ -append "root=/dev/vda earlyprintk=serial console=ttyS0 oops=panic panic_on_warn=1 panic=86400 earlycon" It still
Re: riscv+KASAN does not boot
On Fri, Feb 19, 2021 at 11:26 PM 'Palmer Dabbelt' via syzkaller wrote: > > On Fri, 19 Feb 2021 10:53:43 PST (-0800), dvyu...@google.com wrote: > > On Fri, Feb 19, 2021 at 6:01 PM Alex Ghiti wrote: > >> > >> Hi Dmitry, > >> > >> Le 2/18/21 à 6:36 AM, Dmitry Vyukov a écrit : > >> > On Thu, Feb 18, 2021 at 8:54 AM Alex Ghiti wrote: > >> >> > >> >> Hi Dmitry, > >> >> > >> >>> On Wed, Feb 17, 2021 at 5:36 PM Alex Ghiti wrote: > >> > >> Le 2/16/21 à 11:42 PM, Dmitry Vyukov a écrit : > >> > On Tue, Feb 16, 2021 at 9:42 PM Alex Ghiti wrote: > >> >> > >> >> Hi Dmitry, > >> >> > >> >> Le 2/16/21 à 6:25 AM, Dmitry Vyukov a écrit : > >> >>> On Tue, Feb 16, 2021 at 12:17 PM Dmitry Vyukov > >> >>> wrote: > >> > >> On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov > >> wrote: > >> >> I was fixing KASAN support for my sv48 patchset so I took a > >> >> look at your > >> >> issue: I built a kernel on top of the branch riscv/fixes using > >> >> https://github.com/google/syzkaller/blob/269d24e857a757d09a898086a2fa6fa5d827c3e1/dashboard/config/linux/upstream-riscv64-kasan.config > >> >> and Buildroot 2020.11. I have the warnings regarding the use of > >> >> __virt_to_phys on wrong addresses (but that's normal since this > >> >> function > >> >> is used in virt_addr_valid) but not the segfaults you describe. > >> > > >> > Hi Alex, > >> > > >> > Let me try to rebuild buildroot image. Maybe there was something > >> > wrong > >> > with my build, though, I did 'make clean' before doing. But at > >> > the > >> > same time it worked back in June... > >> > > >> > Re WARNINGs, they indicate kernel bugs. I am working on setting > >> > up a > >> > syzbot instance on riscv. If there a WARNING during boot then the > >> > kernel will be marked as broken. No further testing will happen. > >> > Is it a mis-use of WARN_ON? If so, could anybody please remove > >> > it or > >> > replace it with pr_err. > >> > >> > >> Hi, > >> > >> I've localized one issue with riscv/KASAN: > >> KASAN breaks VDSO and that's I think the root cause of weird > >> faults I > >> saw earlier. The following patch fixes it. > >> Could somebody please upstream this fix? I don't know how to > >> add/run > >> tests for this. > >> Thanks > >> > >> diff --git a/arch/riscv/kernel/vdso/Makefile > >> b/arch/riscv/kernel/vdso/Makefile > >> index 0cfd6da784f84..cf3a383c1799d 100644 > >> --- a/arch/riscv/kernel/vdso/Makefile > >> +++ b/arch/riscv/kernel/vdso/Makefile > >> @@ -35,6 +35,7 @@ CFLAGS_REMOVE_vgettimeofday.o = > >> $(CC_FLAGS_FTRACE) -Os > >> # Disable gcov profiling for VDSO code > >> GCOV_PROFILE := n > >> KCOV_INSTRUMENT := n > >> +KASAN_SANITIZE := n > >> > >> # Force dependency > >> $(obj)/vdso.o: $(obj)/vdso.so > >> >> > >> >> What's weird is that I don't have any issue without this patch with > >> >> the > >> >> following config whereas it indeed seems required for KASAN. But > >> >> when > >> >> looking at the segfaults you got earlier, the segfault address is > >> >> 0xbb0 > >> >> and the cause is an instruction page fault: this address is the PLT > >> >> base > >> >> address in vdso.so and an instruction page fault would mean that > >> >> someone > >> >> tried to jump at this address, which is weird. At first sight, that > >> >> does > >> >> not seem related to your patch above, but clearly I may be wrong. > >> >> > >> >> Tobias, did you observe the same segfaults as Dmitry ? > >> > > >> > > >> > I noticed that not all buildroot images use VDSO, it seems to be > >> > dependent on libc settings (at least I think I changed it in the > >> > past). > >> > >> Ok, I used uClibc but then when using glibc, I have the same > >> segfaults, > >> only when KASAN is enabled. And your patch fixes the problem. I will > >> try > >> to take a look later to better understand the problem. > >> > >> > I also booted an image completely successfully including dhcpd/sshd > >> > start, but then my executable crashed in clock_gettime. The > >> > executable > >> > was build on linux/amd64 host with "riscv64-linux-gnu-gcc -static" > >> > (10.2.1). > >> > > >> > > >> >>> Second issue I am seeing seems to be related to text segment size. > >> >>> I check out v5.11 and use this config: > >> >>> https://gist.github.com/dvyukov/6af25474d455437577a84213b0cc9178 > >> >> > >> >> This config
Re: riscv+KASAN does not boot
On Fri, 19 Feb 2021 10:53:43 PST (-0800), dvyu...@google.com wrote: On Fri, Feb 19, 2021 at 6:01 PM Alex Ghiti wrote: Hi Dmitry, Le 2/18/21 à 6:36 AM, Dmitry Vyukov a écrit : > On Thu, Feb 18, 2021 at 8:54 AM Alex Ghiti wrote: >> >> Hi Dmitry, >> >>> On Wed, Feb 17, 2021 at 5:36 PM Alex Ghiti wrote: Le 2/16/21 à 11:42 PM, Dmitry Vyukov a écrit : > On Tue, Feb 16, 2021 at 9:42 PM Alex Ghiti wrote: >> >> Hi Dmitry, >> >> Le 2/16/21 à 6:25 AM, Dmitry Vyukov a écrit : >>> On Tue, Feb 16, 2021 at 12:17 PM Dmitry Vyukov wrote: On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov wrote: >> I was fixing KASAN support for my sv48 patchset so I took a look at your >> issue: I built a kernel on top of the branch riscv/fixes using >> https://github.com/google/syzkaller/blob/269d24e857a757d09a898086a2fa6fa5d827c3e1/dashboard/config/linux/upstream-riscv64-kasan.config >> and Buildroot 2020.11. I have the warnings regarding the use of >> __virt_to_phys on wrong addresses (but that's normal since this function >> is used in virt_addr_valid) but not the segfaults you describe. > > Hi Alex, > > Let me try to rebuild buildroot image. Maybe there was something wrong > with my build, though, I did 'make clean' before doing. But at the > same time it worked back in June... > > Re WARNINGs, they indicate kernel bugs. I am working on setting up a > syzbot instance on riscv. If there a WARNING during boot then the > kernel will be marked as broken. No further testing will happen. > Is it a mis-use of WARN_ON? If so, could anybody please remove it or > replace it with pr_err. Hi, I've localized one issue with riscv/KASAN: KASAN breaks VDSO and that's I think the root cause of weird faults I saw earlier. The following patch fixes it. Could somebody please upstream this fix? I don't know how to add/run tests for this. Thanks diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile index 0cfd6da784f84..cf3a383c1799d 100644 --- a/arch/riscv/kernel/vdso/Makefile +++ b/arch/riscv/kernel/vdso/Makefile @@ -35,6 +35,7 @@ CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os # Disable gcov profiling for VDSO code GCOV_PROFILE := n KCOV_INSTRUMENT := n +KASAN_SANITIZE := n # Force dependency $(obj)/vdso.o: $(obj)/vdso.so >> >> What's weird is that I don't have any issue without this patch with the >> following config whereas it indeed seems required for KASAN. But when >> looking at the segfaults you got earlier, the segfault address is 0xbb0 >> and the cause is an instruction page fault: this address is the PLT base >> address in vdso.so and an instruction page fault would mean that someone >> tried to jump at this address, which is weird. At first sight, that does >> not seem related to your patch above, but clearly I may be wrong. >> >> Tobias, did you observe the same segfaults as Dmitry ? > > > I noticed that not all buildroot images use VDSO, it seems to be > dependent on libc settings (at least I think I changed it in the > past). Ok, I used uClibc but then when using glibc, I have the same segfaults, only when KASAN is enabled. And your patch fixes the problem. I will try to take a look later to better understand the problem. > I also booted an image completely successfully including dhcpd/sshd > start, but then my executable crashed in clock_gettime. The executable > was build on linux/amd64 host with "riscv64-linux-gnu-gcc -static" > (10.2.1). > > >>> Second issue I am seeing seems to be related to text segment size. >>> I check out v5.11 and use this config: >>> https://gist.github.com/dvyukov/6af25474d455437577a84213b0cc9178 >> >> This config gave my laptop a hard time ! Finally I was able to boot >> correctly to userspace, but I realized I used my sv48 branch...Either I >> fixed your issue along the way or I can't reproduce it, I'll give it a >> try tomorrow. > > Where is your branch? I could also test in my setup on your branch. > You can find my branch int/alex/riscv_kernel_end_of_address_space_v2 here: https://github.com/AlexGhiti/riscv-linux.git >>> >>> No, it does not work for me. >>> >>> Source is on b61ab6c98de021398cd7734ea5fc3655e51e70f2 (HEAD, >>> int/alex/riscv_kernel_end_of_address_space_v2) >>> Config is https://gist.githubusercontent.com/dvyukov/6af25474d455437577a84213b0cc9178/raw/55b116522c14a8a98a7626d76df740d54f648ce5/gistfile1.txt >>> >>> riscv64-linux-gnu-gcc -v >>> gcc version 10.2.1
Re: riscv+KASAN does not boot
On Fri, Feb 19, 2021 at 6:01 PM Alex Ghiti wrote: > > Hi Dmitry, > > Le 2/18/21 à 6:36 AM, Dmitry Vyukov a écrit : > > On Thu, Feb 18, 2021 at 8:54 AM Alex Ghiti wrote: > >> > >> Hi Dmitry, > >> > >>> On Wed, Feb 17, 2021 at 5:36 PM Alex Ghiti wrote: > > Le 2/16/21 à 11:42 PM, Dmitry Vyukov a écrit : > > On Tue, Feb 16, 2021 at 9:42 PM Alex Ghiti wrote: > >> > >> Hi Dmitry, > >> > >> Le 2/16/21 à 6:25 AM, Dmitry Vyukov a écrit : > >>> On Tue, Feb 16, 2021 at 12:17 PM Dmitry Vyukov > >>> wrote: > > On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov > wrote: > >> I was fixing KASAN support for my sv48 patchset so I took a look > >> at your > >> issue: I built a kernel on top of the branch riscv/fixes using > >> https://github.com/google/syzkaller/blob/269d24e857a757d09a898086a2fa6fa5d827c3e1/dashboard/config/linux/upstream-riscv64-kasan.config > >> and Buildroot 2020.11. I have the warnings regarding the use of > >> __virt_to_phys on wrong addresses (but that's normal since this > >> function > >> is used in virt_addr_valid) but not the segfaults you describe. > > > > Hi Alex, > > > > Let me try to rebuild buildroot image. Maybe there was something > > wrong > > with my build, though, I did 'make clean' before doing. But at the > > same time it worked back in June... > > > > Re WARNINGs, they indicate kernel bugs. I am working on setting up a > > syzbot instance on riscv. If there a WARNING during boot then the > > kernel will be marked as broken. No further testing will happen. > > Is it a mis-use of WARN_ON? If so, could anybody please remove it or > > replace it with pr_err. > > > Hi, > > I've localized one issue with riscv/KASAN: > KASAN breaks VDSO and that's I think the root cause of weird faults I > saw earlier. The following patch fixes it. > Could somebody please upstream this fix? I don't know how to add/run > tests for this. > Thanks > > diff --git a/arch/riscv/kernel/vdso/Makefile > b/arch/riscv/kernel/vdso/Makefile > index 0cfd6da784f84..cf3a383c1799d 100644 > --- a/arch/riscv/kernel/vdso/Makefile > +++ b/arch/riscv/kernel/vdso/Makefile > @@ -35,6 +35,7 @@ CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) > -Os > # Disable gcov profiling for VDSO code > GCOV_PROFILE := n > KCOV_INSTRUMENT := n > +KASAN_SANITIZE := n > > # Force dependency > $(obj)/vdso.o: $(obj)/vdso.so > >> > >> What's weird is that I don't have any issue without this patch with the > >> following config whereas it indeed seems required for KASAN. But when > >> looking at the segfaults you got earlier, the segfault address is 0xbb0 > >> and the cause is an instruction page fault: this address is the PLT > >> base > >> address in vdso.so and an instruction page fault would mean that > >> someone > >> tried to jump at this address, which is weird. At first sight, that > >> does > >> not seem related to your patch above, but clearly I may be wrong. > >> > >> Tobias, did you observe the same segfaults as Dmitry ? > > > > > > I noticed that not all buildroot images use VDSO, it seems to be > > dependent on libc settings (at least I think I changed it in the > > past). > > Ok, I used uClibc but then when using glibc, I have the same segfaults, > only when KASAN is enabled. And your patch fixes the problem. I will try > to take a look later to better understand the problem. > > > I also booted an image completely successfully including dhcpd/sshd > > start, but then my executable crashed in clock_gettime. The executable > > was build on linux/amd64 host with "riscv64-linux-gnu-gcc -static" > > (10.2.1). > > > > > >>> Second issue I am seeing seems to be related to text segment size. > >>> I check out v5.11 and use this config: > >>> https://gist.github.com/dvyukov/6af25474d455437577a84213b0cc9178 > >> > >> This config gave my laptop a hard time ! Finally I was able to boot > >> correctly to userspace, but I realized I used my sv48 branch...Either I > >> fixed your issue along the way or I can't reproduce it, I'll give it a > >> try tomorrow. > > > > Where is your branch? I could also test in my setup on your branch. > > > > You can find my branch int/alex/riscv_kernel_end_of_address_space_v2 > here: https://github.com/AlexGhiti/riscv-linux.git > >>> > >>> No, it does not work for me. > >>> > >>> Source is on b61ab6c98de021398cd7734ea5fc3655e51e70f2 (HEAD, > >>>
Re: riscv+KASAN does not boot
Hi Dmitry, Le 2/18/21 à 6:36 AM, Dmitry Vyukov a écrit : On Thu, Feb 18, 2021 at 8:54 AM Alex Ghiti wrote: Hi Dmitry, On Wed, Feb 17, 2021 at 5:36 PM Alex Ghiti wrote: Le 2/16/21 à 11:42 PM, Dmitry Vyukov a écrit : On Tue, Feb 16, 2021 at 9:42 PM Alex Ghiti wrote: Hi Dmitry, Le 2/16/21 à 6:25 AM, Dmitry Vyukov a écrit : On Tue, Feb 16, 2021 at 12:17 PM Dmitry Vyukov wrote: On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov wrote: I was fixing KASAN support for my sv48 patchset so I took a look at your issue: I built a kernel on top of the branch riscv/fixes using https://github.com/google/syzkaller/blob/269d24e857a757d09a898086a2fa6fa5d827c3e1/dashboard/config/linux/upstream-riscv64-kasan.config and Buildroot 2020.11. I have the warnings regarding the use of __virt_to_phys on wrong addresses (but that's normal since this function is used in virt_addr_valid) but not the segfaults you describe. Hi Alex, Let me try to rebuild buildroot image. Maybe there was something wrong with my build, though, I did 'make clean' before doing. But at the same time it worked back in June... Re WARNINGs, they indicate kernel bugs. I am working on setting up a syzbot instance on riscv. If there a WARNING during boot then the kernel will be marked as broken. No further testing will happen. Is it a mis-use of WARN_ON? If so, could anybody please remove it or replace it with pr_err. Hi, I've localized one issue with riscv/KASAN: KASAN breaks VDSO and that's I think the root cause of weird faults I saw earlier. The following patch fixes it. Could somebody please upstream this fix? I don't know how to add/run tests for this. Thanks diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile index 0cfd6da784f84..cf3a383c1799d 100644 --- a/arch/riscv/kernel/vdso/Makefile +++ b/arch/riscv/kernel/vdso/Makefile @@ -35,6 +35,7 @@ CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os # Disable gcov profiling for VDSO code GCOV_PROFILE := n KCOV_INSTRUMENT := n +KASAN_SANITIZE := n # Force dependency $(obj)/vdso.o: $(obj)/vdso.so What's weird is that I don't have any issue without this patch with the following config whereas it indeed seems required for KASAN. But when looking at the segfaults you got earlier, the segfault address is 0xbb0 and the cause is an instruction page fault: this address is the PLT base address in vdso.so and an instruction page fault would mean that someone tried to jump at this address, which is weird. At first sight, that does not seem related to your patch above, but clearly I may be wrong. Tobias, did you observe the same segfaults as Dmitry ? I noticed that not all buildroot images use VDSO, it seems to be dependent on libc settings (at least I think I changed it in the past). Ok, I used uClibc but then when using glibc, I have the same segfaults, only when KASAN is enabled. And your patch fixes the problem. I will try to take a look later to better understand the problem. I also booted an image completely successfully including dhcpd/sshd start, but then my executable crashed in clock_gettime. The executable was build on linux/amd64 host with "riscv64-linux-gnu-gcc -static" (10.2.1). Second issue I am seeing seems to be related to text segment size. I check out v5.11 and use this config: https://gist.github.com/dvyukov/6af25474d455437577a84213b0cc9178 This config gave my laptop a hard time ! Finally I was able to boot correctly to userspace, but I realized I used my sv48 branch...Either I fixed your issue along the way or I can't reproduce it, I'll give it a try tomorrow. Where is your branch? I could also test in my setup on your branch. You can find my branch int/alex/riscv_kernel_end_of_address_space_v2 here: https://github.com/AlexGhiti/riscv-linux.git No, it does not work for me. Source is on b61ab6c98de021398cd7734ea5fc3655e51e70f2 (HEAD, int/alex/riscv_kernel_end_of_address_space_v2) Config is https://gist.githubusercontent.com/dvyukov/6af25474d455437577a84213b0cc9178/raw/55b116522c14a8a98a7626d76df740d54f648ce5/gistfile1.txt riscv64-linux-gnu-gcc -v gcc version 10.2.1 20210110 (Debian 10.2.1-6+build1) qemu-system-riscv64 --version QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-3) qemu-system-riscv64 \ -machine virt -smp 2 -m 2G \ -device virtio-blk-device,drive=hd0 \ -drive file=image-riscv64,if=none,format=raw,id=hd0 \ -kernel arch/riscv/boot/Image \ -nographic \ -device virtio-rng-device,rng=rng0 -object rng-random,filename=/dev/urandom,id=rng0 \ -netdev user,id=net0,host=10.0.2.10,hostfwd=tcp::10022-:22 -device virtio-net-device,netdev=net0 \ -append "root=/dev/vda earlyprintk=serial console=ttyS0 oops=panic panic_on_warn=1 panic=86400 earlycon" It still works for me but I had to disable CONFIG_DEBUG_INFO_BTF (I don't think that changes anything at runtime). But your above command line does not work for me as it appears you do not load any firmware, if I add -bios images/fw_jump.elf, it works. But
Re: riscv+KASAN does not boot
On Thu, Feb 18, 2021 at 8:54 AM Alex Ghiti wrote: > > Hi Dmitry, > > > On Wed, Feb 17, 2021 at 5:36 PM Alex Ghiti wrote: > >> > >> Le 2/16/21 à 11:42 PM, Dmitry Vyukov a écrit : > >>> On Tue, Feb 16, 2021 at 9:42 PM Alex Ghiti wrote: > > Hi Dmitry, > > Le 2/16/21 à 6:25 AM, Dmitry Vyukov a écrit : > > On Tue, Feb 16, 2021 at 12:17 PM Dmitry Vyukov > > wrote: > >> > >> On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov > >> wrote: > I was fixing KASAN support for my sv48 patchset so I took a look at > your > issue: I built a kernel on top of the branch riscv/fixes using > https://github.com/google/syzkaller/blob/269d24e857a757d09a898086a2fa6fa5d827c3e1/dashboard/config/linux/upstream-riscv64-kasan.config > and Buildroot 2020.11. I have the warnings regarding the use of > __virt_to_phys on wrong addresses (but that's normal since this > function > is used in virt_addr_valid) but not the segfaults you describe. > >>> > >>> Hi Alex, > >>> > >>> Let me try to rebuild buildroot image. Maybe there was something wrong > >>> with my build, though, I did 'make clean' before doing. But at the > >>> same time it worked back in June... > >>> > >>> Re WARNINGs, they indicate kernel bugs. I am working on setting up a > >>> syzbot instance on riscv. If there a WARNING during boot then the > >>> kernel will be marked as broken. No further testing will happen. > >>> Is it a mis-use of WARN_ON? If so, could anybody please remove it or > >>> replace it with pr_err. > >> > >> > >> Hi, > >> > >> I've localized one issue with riscv/KASAN: > >> KASAN breaks VDSO and that's I think the root cause of weird faults I > >> saw earlier. The following patch fixes it. > >> Could somebody please upstream this fix? I don't know how to add/run > >> tests for this. > >> Thanks > >> > >> diff --git a/arch/riscv/kernel/vdso/Makefile > >> b/arch/riscv/kernel/vdso/Makefile > >> index 0cfd6da784f84..cf3a383c1799d 100644 > >> --- a/arch/riscv/kernel/vdso/Makefile > >> +++ b/arch/riscv/kernel/vdso/Makefile > >> @@ -35,6 +35,7 @@ CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) > >> -Os > >> # Disable gcov profiling for VDSO code > >> GCOV_PROFILE := n > >> KCOV_INSTRUMENT := n > >> +KASAN_SANITIZE := n > >> > >> # Force dependency > >> $(obj)/vdso.o: $(obj)/vdso.so > > What's weird is that I don't have any issue without this patch with the > following config whereas it indeed seems required for KASAN. But when > looking at the segfaults you got earlier, the segfault address is 0xbb0 > and the cause is an instruction page fault: this address is the PLT base > address in vdso.so and an instruction page fault would mean that someone > tried to jump at this address, which is weird. At first sight, that does > not seem related to your patch above, but clearly I may be wrong. > > Tobias, did you observe the same segfaults as Dmitry ? > >>> > >>> > >>> I noticed that not all buildroot images use VDSO, it seems to be > >>> dependent on libc settings (at least I think I changed it in the > >>> past). > >> > >> Ok, I used uClibc but then when using glibc, I have the same segfaults, > >> only when KASAN is enabled. And your patch fixes the problem. I will try > >> to take a look later to better understand the problem. > >> > >>> I also booted an image completely successfully including dhcpd/sshd > >>> start, but then my executable crashed in clock_gettime. The executable > >>> was build on linux/amd64 host with "riscv64-linux-gnu-gcc -static" > >>> (10.2.1). > >>> > >>> > > Second issue I am seeing seems to be related to text segment size. > > I check out v5.11 and use this config: > > https://gist.github.com/dvyukov/6af25474d455437577a84213b0cc9178 > > This config gave my laptop a hard time ! Finally I was able to boot > correctly to userspace, but I realized I used my sv48 branch...Either I > fixed your issue along the way or I can't reproduce it, I'll give it a > try tomorrow. > >>> > >>> Where is your branch? I could also test in my setup on your branch. > >>> > >> > >> You can find my branch int/alex/riscv_kernel_end_of_address_space_v2 > >> here: https://github.com/AlexGhiti/riscv-linux.git > > > > No, it does not work for me. > > > > Source is on b61ab6c98de021398cd7734ea5fc3655e51e70f2 (HEAD, > > int/alex/riscv_kernel_end_of_address_space_v2) > > Config is > > https://gist.githubusercontent.com/dvyukov/6af25474d455437577a84213b0cc9178/raw/55b116522c14a8a98a7626d76df740d54f648ce5/gistfile1.txt > > > > riscv64-linux-gnu-gcc -v > > gcc version 10.2.1 20210110 (Debian 10.2.1-6+build1) > > > > qemu-system-riscv64 --version > > QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-3) > > > >
Re: riscv+KASAN does not boot
Hi Dmitry, On Wed, Feb 17, 2021 at 5:36 PM Alex Ghiti wrote: Le 2/16/21 à 11:42 PM, Dmitry Vyukov a écrit : On Tue, Feb 16, 2021 at 9:42 PM Alex Ghiti wrote: Hi Dmitry, Le 2/16/21 à 6:25 AM, Dmitry Vyukov a écrit : On Tue, Feb 16, 2021 at 12:17 PM Dmitry Vyukov wrote: On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov wrote: I was fixing KASAN support for my sv48 patchset so I took a look at your issue: I built a kernel on top of the branch riscv/fixes using https://github.com/google/syzkaller/blob/269d24e857a757d09a898086a2fa6fa5d827c3e1/dashboard/config/linux/upstream-riscv64-kasan.config and Buildroot 2020.11. I have the warnings regarding the use of __virt_to_phys on wrong addresses (but that's normal since this function is used in virt_addr_valid) but not the segfaults you describe. Hi Alex, Let me try to rebuild buildroot image. Maybe there was something wrong with my build, though, I did 'make clean' before doing. But at the same time it worked back in June... Re WARNINGs, they indicate kernel bugs. I am working on setting up a syzbot instance on riscv. If there a WARNING during boot then the kernel will be marked as broken. No further testing will happen. Is it a mis-use of WARN_ON? If so, could anybody please remove it or replace it with pr_err. Hi, I've localized one issue with riscv/KASAN: KASAN breaks VDSO and that's I think the root cause of weird faults I saw earlier. The following patch fixes it. Could somebody please upstream this fix? I don't know how to add/run tests for this. Thanks diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile index 0cfd6da784f84..cf3a383c1799d 100644 --- a/arch/riscv/kernel/vdso/Makefile +++ b/arch/riscv/kernel/vdso/Makefile @@ -35,6 +35,7 @@ CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os # Disable gcov profiling for VDSO code GCOV_PROFILE := n KCOV_INSTRUMENT := n +KASAN_SANITIZE := n # Force dependency $(obj)/vdso.o: $(obj)/vdso.so What's weird is that I don't have any issue without this patch with the following config whereas it indeed seems required for KASAN. But when looking at the segfaults you got earlier, the segfault address is 0xbb0 and the cause is an instruction page fault: this address is the PLT base address in vdso.so and an instruction page fault would mean that someone tried to jump at this address, which is weird. At first sight, that does not seem related to your patch above, but clearly I may be wrong. Tobias, did you observe the same segfaults as Dmitry ? I noticed that not all buildroot images use VDSO, it seems to be dependent on libc settings (at least I think I changed it in the past). Ok, I used uClibc but then when using glibc, I have the same segfaults, only when KASAN is enabled. And your patch fixes the problem. I will try to take a look later to better understand the problem. I also booted an image completely successfully including dhcpd/sshd start, but then my executable crashed in clock_gettime. The executable was build on linux/amd64 host with "riscv64-linux-gnu-gcc -static" (10.2.1). Second issue I am seeing seems to be related to text segment size. I check out v5.11 and use this config: https://gist.github.com/dvyukov/6af25474d455437577a84213b0cc9178 This config gave my laptop a hard time ! Finally I was able to boot correctly to userspace, but I realized I used my sv48 branch...Either I fixed your issue along the way or I can't reproduce it, I'll give it a try tomorrow. Where is your branch? I could also test in my setup on your branch. You can find my branch int/alex/riscv_kernel_end_of_address_space_v2 here: https://github.com/AlexGhiti/riscv-linux.git No, it does not work for me. Source is on b61ab6c98de021398cd7734ea5fc3655e51e70f2 (HEAD, int/alex/riscv_kernel_end_of_address_space_v2) Config is https://gist.githubusercontent.com/dvyukov/6af25474d455437577a84213b0cc9178/raw/55b116522c14a8a98a7626d76df740d54f648ce5/gistfile1.txt riscv64-linux-gnu-gcc -v gcc version 10.2.1 20210110 (Debian 10.2.1-6+build1) qemu-system-riscv64 --version QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-3) qemu-system-riscv64 \ -machine virt -smp 2 -m 2G \ -device virtio-blk-device,drive=hd0 \ -drive file=image-riscv64,if=none,format=raw,id=hd0 \ -kernel arch/riscv/boot/Image \ -nographic \ -device virtio-rng-device,rng=rng0 -object rng-random,filename=/dev/urandom,id=rng0 \ -netdev user,id=net0,host=10.0.2.10,hostfwd=tcp::10022-:22 -device virtio-net-device,netdev=net0 \ -append "root=/dev/vda earlyprintk=serial console=ttyS0 oops=panic panic_on_warn=1 panic=86400 earlycon" It still works for me but I had to disable CONFIG_DEBUG_INFO_BTF (I don't think that changes anything at runtime). But your above command line does not work for me as it appears you do not load any firmware, if I add -bios images/fw_jump.elf, it works. But then I don't know where your opensbi output below comes from... And regarding your issue with calling
Re: riscv+KASAN does not boot
On Wed, Feb 17, 2021 at 5:36 PM Alex Ghiti wrote: > > Le 2/16/21 à 11:42 PM, Dmitry Vyukov a écrit : > > On Tue, Feb 16, 2021 at 9:42 PM Alex Ghiti wrote: > >> > >> Hi Dmitry, > >> > >> Le 2/16/21 à 6:25 AM, Dmitry Vyukov a écrit : > >>> On Tue, Feb 16, 2021 at 12:17 PM Dmitry Vyukov wrote: > > On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov wrote: > >> I was fixing KASAN support for my sv48 patchset so I took a look at > >> your > >> issue: I built a kernel on top of the branch riscv/fixes using > >> https://github.com/google/syzkaller/blob/269d24e857a757d09a898086a2fa6fa5d827c3e1/dashboard/config/linux/upstream-riscv64-kasan.config > >> and Buildroot 2020.11. I have the warnings regarding the use of > >> __virt_to_phys on wrong addresses (but that's normal since this > >> function > >> is used in virt_addr_valid) but not the segfaults you describe. > > > > Hi Alex, > > > > Let me try to rebuild buildroot image. Maybe there was something wrong > > with my build, though, I did 'make clean' before doing. But at the > > same time it worked back in June... > > > > Re WARNINGs, they indicate kernel bugs. I am working on setting up a > > syzbot instance on riscv. If there a WARNING during boot then the > > kernel will be marked as broken. No further testing will happen. > > Is it a mis-use of WARN_ON? If so, could anybody please remove it or > > replace it with pr_err. > > > Hi, > > I've localized one issue with riscv/KASAN: > KASAN breaks VDSO and that's I think the root cause of weird faults I > saw earlier. The following patch fixes it. > Could somebody please upstream this fix? I don't know how to add/run > tests for this. > Thanks > > diff --git a/arch/riscv/kernel/vdso/Makefile > b/arch/riscv/kernel/vdso/Makefile > index 0cfd6da784f84..cf3a383c1799d 100644 > --- a/arch/riscv/kernel/vdso/Makefile > +++ b/arch/riscv/kernel/vdso/Makefile > @@ -35,6 +35,7 @@ CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os > # Disable gcov profiling for VDSO code > GCOV_PROFILE := n > KCOV_INSTRUMENT := n > +KASAN_SANITIZE := n > > # Force dependency > $(obj)/vdso.o: $(obj)/vdso.so > >> > >> What's weird is that I don't have any issue without this patch with the > >> following config whereas it indeed seems required for KASAN. But when > >> looking at the segfaults you got earlier, the segfault address is 0xbb0 > >> and the cause is an instruction page fault: this address is the PLT base > >> address in vdso.so and an instruction page fault would mean that someone > >> tried to jump at this address, which is weird. At first sight, that does > >> not seem related to your patch above, but clearly I may be wrong. > >> > >> Tobias, did you observe the same segfaults as Dmitry ? > > > > > > I noticed that not all buildroot images use VDSO, it seems to be > > dependent on libc settings (at least I think I changed it in the > > past). > > Ok, I used uClibc but then when using glibc, I have the same segfaults, > only when KASAN is enabled. And your patch fixes the problem. I will try > to take a look later to better understand the problem. > > > I also booted an image completely successfully including dhcpd/sshd > > start, but then my executable crashed in clock_gettime. The executable > > was build on linux/amd64 host with "riscv64-linux-gnu-gcc -static" > > (10.2.1). > > > > > >>> Second issue I am seeing seems to be related to text segment size. > >>> I check out v5.11 and use this config: > >>> https://gist.github.com/dvyukov/6af25474d455437577a84213b0cc9178 > >> > >> This config gave my laptop a hard time ! Finally I was able to boot > >> correctly to userspace, but I realized I used my sv48 branch...Either I > >> fixed your issue along the way or I can't reproduce it, I'll give it a > >> try tomorrow. > > > > Where is your branch? I could also test in my setup on your branch. > > > > You can find my branch int/alex/riscv_kernel_end_of_address_space_v2 > here: https://github.com/AlexGhiti/riscv-linux.git No, it does not work for me. Source is on b61ab6c98de021398cd7734ea5fc3655e51e70f2 (HEAD, int/alex/riscv_kernel_end_of_address_space_v2) Config is https://gist.githubusercontent.com/dvyukov/6af25474d455437577a84213b0cc9178/raw/55b116522c14a8a98a7626d76df740d54f648ce5/gistfile1.txt riscv64-linux-gnu-gcc -v gcc version 10.2.1 20210110 (Debian 10.2.1-6+build1) qemu-system-riscv64 --version QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-3) qemu-system-riscv64 \ -machine virt -smp 2 -m 2G \ -device virtio-blk-device,drive=hd0 \ -drive file=image-riscv64,if=none,format=raw,id=hd0 \ -kernel arch/riscv/boot/Image \ -nographic \ -device virtio-rng-device,rng=rng0 -object rng-random,filename=/dev/urandom,id=rng0 \ -netdev user,id=net0,host=10.0.2.10,hostfwd=tcp::10022-:22 -device
Re: riscv+KASAN does not boot
Le 2/16/21 à 11:42 PM, Dmitry Vyukov a écrit : On Tue, Feb 16, 2021 at 9:42 PM Alex Ghiti wrote: Hi Dmitry, Le 2/16/21 à 6:25 AM, Dmitry Vyukov a écrit : On Tue, Feb 16, 2021 at 12:17 PM Dmitry Vyukov wrote: On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov wrote: I was fixing KASAN support for my sv48 patchset so I took a look at your issue: I built a kernel on top of the branch riscv/fixes using https://github.com/google/syzkaller/blob/269d24e857a757d09a898086a2fa6fa5d827c3e1/dashboard/config/linux/upstream-riscv64-kasan.config and Buildroot 2020.11. I have the warnings regarding the use of __virt_to_phys on wrong addresses (but that's normal since this function is used in virt_addr_valid) but not the segfaults you describe. Hi Alex, Let me try to rebuild buildroot image. Maybe there was something wrong with my build, though, I did 'make clean' before doing. But at the same time it worked back in June... Re WARNINGs, they indicate kernel bugs. I am working on setting up a syzbot instance on riscv. If there a WARNING during boot then the kernel will be marked as broken. No further testing will happen. Is it a mis-use of WARN_ON? If so, could anybody please remove it or replace it with pr_err. Hi, I've localized one issue with riscv/KASAN: KASAN breaks VDSO and that's I think the root cause of weird faults I saw earlier. The following patch fixes it. Could somebody please upstream this fix? I don't know how to add/run tests for this. Thanks diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile index 0cfd6da784f84..cf3a383c1799d 100644 --- a/arch/riscv/kernel/vdso/Makefile +++ b/arch/riscv/kernel/vdso/Makefile @@ -35,6 +35,7 @@ CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os # Disable gcov profiling for VDSO code GCOV_PROFILE := n KCOV_INSTRUMENT := n +KASAN_SANITIZE := n # Force dependency $(obj)/vdso.o: $(obj)/vdso.so What's weird is that I don't have any issue without this patch with the following config whereas it indeed seems required for KASAN. But when looking at the segfaults you got earlier, the segfault address is 0xbb0 and the cause is an instruction page fault: this address is the PLT base address in vdso.so and an instruction page fault would mean that someone tried to jump at this address, which is weird. At first sight, that does not seem related to your patch above, but clearly I may be wrong. Tobias, did you observe the same segfaults as Dmitry ? I noticed that not all buildroot images use VDSO, it seems to be dependent on libc settings (at least I think I changed it in the past). Ok, I used uClibc but then when using glibc, I have the same segfaults, only when KASAN is enabled. And your patch fixes the problem. I will try to take a look later to better understand the problem. I also booted an image completely successfully including dhcpd/sshd start, but then my executable crashed in clock_gettime. The executable was build on linux/amd64 host with "riscv64-linux-gnu-gcc -static" (10.2.1). Second issue I am seeing seems to be related to text segment size. I check out v5.11 and use this config: https://gist.github.com/dvyukov/6af25474d455437577a84213b0cc9178 This config gave my laptop a hard time ! Finally I was able to boot correctly to userspace, but I realized I used my sv48 branch...Either I fixed your issue along the way or I can't reproduce it, I'll give it a try tomorrow. Where is your branch? I could also test in my setup on your branch. You can find my branch int/alex/riscv_kernel_end_of_address_space_v2 here: https://github.com/AlexGhiti/riscv-linux.git Thanks, Then trying to boot it using: QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-3) $ qemu-system-riscv64 -machine virt -smp 2 -m 4G ... It shows no output from the kernel whatsoever, even though I have earlycon and output shows very early with other configs. Kernel boots fine with defconfig and other smaller configs. If I enable KASAN_OUTLINE and CC_OPTIMIZE_FOR_SIZE, then this config also boots fine. Both of these options significantly reduce kernel size. However, I can also boot the kernel without these 2 configs, if I disable a whole lot of subsystem configs. This makes me think that there is an issue related to kernel size somewhere in qemu/bootloader/kernel bootstrap code. Does it make sense to you? Can somebody reproduce what I am seeing? > I did not bring any answer to your question, but at least you know I'm working on it, I'll keep you posted. Thanks for taking the time to setup syzkaller. Alex Thanks ___ linux-riscv mailing list linux-ri...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ___ linux-riscv mailing list linux-ri...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: riscv+KASAN does not boot
On Tue, Feb 16, 2021 at 9:42 PM Alex Ghiti wrote: > > Hi Dmitry, > > Le 2/16/21 à 6:25 AM, Dmitry Vyukov a écrit : > > On Tue, Feb 16, 2021 at 12:17 PM Dmitry Vyukov wrote: > >> > >> On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov wrote: > I was fixing KASAN support for my sv48 patchset so I took a look at your > issue: I built a kernel on top of the branch riscv/fixes using > https://github.com/google/syzkaller/blob/269d24e857a757d09a898086a2fa6fa5d827c3e1/dashboard/config/linux/upstream-riscv64-kasan.config > and Buildroot 2020.11. I have the warnings regarding the use of > __virt_to_phys on wrong addresses (but that's normal since this function > is used in virt_addr_valid) but not the segfaults you describe. > >>> > >>> Hi Alex, > >>> > >>> Let me try to rebuild buildroot image. Maybe there was something wrong > >>> with my build, though, I did 'make clean' before doing. But at the > >>> same time it worked back in June... > >>> > >>> Re WARNINGs, they indicate kernel bugs. I am working on setting up a > >>> syzbot instance on riscv. If there a WARNING during boot then the > >>> kernel will be marked as broken. No further testing will happen. > >>> Is it a mis-use of WARN_ON? If so, could anybody please remove it or > >>> replace it with pr_err. > >> > >> > >> Hi, > >> > >> I've localized one issue with riscv/KASAN: > >> KASAN breaks VDSO and that's I think the root cause of weird faults I > >> saw earlier. The following patch fixes it. > >> Could somebody please upstream this fix? I don't know how to add/run > >> tests for this. > >> Thanks > >> > >> diff --git a/arch/riscv/kernel/vdso/Makefile > >> b/arch/riscv/kernel/vdso/Makefile > >> index 0cfd6da784f84..cf3a383c1799d 100644 > >> --- a/arch/riscv/kernel/vdso/Makefile > >> +++ b/arch/riscv/kernel/vdso/Makefile > >> @@ -35,6 +35,7 @@ CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os > >> # Disable gcov profiling for VDSO code > >> GCOV_PROFILE := n > >> KCOV_INSTRUMENT := n > >> +KASAN_SANITIZE := n > >> > >> # Force dependency > >> $(obj)/vdso.o: $(obj)/vdso.so > > What's weird is that I don't have any issue without this patch with the > following config whereas it indeed seems required for KASAN. But when > looking at the segfaults you got earlier, the segfault address is 0xbb0 > and the cause is an instruction page fault: this address is the PLT base > address in vdso.so and an instruction page fault would mean that someone > tried to jump at this address, which is weird. At first sight, that does > not seem related to your patch above, but clearly I may be wrong. > > Tobias, did you observe the same segfaults as Dmitry ? I noticed that not all buildroot images use VDSO, it seems to be dependent on libc settings (at least I think I changed it in the past). I also booted an image completely successfully including dhcpd/sshd start, but then my executable crashed in clock_gettime. The executable was build on linux/amd64 host with "riscv64-linux-gnu-gcc -static" (10.2.1). > > Second issue I am seeing seems to be related to text segment size. > > I check out v5.11 and use this config: > > https://gist.github.com/dvyukov/6af25474d455437577a84213b0cc9178 > > This config gave my laptop a hard time ! Finally I was able to boot > correctly to userspace, but I realized I used my sv48 branch...Either I > fixed your issue along the way or I can't reproduce it, I'll give it a > try tomorrow. Where is your branch? I could also test in my setup on your branch. > > Then trying to boot it using: > > QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-3) > > $ qemu-system-riscv64 -machine virt -smp 2 -m 4G ... > > > > It shows no output from the kernel whatsoever, even though I have > > earlycon and output shows very early with other configs. > > Kernel boots fine with defconfig and other smaller configs. > > > > If I enable KASAN_OUTLINE and CC_OPTIMIZE_FOR_SIZE, then this config > > also boots fine. Both of these options significantly reduce kernel > > size. However, I can also boot the kernel without these 2 configs, if > > I disable a whole lot of subsystem configs. This makes me think that > > there is an issue related to kernel size somewhere in > > qemu/bootloader/kernel bootstrap code. > > Does it make sense to you? Can somebody reproduce what I am seeing? > > > I did not bring any answer to your question, but at least you know I'm > working on it, I'll keep you posted. > > Thanks for taking the time to setup syzkaller. > > Alex > > > Thanks > > > > ___ > > linux-riscv mailing list > > linux-ri...@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv > >
Re: riscv+KASAN does not boot
Hi Dmitry, Le 2/16/21 à 6:25 AM, Dmitry Vyukov a écrit : On Tue, Feb 16, 2021 at 12:17 PM Dmitry Vyukov wrote: On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov wrote: I was fixing KASAN support for my sv48 patchset so I took a look at your issue: I built a kernel on top of the branch riscv/fixes using https://github.com/google/syzkaller/blob/269d24e857a757d09a898086a2fa6fa5d827c3e1/dashboard/config/linux/upstream-riscv64-kasan.config and Buildroot 2020.11. I have the warnings regarding the use of __virt_to_phys on wrong addresses (but that's normal since this function is used in virt_addr_valid) but not the segfaults you describe. Hi Alex, Let me try to rebuild buildroot image. Maybe there was something wrong with my build, though, I did 'make clean' before doing. But at the same time it worked back in June... Re WARNINGs, they indicate kernel bugs. I am working on setting up a syzbot instance on riscv. If there a WARNING during boot then the kernel will be marked as broken. No further testing will happen. Is it a mis-use of WARN_ON? If so, could anybody please remove it or replace it with pr_err. Hi, I've localized one issue with riscv/KASAN: KASAN breaks VDSO and that's I think the root cause of weird faults I saw earlier. The following patch fixes it. Could somebody please upstream this fix? I don't know how to add/run tests for this. Thanks diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile index 0cfd6da784f84..cf3a383c1799d 100644 --- a/arch/riscv/kernel/vdso/Makefile +++ b/arch/riscv/kernel/vdso/Makefile @@ -35,6 +35,7 @@ CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os # Disable gcov profiling for VDSO code GCOV_PROFILE := n KCOV_INSTRUMENT := n +KASAN_SANITIZE := n # Force dependency $(obj)/vdso.o: $(obj)/vdso.so What's weird is that I don't have any issue without this patch with the following config whereas it indeed seems required for KASAN. But when looking at the segfaults you got earlier, the segfault address is 0xbb0 and the cause is an instruction page fault: this address is the PLT base address in vdso.so and an instruction page fault would mean that someone tried to jump at this address, which is weird. At first sight, that does not seem related to your patch above, but clearly I may be wrong. Tobias, did you observe the same segfaults as Dmitry ? Second issue I am seeing seems to be related to text segment size. I check out v5.11 and use this config: https://gist.github.com/dvyukov/6af25474d455437577a84213b0cc9178 This config gave my laptop a hard time ! Finally I was able to boot correctly to userspace, but I realized I used my sv48 branch...Either I fixed your issue along the way or I can't reproduce it, I'll give it a try tomorrow. Then trying to boot it using: QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-3) $ qemu-system-riscv64 -machine virt -smp 2 -m 4G ... It shows no output from the kernel whatsoever, even though I have earlycon and output shows very early with other configs. Kernel boots fine with defconfig and other smaller configs. If I enable KASAN_OUTLINE and CC_OPTIMIZE_FOR_SIZE, then this config also boots fine. Both of these options significantly reduce kernel size. However, I can also boot the kernel without these 2 configs, if I disable a whole lot of subsystem configs. This makes me think that there is an issue related to kernel size somewhere in qemu/bootloader/kernel bootstrap code. Does it make sense to you? Can somebody reproduce what I am seeing? > I did not bring any answer to your question, but at least you know I'm working on it, I'll keep you posted. Thanks for taking the time to setup syzkaller. Alex Thanks ___ linux-riscv mailing list linux-ri...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: riscv+KASAN does not boot
On 2021-02-16 at 12:17:30 +0100, Dmitry Vyukov wrote: > On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov wrote: > > > I was fixing KASAN support for my sv48 patchset so I took a look at your > > > issue: I built a kernel on top of the branch riscv/fixes using > > > https://github.com/google/syzkaller/blob/269d24e857a757d09a898086a2fa6fa5d827c3e1/dashboard/config/linux/upstream-riscv64-kasan.config > > > and Buildroot 2020.11. I have the warnings regarding the use of > > > __virt_to_phys on wrong addresses (but that's normal since this function > > > is used in virt_addr_valid) but not the segfaults you describe. > > > > Hi Alex, > > > > Let me try to rebuild buildroot image. Maybe there was something wrong > > with my build, though, I did 'make clean' before doing. But at the > > same time it worked back in June... > > > > Re WARNINGs, they indicate kernel bugs. I am working on setting up a > > syzbot instance on riscv. If there a WARNING during boot then the > > kernel will be marked as broken. No further testing will happen. > > Is it a mis-use of WARN_ON? If so, could anybody please remove it or > > replace it with pr_err. > > > Hi, > > I've localized one issue with riscv/KASAN: > KASAN breaks VDSO and that's I think the root cause of weird faults I > saw earlier. The following patch fixes it. > Could somebody please upstream this fix? I don't know how to add/run > tests for this. Thanks. I've tested the fix locally using vDSO selftests and sent the fix upstream [1] [1] https://lore.kernel.org/linux-riscv/20210216173305.2500-1-tklau...@distanz.ch/T/#u
Re: riscv+KASAN does not boot
On Tue, Feb 16, 2021 at 12:25 PM Dmitry Vyukov wrote:
>
> On Tue, Feb 16, 2021 at 12:17 PM Dmitry Vyukov wrote:
> >
> > On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov wrote:
> > > > I was fixing KASAN support for my sv48 patchset so I took a look at your
> > > > issue: I built a kernel on top of the branch riscv/fixes using
> > > > https://github.com/google/syzkaller/blob/269d24e857a757d09a898086a2fa6fa5d827c3e1/dashboard/config/linux/upstream-riscv64-kasan.config
> > > > and Buildroot 2020.11. I have the warnings regarding the use of
> > > > __virt_to_phys on wrong addresses (but that's normal since this function
> > > > is used in virt_addr_valid) but not the segfaults you describe.
> > >
> > > Hi Alex,
> > >
> > > Let me try to rebuild buildroot image. Maybe there was something wrong
> > > with my build, though, I did 'make clean' before doing. But at the
> > > same time it worked back in June...
> > >
> > > Re WARNINGs, they indicate kernel bugs. I am working on setting up a
> > > syzbot instance on riscv. If there a WARNING during boot then the
> > > kernel will be marked as broken. No further testing will happen.
> > > Is it a mis-use of WARN_ON? If so, could anybody please remove it or
> > > replace it with pr_err.
> >
> >
> > Hi,
> >
> > I've localized one issue with riscv/KASAN:
> > KASAN breaks VDSO and that's I think the root cause of weird faults I
> > saw earlier. The following patch fixes it.
> > Could somebody please upstream this fix? I don't know how to add/run
> > tests for this.
> > Thanks
> >
> > diff --git a/arch/riscv/kernel/vdso/Makefile
> > b/arch/riscv/kernel/vdso/Makefile
> > index 0cfd6da784f84..cf3a383c1799d 100644
> > --- a/arch/riscv/kernel/vdso/Makefile
> > +++ b/arch/riscv/kernel/vdso/Makefile
> > @@ -35,6 +35,7 @@ CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os
> > # Disable gcov profiling for VDSO code
> > GCOV_PROFILE := n
> > KCOV_INSTRUMENT := n
> > +KASAN_SANITIZE := n
> >
> > # Force dependency
> > $(obj)/vdso.o: $(obj)/vdso.so
>
>
>
> Second issue I am seeing seems to be related to text segment size.
> I check out v5.11 and use this config:
> https://gist.github.com/dvyukov/6af25474d455437577a84213b0cc9178
>
> Then trying to boot it using:
> QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-3)
> $ qemu-system-riscv64 -machine virt -smp 2 -m 4G ...
>
> It shows no output from the kernel whatsoever, even though I have
> earlycon and output shows very early with other configs.
> Kernel boots fine with defconfig and other smaller configs.
>
> If I enable KASAN_OUTLINE and CC_OPTIMIZE_FOR_SIZE, then this config
> also boots fine. Both of these options significantly reduce kernel
> size. However, I can also boot the kernel without these 2 configs, if
> I disable a whole lot of subsystem configs. This makes me think that
> there is an issue related to kernel size somewhere in
> qemu/bootloader/kernel bootstrap code.
> Does it make sense to you? Can somebody reproduce what I am seeing?
I am debugging the next issue with VDSO. clock_gettime is broken in
some weird way.
syzkaller has this function:
static uint64 current_time_ms(void)
{
struct timespec ts;
if (clock_gettime(CLOCK_MONOTONIC, ))
//if (syscall(SYS_clock_gettime, CLOCK_MONOTONIC, ))
fail("clock_gettime failed");
return (uint64)ts.tv_sec * 1000 + (uint64)ts.tv_nsec / 100;
}
When using clock_gettime it producer some nonsense that breaks all
timeouts (in particular monotonic time goes backwards):
pid=4343 now=836038064151457975
pid=4343 now=836038064151457975
pid=4343 now=836038064151457970
pid=4343 now=836038064151457971
When I tested it calling real syscall, it works as expected:
pid=4876 now=2493379
pid=4876 now=2493392
pid=4876 now=2493395
pid=4876 now=2493409
pid=4876 now=2493414
Is it a known issue? Any ideas?
Re: riscv+KASAN does not boot
On Tue, Feb 16, 2021 at 12:17 PM Dmitry Vyukov wrote: > > On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov wrote: > > > I was fixing KASAN support for my sv48 patchset so I took a look at your > > > issue: I built a kernel on top of the branch riscv/fixes using > > > https://github.com/google/syzkaller/blob/269d24e857a757d09a898086a2fa6fa5d827c3e1/dashboard/config/linux/upstream-riscv64-kasan.config > > > and Buildroot 2020.11. I have the warnings regarding the use of > > > __virt_to_phys on wrong addresses (but that's normal since this function > > > is used in virt_addr_valid) but not the segfaults you describe. > > > > Hi Alex, > > > > Let me try to rebuild buildroot image. Maybe there was something wrong > > with my build, though, I did 'make clean' before doing. But at the > > same time it worked back in June... > > > > Re WARNINGs, they indicate kernel bugs. I am working on setting up a > > syzbot instance on riscv. If there a WARNING during boot then the > > kernel will be marked as broken. No further testing will happen. > > Is it a mis-use of WARN_ON? If so, could anybody please remove it or > > replace it with pr_err. > > > Hi, > > I've localized one issue with riscv/KASAN: > KASAN breaks VDSO and that's I think the root cause of weird faults I > saw earlier. The following patch fixes it. > Could somebody please upstream this fix? I don't know how to add/run > tests for this. > Thanks > > diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile > index 0cfd6da784f84..cf3a383c1799d 100644 > --- a/arch/riscv/kernel/vdso/Makefile > +++ b/arch/riscv/kernel/vdso/Makefile > @@ -35,6 +35,7 @@ CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os > # Disable gcov profiling for VDSO code > GCOV_PROFILE := n > KCOV_INSTRUMENT := n > +KASAN_SANITIZE := n > > # Force dependency > $(obj)/vdso.o: $(obj)/vdso.so Second issue I am seeing seems to be related to text segment size. I check out v5.11 and use this config: https://gist.github.com/dvyukov/6af25474d455437577a84213b0cc9178 Then trying to boot it using: QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-3) $ qemu-system-riscv64 -machine virt -smp 2 -m 4G ... It shows no output from the kernel whatsoever, even though I have earlycon and output shows very early with other configs. Kernel boots fine with defconfig and other smaller configs. If I enable KASAN_OUTLINE and CC_OPTIMIZE_FOR_SIZE, then this config also boots fine. Both of these options significantly reduce kernel size. However, I can also boot the kernel without these 2 configs, if I disable a whole lot of subsystem configs. This makes me think that there is an issue related to kernel size somewhere in qemu/bootloader/kernel bootstrap code. Does it make sense to you? Can somebody reproduce what I am seeing? Thanks
Re: riscv+KASAN does not boot
On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov wrote: > > I was fixing KASAN support for my sv48 patchset so I took a look at your > > issue: I built a kernel on top of the branch riscv/fixes using > > https://github.com/google/syzkaller/blob/269d24e857a757d09a898086a2fa6fa5d827c3e1/dashboard/config/linux/upstream-riscv64-kasan.config > > and Buildroot 2020.11. I have the warnings regarding the use of > > __virt_to_phys on wrong addresses (but that's normal since this function > > is used in virt_addr_valid) but not the segfaults you describe. > > Hi Alex, > > Let me try to rebuild buildroot image. Maybe there was something wrong > with my build, though, I did 'make clean' before doing. But at the > same time it worked back in June... > > Re WARNINGs, they indicate kernel bugs. I am working on setting up a > syzbot instance on riscv. If there a WARNING during boot then the > kernel will be marked as broken. No further testing will happen. > Is it a mis-use of WARN_ON? If so, could anybody please remove it or > replace it with pr_err. Hi, I've localized one issue with riscv/KASAN: KASAN breaks VDSO and that's I think the root cause of weird faults I saw earlier. The following patch fixes it. Could somebody please upstream this fix? I don't know how to add/run tests for this. Thanks diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile index 0cfd6da784f84..cf3a383c1799d 100644 --- a/arch/riscv/kernel/vdso/Makefile +++ b/arch/riscv/kernel/vdso/Makefile @@ -35,6 +35,7 @@ CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os # Disable gcov profiling for VDSO code GCOV_PROFILE := n KCOV_INSTRUMENT := n +KASAN_SANITIZE := n # Force dependency $(obj)/vdso.o: $(obj)/vdso.so
Re: riscv+KASAN does not boot
Hi Dmitry, On 1/18/21 10:43 AM, Dmitry Vyukov wrote: On Mon, Jan 18, 2021 at 4:05 PM Dmitry Vyukov wrote: On Mon, Jan 18, 2021 at 3:53 PM Tobias Klauser wrote: On Thu, Jan 14, 2021 at 5:57 AM Palmer Dabbelt wrote: On Fri, 25 Dec 2020 09:13:23 PST (-0800), dvyu...@google.com wrote: On Fri, Dec 25, 2020 at 5:58 PM Andreas Schwab wrote: On Dez 25 2020, Dmitry Vyukov wrote: qemu-system-riscv64 \ -machine virt -bios default -smp 1 -m 2G \ -device virtio-blk-device,drive=hd0 \ -drive file=buildroot-riscv64.ext4,if=none,format=raw,id=hd0 \ -kernel arch/riscv/boot/Image \ -nographic \ -device virtio-rng-device,rng=rng0 -object rng-random,filename=/dev/urandom,id=rng0 \ -netdev user,id=net0,host=10.0.2.10,hostfwd=tcp::10022-:22 -device virtio-net-device,netdev=net0 \ -append "root=/dev/vda earlyprintk=serial console=ttyS0 oops=panic panic_on_warn=1 panic=86400" Do you get more output with earlycon=sbi? Hi Andreas, For defconfig+kvm_guest.config+ scripts/config -e KASAN -e KASAN_INLINE it actually gave me more output: OpenSBI v0.7 _ _ / __ \ / | _ \_ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ \___ \| _ < | | | |__| | |_) | __/ | | |) | |_) || |_ \/| .__/ \___|_| |_|_/|/_| | | |_| Platform Name : QEMU Virt Machine Platform HART Features : RV64ACDFIMSU Current Hart : 0 Firmware Base : 0x8000 Firmware Size : 132 KB Runtime SBI Version: 0.2 MIDELEG : 0x0222 MEDELEG : 0xb109 PMP0: 0x8000-0x8003 (A) PMP1: 0x-0x (A,R,W,X) [0.00] Linux version 5.10.0-01370-g71c5f03154ac (dvyu...@dvyukov-desk.muc.corp.google.com) (riscv64-linux-gnu-gcc (Debian 10.2.0-9) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #17 SMP Fri Dec 25 18:10:12 CET 2020 [0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020 [0.00] earlycon: sbi0 at I/O port 0x0 (options '') [0.00] printk: bootconsole [sbi0] enabled [0.00] efi: UEFI not found. [0.00] Zone ranges: [0.00] DMA32[mem 0x8020-0x] [0.00] Normal empty [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x8020-0x] [0.00] Initmem setup node 0 [mem 0x8020-0x] [0.00] SBI specification v0.2 detected [0.00] SBI implementation ID=0x1 Version=0x7 [0.00] SBI v0.2 TIME extension detected [0.00] SBI v0.2 IPI extension detected [0.00] SBI v0.2 RFENCE extension detected [0.00] software IO TLB: mapped [mem 0xfa3f9000-0xfe3f9000] (64MB) [0.00] Unable to handle kernel paging request at virtual address dfc81004 [0.00] Oops [#1] [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0-01370-g71c5f03154ac #17 [0.00] epc: ffe00042e3e4 ra : ffe000c0462c sp : ffe001603ea0 [0.00] gp : ffe0016e3c60 tp : ffe00160cd40 t0 : dfc81004 [0.00] t1 : ffe000e0a838 t2 : s0 : ffe001603f50 [0.00] s1 : ffe0016e50a8 a0 : dfc81004 a1 : [0.00] a2 : 0ffc a3 : dfc82000 a4 : [0.00] a5 : 3e8c6001 a6 : ffe000e0a820 a7 : 0900 [0.00] s2 : dfc82000 s3 : dfc8 s4 : 0001 [0.00] s5 : ffe0016e5108 s6 : f000 s7 : dfc81004 [0.00] s8 : 0080 s9 : s10: ffe07a119000 [0.00] s11: ffc0 t3 : ffe0016eb908 t4 : 0001 [0.00] t5 : ffc4001c150a t6 : ffe001603be8 [0.00] status: 0100 badaddr: dfc81004 cause: 000f [0.00] random: get_random_bytes called from oops_exit+0x30/0x58 with crng_init=0 [0.00] ---[ end trace ]--- [0.00] Kernel panic - not syncing: Fatal exception [0.00] ---[ end Kernel panic - not syncing: Fatal exception ]--- But I first tried with a the kernel image I had in the dir, I think it was this config (no KASAN): https://gist.githubusercontent.com/dvyukov/b2b62beccf80493781ab03b41430e616/raw/62e673cff08a8a41656d2871b8a37f74b00f509f/gistfile1.txt and earlycon=sbi did not change anything (no output after OpenSBI). So potentially there are 2 different problems. Thanks for reporting this. Looks like I'd forgotten to add a kasan config to my tests. There's one in there now, and it's passing as of the fix that Nylon posted. I can boot the KASAN kernel now on riscv/fixes. Next problem: I've got only to: [ 90.498967][T1] Run /sbin/init as
Re: riscv+KASAN does not boot
On Mon, Jan 18, 2021 at 3:53 PM Tobias Klauser wrote: > > > On Thu, Jan 14, 2021 at 5:57 AM Palmer Dabbelt > > > wrote: > > > > > > > > On Fri, 25 Dec 2020 09:13:23 PST (-0800), dvyu...@google.com wrote: > > > > > On Fri, Dec 25, 2020 at 5:58 PM Andreas Schwab > > > > > wrote: > > > > >> > > > > >> On Dez 25 2020, Dmitry Vyukov wrote: > > > > >> > > > > >> > qemu-system-riscv64 \ > > > > >> > -machine virt -bios default -smp 1 -m 2G \ > > > > >> > -device virtio-blk-device,drive=hd0 \ > > > > >> > -drive file=buildroot-riscv64.ext4,if=none,format=raw,id=hd0 \ > > > > >> > -kernel arch/riscv/boot/Image \ > > > > >> > -nographic \ > > > > >> > -device virtio-rng-device,rng=rng0 -object > > > > >> > rng-random,filename=/dev/urandom,id=rng0 \ > > > > >> > -netdev user,id=net0,host=10.0.2.10,hostfwd=tcp::10022-:22 -device > > > > >> > virtio-net-device,netdev=net0 \ > > > > >> > -append "root=/dev/vda earlyprintk=serial console=ttyS0 oops=panic > > > > >> > panic_on_warn=1 panic=86400" > > > > >> > > > > >> Do you get more output with earlycon=sbi? > > > > > > > > > > Hi Andreas, > > > > > > > > > > For defconfig+kvm_guest.config+ scripts/config -e KASAN -e > > > > > KASAN_INLINE it actually gave me more output: > > > > > > > > > > > > > > > OpenSBI v0.7 > > > > >_ _ > > > > > / __ \ / | _ \_ _| > > > > > | | | |_ __ ___ _ __ | (___ | |_) || | > > > > > | | | | '_ \ / _ \ '_ \ \___ \| _ < | | > > > > > | |__| | |_) | __/ | | |) | |_) || |_ > > > > > \/| .__/ \___|_| |_|_/|/_| > > > > > | | > > > > > |_| > > > > > > > > > > Platform Name : QEMU Virt Machine > > > > > Platform HART Features : RV64ACDFIMSU > > > > > Current Hart : 0 > > > > > Firmware Base : 0x8000 > > > > > Firmware Size : 132 KB > > > > > Runtime SBI Version: 0.2 > > > > > > > > > > MIDELEG : 0x0222 > > > > > MEDELEG : 0xb109 > > > > > PMP0: 0x8000-0x8003 (A) > > > > > PMP1: 0x-0x (A,R,W,X) > > > > > [0.00] Linux version 5.10.0-01370-g71c5f03154ac > > > > > (dvyu...@dvyukov-desk.muc.corp.google.com) (riscv64-linux-gnu-gcc > > > > > (Debian 10.2.0-9) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #17 > > > > > SMP Fri Dec 25 18:10:12 CET 2020 > > > > > [0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020 > > > > > [0.00] earlycon: sbi0 at I/O port 0x0 (options '') > > > > > [0.00] printk: bootconsole [sbi0] enabled > > > > > [0.00] efi: UEFI not found. > > > > > [0.00] Zone ranges: > > > > > [0.00] DMA32[mem 0x8020-0x] > > > > > [0.00] Normal empty > > > > > [0.00] Movable zone start for each node > > > > > [0.00] Early memory node ranges > > > > > [0.00] node 0: [mem 0x8020-0x] > > > > > [0.00] Initmem setup node 0 [mem > > > > > 0x8020-0x] > > > > > [0.00] SBI specification v0.2 detected > > > > > [0.00] SBI implementation ID=0x1 Version=0x7 > > > > > [0.00] SBI v0.2 TIME extension detected > > > > > [0.00] SBI v0.2 IPI extension detected > > > > > [0.00] SBI v0.2 RFENCE extension detected > > > > > [0.00] software IO TLB: mapped [mem > > > > > 0xfa3f9000-0xfe3f9000] (64MB) > > > > > [0.00] Unable to handle kernel paging request at virtual > > > > > address dfc81004 > > > > > [0.00] Oops [#1] > > > > > [0.00] Modules linked in: > > > > > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted > > > > > 5.10.0-01370-g71c5f03154ac #17 > > > > > [0.00] epc: ffe00042e3e4 ra : ffe000c0462c sp : > > > > > ffe001603ea0 > > > > > [0.00] gp : ffe0016e3c60 tp : ffe00160cd40 t0 : > > > > > dfc81004 > > > > > [0.00] t1 : ffe000e0a838 t2 : s0 : > > > > > ffe001603f50 > > > > > [0.00] s1 : ffe0016e50a8 a0 : dfc81004 a1 : > > > > > > > > > > [0.00] a2 : 0ffc a3 : dfc82000 a4 : > > > > > > > > > > [0.00] a5 : 3e8c6001 a6 : ffe000e0a820 a7 : > > > > > 0900 > > > > > [0.00] s2 : dfc82000 s3 : dfc8 s4 : > > > > > 0001 > > > > > [0.00] s5 : ffe0016e5108 s6 : f000 s7 : > > > > > dfc81004 > > > > > [0.00] s8 : 0080 s9 : s10: > > > > > ffe07a119000 > > > > > [0.00] s11: ffc0 t3 : ffe0016eb908 t4 : > > > > > 0001 > > > > > [0.00] t5 : ffc4001c150a t6 : ffe001603be8 > > > > > [0.00] status: 0100 badaddr: dfc81004 > > > > > cause:
Re: riscv+KASAN does not boot
On Mon, Jan 18, 2021 at 4:05 PM Dmitry Vyukov wrote: > > On Mon, Jan 18, 2021 at 3:53 PM Tobias Klauser wrote: > > > > On Thu, Jan 14, 2021 at 5:57 AM Palmer Dabbelt > > > > wrote: > > > > > > > > > > On Fri, 25 Dec 2020 09:13:23 PST (-0800), dvyu...@google.com wrote: > > > > > > On Fri, Dec 25, 2020 at 5:58 PM Andreas Schwab > > > > > > wrote: > > > > > >> > > > > > >> On Dez 25 2020, Dmitry Vyukov wrote: > > > > > >> > > > > > >> > qemu-system-riscv64 \ > > > > > >> > -machine virt -bios default -smp 1 -m 2G \ > > > > > >> > -device virtio-blk-device,drive=hd0 \ > > > > > >> > -drive file=buildroot-riscv64.ext4,if=none,format=raw,id=hd0 \ > > > > > >> > -kernel arch/riscv/boot/Image \ > > > > > >> > -nographic \ > > > > > >> > -device virtio-rng-device,rng=rng0 -object > > > > > >> > rng-random,filename=/dev/urandom,id=rng0 \ > > > > > >> > -netdev user,id=net0,host=10.0.2.10,hostfwd=tcp::10022-:22 > > > > > >> > -device > > > > > >> > virtio-net-device,netdev=net0 \ > > > > > >> > -append "root=/dev/vda earlyprintk=serial console=ttyS0 > > > > > >> > oops=panic > > > > > >> > panic_on_warn=1 panic=86400" > > > > > >> > > > > > >> Do you get more output with earlycon=sbi? > > > > > > > > > > > > Hi Andreas, > > > > > > > > > > > > For defconfig+kvm_guest.config+ scripts/config -e KASAN -e > > > > > > KASAN_INLINE it actually gave me more output: > > > > > > > > > > > > > > > > > > OpenSBI v0.7 > > > > > >_ _ > > > > > > / __ \ / | _ \_ _| > > > > > > | | | |_ __ ___ _ __ | (___ | |_) || | > > > > > > | | | | '_ \ / _ \ '_ \ \___ \| _ < | | > > > > > > | |__| | |_) | __/ | | |) | |_) || |_ > > > > > > \/| .__/ \___|_| |_|_/|/_| > > > > > > | | > > > > > > |_| > > > > > > > > > > > > Platform Name : QEMU Virt Machine > > > > > > Platform HART Features : RV64ACDFIMSU > > > > > > Current Hart : 0 > > > > > > Firmware Base : 0x8000 > > > > > > Firmware Size : 132 KB > > > > > > Runtime SBI Version: 0.2 > > > > > > > > > > > > MIDELEG : 0x0222 > > > > > > MEDELEG : 0xb109 > > > > > > PMP0: 0x8000-0x8003 (A) > > > > > > PMP1: 0x-0x (A,R,W,X) > > > > > > [0.00] Linux version 5.10.0-01370-g71c5f03154ac > > > > > > (dvyu...@dvyukov-desk.muc.corp.google.com) (riscv64-linux-gnu-gcc > > > > > > (Debian 10.2.0-9) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) > > > > > > #17 > > > > > > SMP Fri Dec 25 18:10:12 CET 2020 > > > > > > [0.00] OF: fdt: Ignoring memory range 0x8000 - > > > > > > 0x8020 > > > > > > [0.00] earlycon: sbi0 at I/O port 0x0 (options '') > > > > > > [0.00] printk: bootconsole [sbi0] enabled > > > > > > [0.00] efi: UEFI not found. > > > > > > [0.00] Zone ranges: > > > > > > [0.00] DMA32[mem > > > > > > 0x8020-0x] > > > > > > [0.00] Normal empty > > > > > > [0.00] Movable zone start for each node > > > > > > [0.00] Early memory node ranges > > > > > > [0.00] node 0: [mem > > > > > > 0x8020-0x] > > > > > > [0.00] Initmem setup node 0 [mem > > > > > > 0x8020-0x] > > > > > > [0.00] SBI specification v0.2 detected > > > > > > [0.00] SBI implementation ID=0x1 Version=0x7 > > > > > > [0.00] SBI v0.2 TIME extension detected > > > > > > [0.00] SBI v0.2 IPI extension detected > > > > > > [0.00] SBI v0.2 RFENCE extension detected > > > > > > [0.00] software IO TLB: mapped [mem > > > > > > 0xfa3f9000-0xfe3f9000] (64MB) > > > > > > [0.00] Unable to handle kernel paging request at virtual > > > > > > address dfc81004 > > > > > > [0.00] Oops [#1] > > > > > > [0.00] Modules linked in: > > > > > > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted > > > > > > 5.10.0-01370-g71c5f03154ac #17 > > > > > > [0.00] epc: ffe00042e3e4 ra : ffe000c0462c sp : > > > > > > ffe001603ea0 > > > > > > [0.00] gp : ffe0016e3c60 tp : ffe00160cd40 t0 : > > > > > > dfc81004 > > > > > > [0.00] t1 : ffe000e0a838 t2 : s0 : > > > > > > ffe001603f50 > > > > > > [0.00] s1 : ffe0016e50a8 a0 : dfc81004 a1 : > > > > > > > > > > > > [0.00] a2 : 0ffc a3 : dfc82000 a4 : > > > > > > > > > > > > [0.00] a5 : 3e8c6001 a6 : ffe000e0a820 a7 : > > > > > > 0900 > > > > > > [0.00] s2 : dfc82000 s3 : dfc8 s4 : > > > > > > 0001 > > > > > > [0.00] s5 : ffe0016e5108 s6 : f000 s7 : > > > > > > dfc81004 > > > > > > [0.00] s8 :
Re: riscv+KASAN does not boot
On 2021-01-14 at 11:24:07 +0100, Dmitry Vyukov wrote: > On Thu, Jan 14, 2021 at 10:23 AM Dmitry Vyukov wrote: > > > > On Thu, Jan 14, 2021 at 5:57 AM Palmer Dabbelt > > wrote: > > > > > > On Fri, 25 Dec 2020 09:13:23 PST (-0800), dvyu...@google.com wrote: > > > > On Fri, Dec 25, 2020 at 5:58 PM Andreas Schwab > > > > wrote: > > > >> > > > >> On Dez 25 2020, Dmitry Vyukov wrote: > > > >> > > > >> > qemu-system-riscv64 \ > > > >> > -machine virt -bios default -smp 1 -m 2G \ > > > >> > -device virtio-blk-device,drive=hd0 \ > > > >> > -drive file=buildroot-riscv64.ext4,if=none,format=raw,id=hd0 \ > > > >> > -kernel arch/riscv/boot/Image \ > > > >> > -nographic \ > > > >> > -device virtio-rng-device,rng=rng0 -object > > > >> > rng-random,filename=/dev/urandom,id=rng0 \ > > > >> > -netdev user,id=net0,host=10.0.2.10,hostfwd=tcp::10022-:22 -device > > > >> > virtio-net-device,netdev=net0 \ > > > >> > -append "root=/dev/vda earlyprintk=serial console=ttyS0 oops=panic > > > >> > panic_on_warn=1 panic=86400" > > > >> > > > >> Do you get more output with earlycon=sbi? > > > > > > > > Hi Andreas, > > > > > > > > For defconfig+kvm_guest.config+ scripts/config -e KASAN -e > > > > KASAN_INLINE it actually gave me more output: > > > > > > > > > > > > OpenSBI v0.7 > > > >_ _ > > > > / __ \ / | _ \_ _| > > > > | | | |_ __ ___ _ __ | (___ | |_) || | > > > > | | | | '_ \ / _ \ '_ \ \___ \| _ < | | > > > > | |__| | |_) | __/ | | |) | |_) || |_ > > > > \/| .__/ \___|_| |_|_/|/_| > > > > | | > > > > |_| > > > > > > > > Platform Name : QEMU Virt Machine > > > > Platform HART Features : RV64ACDFIMSU > > > > Current Hart : 0 > > > > Firmware Base : 0x8000 > > > > Firmware Size : 132 KB > > > > Runtime SBI Version: 0.2 > > > > > > > > MIDELEG : 0x0222 > > > > MEDELEG : 0xb109 > > > > PMP0: 0x8000-0x8003 (A) > > > > PMP1: 0x-0x (A,R,W,X) > > > > [0.00] Linux version 5.10.0-01370-g71c5f03154ac > > > > (dvyu...@dvyukov-desk.muc.corp.google.com) (riscv64-linux-gnu-gcc > > > > (Debian 10.2.0-9) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #17 > > > > SMP Fri Dec 25 18:10:12 CET 2020 > > > > [0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020 > > > > [0.00] earlycon: sbi0 at I/O port 0x0 (options '') > > > > [0.00] printk: bootconsole [sbi0] enabled > > > > [0.00] efi: UEFI not found. > > > > [0.00] Zone ranges: > > > > [0.00] DMA32[mem 0x8020-0x] > > > > [0.00] Normal empty > > > > [0.00] Movable zone start for each node > > > > [0.00] Early memory node ranges > > > > [0.00] node 0: [mem 0x8020-0x] > > > > [0.00] Initmem setup node 0 [mem > > > > 0x8020-0x] > > > > [0.00] SBI specification v0.2 detected > > > > [0.00] SBI implementation ID=0x1 Version=0x7 > > > > [0.00] SBI v0.2 TIME extension detected > > > > [0.00] SBI v0.2 IPI extension detected > > > > [0.00] SBI v0.2 RFENCE extension detected > > > > [0.00] software IO TLB: mapped [mem > > > > 0xfa3f9000-0xfe3f9000] (64MB) > > > > [0.00] Unable to handle kernel paging request at virtual > > > > address dfc81004 > > > > [0.00] Oops [#1] > > > > [0.00] Modules linked in: > > > > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted > > > > 5.10.0-01370-g71c5f03154ac #17 > > > > [0.00] epc: ffe00042e3e4 ra : ffe000c0462c sp : > > > > ffe001603ea0 > > > > [0.00] gp : ffe0016e3c60 tp : ffe00160cd40 t0 : > > > > dfc81004 > > > > [0.00] t1 : ffe000e0a838 t2 : s0 : > > > > ffe001603f50 > > > > [0.00] s1 : ffe0016e50a8 a0 : dfc81004 a1 : > > > > > > > > [0.00] a2 : 0ffc a3 : dfc82000 a4 : > > > > > > > > [0.00] a5 : 3e8c6001 a6 : ffe000e0a820 a7 : > > > > 0900 > > > > [0.00] s2 : dfc82000 s3 : dfc8 s4 : > > > > 0001 > > > > [0.00] s5 : ffe0016e5108 s6 : f000 s7 : > > > > dfc81004 > > > > [0.00] s8 : 0080 s9 : s10: > > > > ffe07a119000 > > > > [0.00] s11: ffc0 t3 : ffe0016eb908 t4 : > > > > 0001 > > > > [0.00] t5 : ffc4001c150a t6 : ffe001603be8 > > > > [0.00] status: 0100 badaddr: dfc81004 > > > > cause: 000f > > > > [0.00] random: get_random_bytes called from > > > > oops_exit+0x30/0x58 with crng_init=0 > > > > [0.00] ---[ end
Re: riscv+KASAN does not boot
On Thu, Jan 14, 2021 at 11:24 AM Dmitry Vyukov wrote: > > On Thu, Jan 14, 2021 at 10:23 AM Dmitry Vyukov wrote: > > > > On Thu, Jan 14, 2021 at 5:57 AM Palmer Dabbelt > > wrote: > > > > > > On Fri, 25 Dec 2020 09:13:23 PST (-0800), dvyu...@google.com wrote: > > > > On Fri, Dec 25, 2020 at 5:58 PM Andreas Schwab > > > > wrote: > > > >> > > > >> On Dez 25 2020, Dmitry Vyukov wrote: > > > >> > > > >> > qemu-system-riscv64 \ > > > >> > -machine virt -bios default -smp 1 -m 2G \ > > > >> > -device virtio-blk-device,drive=hd0 \ > > > >> > -drive file=buildroot-riscv64.ext4,if=none,format=raw,id=hd0 \ > > > >> > -kernel arch/riscv/boot/Image \ > > > >> > -nographic \ > > > >> > -device virtio-rng-device,rng=rng0 -object > > > >> > rng-random,filename=/dev/urandom,id=rng0 \ > > > >> > -netdev user,id=net0,host=10.0.2.10,hostfwd=tcp::10022-:22 -device > > > >> > virtio-net-device,netdev=net0 \ > > > >> > -append "root=/dev/vda earlyprintk=serial console=ttyS0 oops=panic > > > >> > panic_on_warn=1 panic=86400" > > > >> > > > >> Do you get more output with earlycon=sbi? > > > > > > > > Hi Andreas, > > > > > > > > For defconfig+kvm_guest.config+ scripts/config -e KASAN -e > > > > KASAN_INLINE it actually gave me more output: > > > > > > > > > > > > OpenSBI v0.7 > > > >_ _ > > > > / __ \ / | _ \_ _| > > > > | | | |_ __ ___ _ __ | (___ | |_) || | > > > > | | | | '_ \ / _ \ '_ \ \___ \| _ < | | > > > > | |__| | |_) | __/ | | |) | |_) || |_ > > > > \/| .__/ \___|_| |_|_/|/_| > > > > | | > > > > |_| > > > > > > > > Platform Name : QEMU Virt Machine > > > > Platform HART Features : RV64ACDFIMSU > > > > Current Hart : 0 > > > > Firmware Base : 0x8000 > > > > Firmware Size : 132 KB > > > > Runtime SBI Version: 0.2 > > > > > > > > MIDELEG : 0x0222 > > > > MEDELEG : 0xb109 > > > > PMP0: 0x8000-0x8003 (A) > > > > PMP1: 0x-0x (A,R,W,X) > > > > [0.00] Linux version 5.10.0-01370-g71c5f03154ac > > > > (dvyu...@dvyukov-desk.muc.corp.google.com) (riscv64-linux-gnu-gcc > > > > (Debian 10.2.0-9) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #17 > > > > SMP Fri Dec 25 18:10:12 CET 2020 > > > > [0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020 > > > > [0.00] earlycon: sbi0 at I/O port 0x0 (options '') > > > > [0.00] printk: bootconsole [sbi0] enabled > > > > [0.00] efi: UEFI not found. > > > > [0.00] Zone ranges: > > > > [0.00] DMA32[mem 0x8020-0x] > > > > [0.00] Normal empty > > > > [0.00] Movable zone start for each node > > > > [0.00] Early memory node ranges > > > > [0.00] node 0: [mem 0x8020-0x] > > > > [0.00] Initmem setup node 0 [mem > > > > 0x8020-0x] > > > > [0.00] SBI specification v0.2 detected > > > > [0.00] SBI implementation ID=0x1 Version=0x7 > > > > [0.00] SBI v0.2 TIME extension detected > > > > [0.00] SBI v0.2 IPI extension detected > > > > [0.00] SBI v0.2 RFENCE extension detected > > > > [0.00] software IO TLB: mapped [mem > > > > 0xfa3f9000-0xfe3f9000] (64MB) > > > > [0.00] Unable to handle kernel paging request at virtual > > > > address dfc81004 > > > > [0.00] Oops [#1] > > > > [0.00] Modules linked in: > > > > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted > > > > 5.10.0-01370-g71c5f03154ac #17 > > > > [0.00] epc: ffe00042e3e4 ra : ffe000c0462c sp : > > > > ffe001603ea0 > > > > [0.00] gp : ffe0016e3c60 tp : ffe00160cd40 t0 : > > > > dfc81004 > > > > [0.00] t1 : ffe000e0a838 t2 : s0 : > > > > ffe001603f50 > > > > [0.00] s1 : ffe0016e50a8 a0 : dfc81004 a1 : > > > > > > > > [0.00] a2 : 0ffc a3 : dfc82000 a4 : > > > > > > > > [0.00] a5 : 3e8c6001 a6 : ffe000e0a820 a7 : > > > > 0900 > > > > [0.00] s2 : dfc82000 s3 : dfc8 s4 : > > > > 0001 > > > > [0.00] s5 : ffe0016e5108 s6 : f000 s7 : > > > > dfc81004 > > > > [0.00] s8 : 0080 s9 : s10: > > > > ffe07a119000 > > > > [0.00] s11: ffc0 t3 : ffe0016eb908 t4 : > > > > 0001 > > > > [0.00] t5 : ffc4001c150a t6 : ffe001603be8 > > > > [0.00] status: 0100 badaddr: dfc81004 > > > > cause: 000f > > > > [0.00] random: get_random_bytes called from > > > > oops_exit+0x30/0x58 with crng_init=0 > > > > [0.00] ---[
Re: riscv+KASAN does not boot
On Thu, Jan 14, 2021 at 10:23 AM Dmitry Vyukov wrote: > > On Thu, Jan 14, 2021 at 5:57 AM Palmer Dabbelt > wrote: > > > > On Fri, 25 Dec 2020 09:13:23 PST (-0800), dvyu...@google.com wrote: > > > On Fri, Dec 25, 2020 at 5:58 PM Andreas Schwab > > > wrote: > > >> > > >> On Dez 25 2020, Dmitry Vyukov wrote: > > >> > > >> > qemu-system-riscv64 \ > > >> > -machine virt -bios default -smp 1 -m 2G \ > > >> > -device virtio-blk-device,drive=hd0 \ > > >> > -drive file=buildroot-riscv64.ext4,if=none,format=raw,id=hd0 \ > > >> > -kernel arch/riscv/boot/Image \ > > >> > -nographic \ > > >> > -device virtio-rng-device,rng=rng0 -object > > >> > rng-random,filename=/dev/urandom,id=rng0 \ > > >> > -netdev user,id=net0,host=10.0.2.10,hostfwd=tcp::10022-:22 -device > > >> > virtio-net-device,netdev=net0 \ > > >> > -append "root=/dev/vda earlyprintk=serial console=ttyS0 oops=panic > > >> > panic_on_warn=1 panic=86400" > > >> > > >> Do you get more output with earlycon=sbi? > > > > > > Hi Andreas, > > > > > > For defconfig+kvm_guest.config+ scripts/config -e KASAN -e > > > KASAN_INLINE it actually gave me more output: > > > > > > > > > OpenSBI v0.7 > > >_ _ > > > / __ \ / | _ \_ _| > > > | | | |_ __ ___ _ __ | (___ | |_) || | > > > | | | | '_ \ / _ \ '_ \ \___ \| _ < | | > > > | |__| | |_) | __/ | | |) | |_) || |_ > > > \/| .__/ \___|_| |_|_/|/_| > > > | | > > > |_| > > > > > > Platform Name : QEMU Virt Machine > > > Platform HART Features : RV64ACDFIMSU > > > Current Hart : 0 > > > Firmware Base : 0x8000 > > > Firmware Size : 132 KB > > > Runtime SBI Version: 0.2 > > > > > > MIDELEG : 0x0222 > > > MEDELEG : 0xb109 > > > PMP0: 0x8000-0x8003 (A) > > > PMP1: 0x-0x (A,R,W,X) > > > [0.00] Linux version 5.10.0-01370-g71c5f03154ac > > > (dvyu...@dvyukov-desk.muc.corp.google.com) (riscv64-linux-gnu-gcc > > > (Debian 10.2.0-9) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #17 > > > SMP Fri Dec 25 18:10:12 CET 2020 > > > [0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020 > > > [0.00] earlycon: sbi0 at I/O port 0x0 (options '') > > > [0.00] printk: bootconsole [sbi0] enabled > > > [0.00] efi: UEFI not found. > > > [0.00] Zone ranges: > > > [0.00] DMA32[mem 0x8020-0x] > > > [0.00] Normal empty > > > [0.00] Movable zone start for each node > > > [0.00] Early memory node ranges > > > [0.00] node 0: [mem 0x8020-0x] > > > [0.00] Initmem setup node 0 [mem > > > 0x8020-0x] > > > [0.00] SBI specification v0.2 detected > > > [0.00] SBI implementation ID=0x1 Version=0x7 > > > [0.00] SBI v0.2 TIME extension detected > > > [0.00] SBI v0.2 IPI extension detected > > > [0.00] SBI v0.2 RFENCE extension detected > > > [0.00] software IO TLB: mapped [mem > > > 0xfa3f9000-0xfe3f9000] (64MB) > > > [0.00] Unable to handle kernel paging request at virtual > > > address dfc81004 > > > [0.00] Oops [#1] > > > [0.00] Modules linked in: > > > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted > > > 5.10.0-01370-g71c5f03154ac #17 > > > [0.00] epc: ffe00042e3e4 ra : ffe000c0462c sp : > > > ffe001603ea0 > > > [0.00] gp : ffe0016e3c60 tp : ffe00160cd40 t0 : > > > dfc81004 > > > [0.00] t1 : ffe000e0a838 t2 : s0 : > > > ffe001603f50 > > > [0.00] s1 : ffe0016e50a8 a0 : dfc81004 a1 : > > > > > > [0.00] a2 : 0ffc a3 : dfc82000 a4 : > > > > > > [0.00] a5 : 3e8c6001 a6 : ffe000e0a820 a7 : > > > 0900 > > > [0.00] s2 : dfc82000 s3 : dfc8 s4 : > > > 0001 > > > [0.00] s5 : ffe0016e5108 s6 : f000 s7 : > > > dfc81004 > > > [0.00] s8 : 0080 s9 : s10: > > > ffe07a119000 > > > [0.00] s11: ffc0 t3 : ffe0016eb908 t4 : > > > 0001 > > > [0.00] t5 : ffc4001c150a t6 : ffe001603be8 > > > [0.00] status: 0100 badaddr: dfc81004 > > > cause: 000f > > > [0.00] random: get_random_bytes called from > > > oops_exit+0x30/0x58 with crng_init=0 > > > [0.00] ---[ end trace ]--- > > > [0.00] Kernel panic - not syncing: Fatal exception > > > [0.00] ---[ end Kernel panic - not syncing: Fatal exception ]--- > > > > > > > > > But I first tried with a the kernel image I had in the dir, I think it > > > was
Re: riscv+KASAN does not boot
On Thu, Jan 14, 2021 at 5:57 AM Palmer Dabbelt wrote: > > On Fri, 25 Dec 2020 09:13:23 PST (-0800), dvyu...@google.com wrote: > > On Fri, Dec 25, 2020 at 5:58 PM Andreas Schwab > > wrote: > >> > >> On Dez 25 2020, Dmitry Vyukov wrote: > >> > >> > qemu-system-riscv64 \ > >> > -machine virt -bios default -smp 1 -m 2G \ > >> > -device virtio-blk-device,drive=hd0 \ > >> > -drive file=buildroot-riscv64.ext4,if=none,format=raw,id=hd0 \ > >> > -kernel arch/riscv/boot/Image \ > >> > -nographic \ > >> > -device virtio-rng-device,rng=rng0 -object > >> > rng-random,filename=/dev/urandom,id=rng0 \ > >> > -netdev user,id=net0,host=10.0.2.10,hostfwd=tcp::10022-:22 -device > >> > virtio-net-device,netdev=net0 \ > >> > -append "root=/dev/vda earlyprintk=serial console=ttyS0 oops=panic > >> > panic_on_warn=1 panic=86400" > >> > >> Do you get more output with earlycon=sbi? > > > > Hi Andreas, > > > > For defconfig+kvm_guest.config+ scripts/config -e KASAN -e > > KASAN_INLINE it actually gave me more output: > > > > > > OpenSBI v0.7 > >_ _ > > / __ \ / | _ \_ _| > > | | | |_ __ ___ _ __ | (___ | |_) || | > > | | | | '_ \ / _ \ '_ \ \___ \| _ < | | > > | |__| | |_) | __/ | | |) | |_) || |_ > > \/| .__/ \___|_| |_|_/|/_| > > | | > > |_| > > > > Platform Name : QEMU Virt Machine > > Platform HART Features : RV64ACDFIMSU > > Current Hart : 0 > > Firmware Base : 0x8000 > > Firmware Size : 132 KB > > Runtime SBI Version: 0.2 > > > > MIDELEG : 0x0222 > > MEDELEG : 0xb109 > > PMP0: 0x8000-0x8003 (A) > > PMP1: 0x-0x (A,R,W,X) > > [0.00] Linux version 5.10.0-01370-g71c5f03154ac > > (dvyu...@dvyukov-desk.muc.corp.google.com) (riscv64-linux-gnu-gcc > > (Debian 10.2.0-9) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #17 > > SMP Fri Dec 25 18:10:12 CET 2020 > > [0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020 > > [0.00] earlycon: sbi0 at I/O port 0x0 (options '') > > [0.00] printk: bootconsole [sbi0] enabled > > [0.00] efi: UEFI not found. > > [0.00] Zone ranges: > > [0.00] DMA32[mem 0x8020-0x] > > [0.00] Normal empty > > [0.00] Movable zone start for each node > > [0.00] Early memory node ranges > > [0.00] node 0: [mem 0x8020-0x] > > [0.00] Initmem setup node 0 [mem > > 0x8020-0x] > > [0.00] SBI specification v0.2 detected > > [0.00] SBI implementation ID=0x1 Version=0x7 > > [0.00] SBI v0.2 TIME extension detected > > [0.00] SBI v0.2 IPI extension detected > > [0.00] SBI v0.2 RFENCE extension detected > > [0.00] software IO TLB: mapped [mem > > 0xfa3f9000-0xfe3f9000] (64MB) > > [0.00] Unable to handle kernel paging request at virtual > > address dfc81004 > > [0.00] Oops [#1] > > [0.00] Modules linked in: > > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted > > 5.10.0-01370-g71c5f03154ac #17 > > [0.00] epc: ffe00042e3e4 ra : ffe000c0462c sp : > > ffe001603ea0 > > [0.00] gp : ffe0016e3c60 tp : ffe00160cd40 t0 : > > dfc81004 > > [0.00] t1 : ffe000e0a838 t2 : s0 : > > ffe001603f50 > > [0.00] s1 : ffe0016e50a8 a0 : dfc81004 a1 : > > > > [0.00] a2 : 0ffc a3 : dfc82000 a4 : > > > > [0.00] a5 : 3e8c6001 a6 : ffe000e0a820 a7 : > > 0900 > > [0.00] s2 : dfc82000 s3 : dfc8 s4 : > > 0001 > > [0.00] s5 : ffe0016e5108 s6 : f000 s7 : > > dfc81004 > > [0.00] s8 : 0080 s9 : s10: > > ffe07a119000 > > [0.00] s11: ffc0 t3 : ffe0016eb908 t4 : > > 0001 > > [0.00] t5 : ffc4001c150a t6 : ffe001603be8 > > [0.00] status: 0100 badaddr: dfc81004 > > cause: 000f > > [0.00] random: get_random_bytes called from > > oops_exit+0x30/0x58 with crng_init=0 > > [0.00] ---[ end trace ]--- > > [0.00] Kernel panic - not syncing: Fatal exception > > [0.00] ---[ end Kernel panic - not syncing: Fatal exception ]--- > > > > > > But I first tried with a the kernel image I had in the dir, I think it > > was this config (no KASAN): > > https://gist.githubusercontent.com/dvyukov/b2b62beccf80493781ab03b41430e616/raw/62e673cff08a8a41656d2871b8a37f74b00f509f/gistfile1.txt > > > > and earlycon=sbi did not change anything (no output after OpenSBI). > > So potentially there are 2 different
Re: riscv+KASAN does not boot
On Fri, 25 Dec 2020 09:13:23 PST (-0800), dvyu...@google.com wrote: On Fri, Dec 25, 2020 at 5:58 PM Andreas Schwab wrote: On Dez 25 2020, Dmitry Vyukov wrote: > qemu-system-riscv64 \ > -machine virt -bios default -smp 1 -m 2G \ > -device virtio-blk-device,drive=hd0 \ > -drive file=buildroot-riscv64.ext4,if=none,format=raw,id=hd0 \ > -kernel arch/riscv/boot/Image \ > -nographic \ > -device virtio-rng-device,rng=rng0 -object > rng-random,filename=/dev/urandom,id=rng0 \ > -netdev user,id=net0,host=10.0.2.10,hostfwd=tcp::10022-:22 -device > virtio-net-device,netdev=net0 \ > -append "root=/dev/vda earlyprintk=serial console=ttyS0 oops=panic > panic_on_warn=1 panic=86400" Do you get more output with earlycon=sbi? Hi Andreas, For defconfig+kvm_guest.config+ scripts/config -e KASAN -e KASAN_INLINE it actually gave me more output: OpenSBI v0.7 _ _ / __ \ / | _ \_ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ \___ \| _ < | | | |__| | |_) | __/ | | |) | |_) || |_ \/| .__/ \___|_| |_|_/|/_| | | |_| Platform Name : QEMU Virt Machine Platform HART Features : RV64ACDFIMSU Current Hart : 0 Firmware Base : 0x8000 Firmware Size : 132 KB Runtime SBI Version: 0.2 MIDELEG : 0x0222 MEDELEG : 0xb109 PMP0: 0x8000-0x8003 (A) PMP1: 0x-0x (A,R,W,X) [0.00] Linux version 5.10.0-01370-g71c5f03154ac (dvyu...@dvyukov-desk.muc.corp.google.com) (riscv64-linux-gnu-gcc (Debian 10.2.0-9) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #17 SMP Fri Dec 25 18:10:12 CET 2020 [0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020 [0.00] earlycon: sbi0 at I/O port 0x0 (options '') [0.00] printk: bootconsole [sbi0] enabled [0.00] efi: UEFI not found. [0.00] Zone ranges: [0.00] DMA32[mem 0x8020-0x] [0.00] Normal empty [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x8020-0x] [0.00] Initmem setup node 0 [mem 0x8020-0x] [0.00] SBI specification v0.2 detected [0.00] SBI implementation ID=0x1 Version=0x7 [0.00] SBI v0.2 TIME extension detected [0.00] SBI v0.2 IPI extension detected [0.00] SBI v0.2 RFENCE extension detected [0.00] software IO TLB: mapped [mem 0xfa3f9000-0xfe3f9000] (64MB) [0.00] Unable to handle kernel paging request at virtual address dfc81004 [0.00] Oops [#1] [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0-01370-g71c5f03154ac #17 [0.00] epc: ffe00042e3e4 ra : ffe000c0462c sp : ffe001603ea0 [0.00] gp : ffe0016e3c60 tp : ffe00160cd40 t0 : dfc81004 [0.00] t1 : ffe000e0a838 t2 : s0 : ffe001603f50 [0.00] s1 : ffe0016e50a8 a0 : dfc81004 a1 : [0.00] a2 : 0ffc a3 : dfc82000 a4 : [0.00] a5 : 3e8c6001 a6 : ffe000e0a820 a7 : 0900 [0.00] s2 : dfc82000 s3 : dfc8 s4 : 0001 [0.00] s5 : ffe0016e5108 s6 : f000 s7 : dfc81004 [0.00] s8 : 0080 s9 : s10: ffe07a119000 [0.00] s11: ffc0 t3 : ffe0016eb908 t4 : 0001 [0.00] t5 : ffc4001c150a t6 : ffe001603be8 [0.00] status: 0100 badaddr: dfc81004 cause: 000f [0.00] random: get_random_bytes called from oops_exit+0x30/0x58 with crng_init=0 [0.00] ---[ end trace ]--- [0.00] Kernel panic - not syncing: Fatal exception [0.00] ---[ end Kernel panic - not syncing: Fatal exception ]--- But I first tried with a the kernel image I had in the dir, I think it was this config (no KASAN): https://gist.githubusercontent.com/dvyukov/b2b62beccf80493781ab03b41430e616/raw/62e673cff08a8a41656d2871b8a37f74b00f509f/gistfile1.txt and earlycon=sbi did not change anything (no output after OpenSBI). So potentially there are 2 different problems. Thanks for reporting this. Looks like I'd forgotten to add a kasan config to my tests. There's one in there now, and it's passing as of the fix that Nylon posted.
Re: riscv+KASAN does not boot
On Fri, Dec 25, 2020 at 5:58 PM Andreas Schwab wrote: > > On Dez 25 2020, Dmitry Vyukov wrote: > > > qemu-system-riscv64 \ > > -machine virt -bios default -smp 1 -m 2G \ > > -device virtio-blk-device,drive=hd0 \ > > -drive file=buildroot-riscv64.ext4,if=none,format=raw,id=hd0 \ > > -kernel arch/riscv/boot/Image \ > > -nographic \ > > -device virtio-rng-device,rng=rng0 -object > > rng-random,filename=/dev/urandom,id=rng0 \ > > -netdev user,id=net0,host=10.0.2.10,hostfwd=tcp::10022-:22 -device > > virtio-net-device,netdev=net0 \ > > -append "root=/dev/vda earlyprintk=serial console=ttyS0 oops=panic > > panic_on_warn=1 panic=86400" > > Do you get more output with earlycon=sbi? Hi Andreas, For defconfig+kvm_guest.config+ scripts/config -e KASAN -e KASAN_INLINE it actually gave me more output: OpenSBI v0.7 _ _ / __ \ / | _ \_ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ \___ \| _ < | | | |__| | |_) | __/ | | |) | |_) || |_ \/| .__/ \___|_| |_|_/|/_| | | |_| Platform Name : QEMU Virt Machine Platform HART Features : RV64ACDFIMSU Current Hart : 0 Firmware Base : 0x8000 Firmware Size : 132 KB Runtime SBI Version: 0.2 MIDELEG : 0x0222 MEDELEG : 0xb109 PMP0: 0x8000-0x8003 (A) PMP1: 0x-0x (A,R,W,X) [0.00] Linux version 5.10.0-01370-g71c5f03154ac (dvyu...@dvyukov-desk.muc.corp.google.com) (riscv64-linux-gnu-gcc (Debian 10.2.0-9) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #17 SMP Fri Dec 25 18:10:12 CET 2020 [0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020 [0.00] earlycon: sbi0 at I/O port 0x0 (options '') [0.00] printk: bootconsole [sbi0] enabled [0.00] efi: UEFI not found. [0.00] Zone ranges: [0.00] DMA32[mem 0x8020-0x] [0.00] Normal empty [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x8020-0x] [0.00] Initmem setup node 0 [mem 0x8020-0x] [0.00] SBI specification v0.2 detected [0.00] SBI implementation ID=0x1 Version=0x7 [0.00] SBI v0.2 TIME extension detected [0.00] SBI v0.2 IPI extension detected [0.00] SBI v0.2 RFENCE extension detected [0.00] software IO TLB: mapped [mem 0xfa3f9000-0xfe3f9000] (64MB) [0.00] Unable to handle kernel paging request at virtual address dfc81004 [0.00] Oops [#1] [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0-01370-g71c5f03154ac #17 [0.00] epc: ffe00042e3e4 ra : ffe000c0462c sp : ffe001603ea0 [0.00] gp : ffe0016e3c60 tp : ffe00160cd40 t0 : dfc81004 [0.00] t1 : ffe000e0a838 t2 : s0 : ffe001603f50 [0.00] s1 : ffe0016e50a8 a0 : dfc81004 a1 : [0.00] a2 : 0ffc a3 : dfc82000 a4 : [0.00] a5 : 3e8c6001 a6 : ffe000e0a820 a7 : 0900 [0.00] s2 : dfc82000 s3 : dfc8 s4 : 0001 [0.00] s5 : ffe0016e5108 s6 : f000 s7 : dfc81004 [0.00] s8 : 0080 s9 : s10: ffe07a119000 [0.00] s11: ffc0 t3 : ffe0016eb908 t4 : 0001 [0.00] t5 : ffc4001c150a t6 : ffe001603be8 [0.00] status: 0100 badaddr: dfc81004 cause: 000f [0.00] random: get_random_bytes called from oops_exit+0x30/0x58 with crng_init=0 [0.00] ---[ end trace ]--- [0.00] Kernel panic - not syncing: Fatal exception [0.00] ---[ end Kernel panic - not syncing: Fatal exception ]--- But I first tried with a the kernel image I had in the dir, I think it was this config (no KASAN): https://gist.githubusercontent.com/dvyukov/b2b62beccf80493781ab03b41430e616/raw/62e673cff08a8a41656d2871b8a37f74b00f509f/gistfile1.txt and earlycon=sbi did not change anything (no output after OpenSBI). So potentially there are 2 different problems.
Re: riscv+KASAN does not boot
On Dez 25 2020, Dmitry Vyukov wrote: > qemu-system-riscv64 \ > -machine virt -bios default -smp 1 -m 2G \ > -device virtio-blk-device,drive=hd0 \ > -drive file=buildroot-riscv64.ext4,if=none,format=raw,id=hd0 \ > -kernel arch/riscv/boot/Image \ > -nographic \ > -device virtio-rng-device,rng=rng0 -object > rng-random,filename=/dev/urandom,id=rng0 \ > -netdev user,id=net0,host=10.0.2.10,hostfwd=tcp::10022-:22 -device > virtio-net-device,netdev=net0 \ > -append "root=/dev/vda earlyprintk=serial console=ttyS0 oops=panic > panic_on_warn=1 panic=86400" Do you get more output with earlycon=sbi? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
riscv+KASAN does not boot
Hello, I am considering setting up a syzbot instance for riscv arch (using qemu emulation) and testing kernel config/image/etc. I can boot defconfig+kvmconfig riscv kernel, but so far I can't get a booting CONFIG_KASAN+CONFIG+KCOV kernel. But first of all I would like to ask if the riscv port is stable enough at this point and if there is interest in continuous fuzzing and receiving bugs? If there is no interest, then the rest is not worth spending time on. Second, what git tree/branch should be used for testing (to find bugs sooner and get fixes faster)? Currently it seems that riscv/fixes is the most up-to-date branch with most fixes, is it the right one? Re non-booting kernel problem. If I do: defconfig+kvm_guest.config+ scripts/config -e KASAN -e KASAN_INLINE I only see OpenSBI banner and then nothing happens (qemu consumes 100% CPU). I've tried on v5.10, current upstream head (71c5f03154ac) and riscv/fixes (20620d72c31e). The result is the same. I see this recent patch from Nylon: https://lore.kernel.org/linux-riscv/1606727599-8598-1-git-send-email-nyl...@andestech.com/ which suggests that KASAN is working for Nylon. I am using qemu 5.1.0 as: qemu-system-riscv64 \ -machine virt -bios default -smp 1 -m 2G \ -device virtio-blk-device,drive=hd0 \ -drive file=buildroot-riscv64.ext4,if=none,format=raw,id=hd0 \ -kernel arch/riscv/boot/Image \ -nographic \ -device virtio-rng-device,rng=rng0 -object rng-random,filename=/dev/urandom,id=rng0 \ -netdev user,id=net0,host=10.0.2.10,hostfwd=tcp::10022-:22 -device virtio-net-device,netdev=net0 \ -append "root=/dev/vda earlyprintk=serial console=ttyS0 oops=panic panic_on_warn=1 panic=86400" I've also tried this config (slightly larger than defconfig, but does NOT include KASAN nor KCOV): https://gist.githubusercontent.com/dvyukov/b2b62beccf80493781ab03b41430e616/raw/62e673cff08a8a41656d2871b8a37f74b00f509f/gistfile1.txt and this is the ultimate large config that I would like to use: https://gist.githubusercontent.com/dvyukov/2b4e621d5252dbc5a2f28802b8d71d95/raw/3ef2b8d8eda60d3acfc4bf7916ffb9e77671ed76/gistfile1.txt Both of them hang after the OpenSBI banner in the same way. Is it a known issue? Am I doing something wrong? TIA
