| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <4595022.rnE6jSC6OK@diego>
Date: Wed, 25 May 2022 21:45:50 +0200
From: Heiko Stübner <heiko@...ech.de>
To: palmer@...osinc.com, arnd@...db.de, linux@...ck-us.net,
palmer@...belt.com, guoren@...nel.org
Cc: linux-riscv@...ts.infradead.org, linux-arch@...r.kernel.org,
linux-kernel@...r.kernel.org, Guo Ren <guoren@...ux.alibaba.com>,
Guo Ren <guoren@...nel.org>
Subject: Re: [PATCH] riscv: compat: Using seperated vdso_maps for compat_vdso_info
Am Mittwoch, 25. Mai 2022, 21:36:16 CEST schrieb Heiko Stübner:
> Am Mittwoch, 25. Mai 2022, 18:04:04 CEST schrieb guoren@...nel.org:
> > From: Guo Ren <guoren@...ux.alibaba.com>
> >
> > This is a fixup for vdso implementation which caused musl to
> > fail.
> >
> > [ 11.600082] Run /sbin/init as init process
> > [ 11.628561] init[1]: unhandled signal 11 code 0x1 at
> > 0x0000000000000000 in libc.so[ffffff8ad39000+a4000]
> > [ 11.629398] CPU: 0 PID: 1 Comm: init Not tainted
> > 5.18.0-rc7-next-20220520 #1
> > [ 11.629462] Hardware name: riscv-virtio,qemu (DT)
> > [ 11.629546] epc : 00ffffff8ada1100 ra : 00ffffff8ada13c8 sp :
> > 00ffffffc58199f0
> > [ 11.629586] gp : 00ffffff8ad39000 tp : 00ffffff8ade0998 t0 :
> > ffffffffffffffff
> > [ 11.629598] t1 : 00ffffffc5819fd0 t2 : 0000000000000000 s0 :
> > 00ffffff8ade0cc0
> > [ 11.629610] s1 : 00ffffff8ade0cc0 a0 : 0000000000000000 a1 :
> > 00ffffffc5819a00
> > [ 11.629622] a2 : 0000000000000001 a3 : 000000000000001e a4 :
> > 00ffffffc5819b00
> > [ 11.629634] a5 : 00ffffffc5819b00 a6 : 0000000000000000 a7 :
> > 0000000000000000
> > [ 11.629645] s2 : 00ffffff8ade0ac8 s3 : 00ffffff8ade0ec8 s4 :
> > 00ffffff8ade0728
> > [ 11.629656] s5 : 00ffffff8ade0a90 s6 : 0000000000000000 s7 :
> > 00ffffffc5819e40
> > [ 11.629667] s8 : 00ffffff8ade0ca0 s9 : 00ffffff8addba50 s10:
> > 0000000000000000
> > [ 11.629678] s11: 0000000000000000 t3 : 0000000000000002 t4 :
> > 0000000000000001
> > [ 11.629688] t5 : 0000000000020000 t6 : ffffffffffffffff
> > [ 11.629699] status: 0000000000004020 badaddr: 0000000000000000
> > cause: 000000000000000d
> >
> > The last __vdso_init(&compat_vdso_info) replaces the data in normal
> > vdso_info. This is an obvious bug.
> >
> > Reported-by: Guenter Roeck <linux@...ck-us.net>
> > Signed-off-by: Guo Ren <guoren@...ux.alibaba.com>
> > Signed-off-by: Guo Ren <guoren@...nel.org>
> > Cc: Palmer Dabbelt <palmer@...belt.com>
> > Cc: Heiko Stübner <heiko@...ech.de>
>
> on palmer's for-next branch and a Debian riscv64 rootfs:
>
> - WITHOUT this patch I end up with:
> [ 3.142030] Unable to handle kernel paging request at virtual address ff60007265776f78
> [ 3.144398] Oops [#1]
> [ 3.144882] Modules linked in:
> [ 3.145620] CPU: 1 PID: 1 Comm: init Not tainted 5.18.0-rc1-00049-g8810d7feee5a #225
> [ 3.146698] Hardware name: riscv-virtio,qemu (DT)
> [ 3.147441] epc : special_mapping_fault+0x4c/0x8e
> [ 3.148352] ra : __do_fault+0x28/0x11c
> [ 3.149005] epc : ffffffff8011ce3e ra : ffffffff80113216 sp : ff2000000060bd20
> [ 3.149851] gp : ffffffff810de540 tp : ff600000012a8000 t0 : ffffffff80008af0
> [ 3.150651] t1 : ffffffff80c001e0 t2 : ffffffff80c00260 s0 : ff2000000060bd30
> [ 3.151434] s1 : ff2000000060bd78 a0 : ff600000013165f0 a1 : ff60000001dbc450
> [ 3.152734] a2 : ff2000000060bd78 a3 : 00fffffffffff000 a4 : ff6000003f0337c8
> [ 3.153821] a5 : ff60007265776f70 a6 : 0000000000000000 a7 : 0000000000000007
> [ 3.154709] s2 : ff60000001dbc450 s3 : ff60000001dbc450 s4 : ffffffff810ddd69
> [ 3.155557] s5 : ff60000001dbc450 s6 : 0000000000000254 s7 : 000000000000000c
> [ 3.156369] s8 : 000000000000000f s9 : 000000000000000d s10: ff60000001cf8080
> [ 3.157242] s11: 000000000000000d t3 : 00ffffff8232d000 t4 : 000000006ffffdff
> [ 3.158094] t5 : 000000006ffffe35 t6 : 000000000000000a
> [ 3.158742] status: 0000000200000120 badaddr: ff60007265776f78 cause: 000000000000000d
> [ 3.160000] [<ffffffff80113216>] __do_fault+0x28/0x11c
> [ 3.160881] [<ffffffff80116f3e>] __handle_mm_fault+0x6ec/0x9c8
> [ 3.161619] [<ffffffff8011729c>] handle_mm_fault+0x82/0x136
> [ 3.162308] [<ffffffff80008c10>] do_page_fault+0x120/0x31c
> [ 3.163006] [<ffffffff800032dc>] ret_from_exception+0x0/0xc
> [ 3.164607] ---[ end trace 0000000000000000 ]---
> -> a different error
>
>
> - WITH this patch applied on top, the error above goes away and the
> qemu-system can boot normally.
The linux-next tree that failed for me yesterday, also works again
after this patch is applied.
Heiko
> So, while my error is different and I don't think there is any musl in
> my rootfs, this patch definitly fixes the issue for me, so
>
> Tested-by: Heiko Stuebner <heiko@...ech.de>
>
>
> > ---
> > arch/riscv/kernel/vdso.c | 15 +++++++++++++--
> > 1 file changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/riscv/kernel/vdso.c b/arch/riscv/kernel/vdso.c
> > index 50fe4c877603..69b05b6c181b 100644
> > --- a/arch/riscv/kernel/vdso.c
> > +++ b/arch/riscv/kernel/vdso.c
> > @@ -206,12 +206,23 @@ static struct __vdso_info vdso_info __ro_after_init = {
> > };
> >
> > #ifdef CONFIG_COMPAT
> > +static struct vm_special_mapping rv_compat_vdso_maps[] __ro_after_init = {
> > + [RV_VDSO_MAP_VVAR] = {
> > + .name = "[vvar]",
> > + .fault = vvar_fault,
> > + },
> > + [RV_VDSO_MAP_VDSO] = {
> > + .name = "[vdso]",
> > + .mremap = vdso_mremap,
> > + },
> > +};
> > +
> > static struct __vdso_info compat_vdso_info __ro_after_init = {
> > .name = "compat_vdso",
> > .vdso_code_start = compat_vdso_start,
> > .vdso_code_end = compat_vdso_end,
> > - .dm = &rv_vdso_maps[RV_VDSO_MAP_VVAR],
> > - .cm = &rv_vdso_maps[RV_VDSO_MAP_VDSO],
> > + .dm = &rv_compat_vdso_maps[RV_VDSO_MAP_VVAR],
> > + .cm = &rv_compat_vdso_maps[RV_VDSO_MAP_VDSO],
> > };
> > #endif
> >
> >
>
>
Powered by blists - more mailing lists