On Thu, 2024-06-20 at 10:36 +0200, Alexander Potapenko wrote:
> On Wed, Jun 19, 2024 at 5:45 PM Ilya Leoshkevich <iii@xxxxxxxxxxxxx>
> wrote:
> >
> > put_user() uses inline assembly with precise constraints, so Clang
> > is
> > in principle capable of instrumenting it automatically.
> > Unfortunately,
> > one of the constraints contains a dereferenced user pointer, and
> > Clang
> > does not currently distinguish user and kernel pointers. Therefore
> > KMSAN attempts to access shadow for user pointers, which is not a
> > right
> > thing to do.
>
> By the way, how does this problem manifest?
> I was expecting KMSAN to generate dummy shadow accesses in this case,
> and reading/writing 1-8 bytes from dummy shadow shouldn't be a
> problem.
>
> (On the other hand, not inlining the get_user/put_user functions is
> probably still faster than retrieving the dummy shadow, so I'm fine
> either way)
We have two problems here: not only clang can't distinguish user and
kernel pointers, the KMSAN runtime - which is supposed to clean that
up - can't do that either due to overlapping kernel and user address
spaces on s390. So the instrumentation ultimately tries to access the
real shadow.
I forgot what the consequences of that were exactly, so I reverted the
patch and now I get:
Unable to handle kernel pointer dereference in virtual kernel address
space
Failing address: 000003fed25fa000 TEID: 000003fed25fa403
Fault in home space mode while using kernel ASCE.
AS:0000000005a70007 R3:00000000824d8007 S:0000000000000020
Oops: 0010 ilc:2 [#1] SMP
Modules linked in:
CPU: 3 PID: 1 Comm: init Tainted: G B N 6.10.0-rc4-
g8aadb00f495e #11
Hardware name: IBM 3931 A01 704 (KVM/Linux)
Krnl PSW : 0704c00180000000 000003ffe288975a (memset+0x3a/0xa0)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
Krnl GPRS: 0000000000000000 000003fed25fa180 000003fed25fa180
000003ffe28897a6
0000000000000007 000003ffe0000000 0000000000000000
000002ee06e68190
000002ee06f19000 000003fed25fa180 000003ffd25fa180
000003ffd25fa180
0000000000000008 0000000000000000 000003ffe17262e0
0000037ee000f730
Krnl Code: 000003ffe288974c: 41101100 la %r1,256(%r1)
000003ffe2889750: a737fffb brctg
%r3,000003ffe2889746
#000003ffe2889754: c03000000029 larl
%r3,000003ffe28897a6
>000003ffe288975a: 44403000 ex %r4,0(%r3)
000003ffe288975e: 07fe bcr 15,%r14
000003ffe2889760: a74f0001 cghi %r4,1
000003ffe2889764: b9040012 lgr %r1,%r2
000003ffe2889768: a784001c brc
8,000003ffe28897a0
Call Trace:
[<000003ffe288975a>] memset+0x3a/0xa0
([<000003ffe17262bc>] kmsan_internal_set_shadow_origin+0x21c/0x3a0)
[<000003ffe1725fb6>] kmsan_internal_unpoison_memory+0x26/0x30
[<000003ffe1c1c646>] create_elf_tables+0x13c6/0x2620
[<000003ffe1c0ebaa>] load_elf_binary+0x50da/0x68f0
[<000003ffe18c41fc>] bprm_execve+0x201c/0x2f40
[<000003ffe18bff9a>] kernel_execve+0x2cda/0x2d00
[<000003ffe49b745a>] kernel_init+0x9ba/0x1630
[<000003ffe000cd5c>] __ret_from_fork+0xbc/0x180
[<000003ffe4a1907a>] ret_from_fork+0xa/0x30
Last Breaking-Event-Address:
[<000003ffe2889742>] memset+0x22/0xa0
Kernel panic - not syncing: Fatal exception: panic_on_oops
So is_bad_asm_addr() returned false for a userspace address.
Why? Because it happened to collide with the kernel modules area:
precisely the effect of overlapping.
VMALLOC_START: 0x37ee0000000
VMALLOC_END: 0x3a960000000
MODULES_VADDR: 0x3ff60000000
Address: 0x3ffd157a580
MODULES_END: 0x3ffe0000000
Now the question is, why do we crash when accessing shadow for modules?
I'll need to investigate, this does not look normal. But even if that
worked, we clearly wouldn't want userspace accesses to pollute module
shadow, so I think we need this patch in its current form.
[...]
