Le 27/02/2019 à 10:25, Dmitry Vyukov a écrit :
On Wed, Feb 27, 2019 at 10:18 AM Andrey Ryabinin
<aryabinin@xxxxxxxxxxxxx> wrote:
On 2/27/19 11:25 AM, Christophe Leroy wrote:
With version v8 of the series implementing KASAN on 32 bits powerpc (https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=94309), I'm now able to activate KASAN on a mac99 is QEMU.
Then I get the following reports at startup. Which of the two reports I get seems to depend on the option used to build the kernel, but for a given kernel I always get the same report.
Is that a real bug, in which case how could I spot it ? Or is it something wrong in my implementation of KASAN ?
I checked that after kasan_init(), the entire shadow memory is full of 0 only.
I also made a try with the strong STACK_PROTECTOR compiled in, but no difference and nothing detected by the stack protector.
==================================================================
BUG: KASAN: stack-out-of-bounds in memchr+0x24/0x74
Read of size 1 at addr c0ecdd40 by task swapper/0
CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc7+ #1133
Call Trace:
[c0e9dca0] [c01c42a0] print_address_description+0x64/0x2bc (unreliable)
[c0e9dcd0] [c01c4684] kasan_report+0xfc/0x180
[c0e9dd10] [c089579c] memchr+0x24/0x74
[c0e9dd30] [c00a9e38] msg_print_text+0x124/0x574
[c0e9dde0] [c00ab710] console_unlock+0x114/0x4f8
[c0e9de40] [c00adc60] vprintk_emit+0x188/0x1c4
--- interrupt: c0e9df00 at 0x400f330
LR = init_stack+0x1f00/0x2000
[c0e9de80] [c00ae3c4] printk+0xa8/0xcc (unreliable)
[c0e9df20] [c0c28e44] early_irq_init+0x38/0x108
[c0e9df50] [c0c16434] start_kernel+0x310/0x488
[c0e9dff0] [00003484] 0x3484
The buggy address belongs to the variable:
__log_buf+0xec0/0x4020
The buggy address belongs to the page:
page:c6eac9a0 count:1 mapcount:0 mapping:00000000 index:0x0
flags: 0x1000(reserved)
raw: 00001000 c6eac9a4 c6eac9a4 00000000 00000000 00000000 ffffffff 00000001
page dumped because: kasan: bad access detected
Memory state around the buggy address:
c0ecdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0ecdc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0ecdd00: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00
^
c0ecdd80: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
c0ecde00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
This one doesn't look good. Notice that it says stack-out-of-bounds, but at the same time there is
"The buggy address belongs to the variable: __log_buf+0xec0/0x4020"
which is printed by following code:
if (kernel_or_module_addr(addr) && !init_task_stack_addr(addr)) {
pr_err("The buggy address belongs to the variable:\n");
pr_err(" %pS\n", addr);
}
So the stack unrelated address got stack-related poisoning. This could be a stack overflow, did you increase THREAD_SHIFT?
KASAN with stack instrumentation significantly increases stack usage.
A straightforward explanation would be that this happens before real
shadow is mapped and we don't turn off KASAN reports. Should be easy
to check so worth eliminating this possibility before any other
debugging.
I confirm this happens _after_ the call of kasan_init() which sets up
the final shadow mapping. And after the call of kasan_init() I can
confirm that the entire shadow area is zeroized.
kasan_init() is called at the top of setup_arch() which is called soon
after the begining of start_kernel() (see 'KASAN init done' below).
early_irq_init() is called long after that.
Booting Linux via __start() @ 0x01000000 ...
Hello World !
Total memory = 128MB; using 256kB for hash table (at (ptrval))
Linux version 5.0.0-rc7+ (root@xxxxxxxxxxxxxxxxxxxxxxxxx) (gcc version
5.4.0 (GCC)) #1133 Tue Feb 26 03:30:01 UTC 2019
KASAN init done
Found UniNorth memory controller & host bridge @ 0xf8000000 revision: 0x07
Mapped at 0xf77c0000
Found a Keylargo mac-io controller, rev: 0, mapped at 0x(ptrval)
PowerMac motherboard: PowerMac G4 AGP Graphics
boot stdout isn't a display !
Using PowerMac machine description
printk: bootconsole [udbg0] enabled
-----------------------------------------------------
Hash_size = 0x40000
phys_mem_size = 0x8000000
dcache_bsize = 0x20
icache_bsize = 0x20
cpu_features = 0x000000000401a00a
possible = 0x000000002f7ff14b
always = 0x0000000000000000
cpu_user_features = 0x9c000001 0x00000000
mmu_features = 0x00000001
Hash = 0x(ptrval)
Hash_mask = 0xfff
-----------------------------------------------------
Found UniNorth PCI host bridge at 0x00000000f2000000. Firmware bus
number: 0->0
PCI host bridge /pci@f2000000 (primary) ranges:
IO 0x00000000f2000000..0x00000000f27fffff -> 0x0000000000000000
MEM 0x0000000080000000..0x000000008fffffff -> 0x0000000080000000
nvram: Checking bank 0...
Invalid signature
Invalid checksum
nvram: gen0=0, gen1=0
nvram: Active bank is: 0
nvram: OF partition at 0xffffffff
nvram: XP partition at 0xffffffff
nvram: NR partition at 0xffffffff
Zone ranges:
Normal [mem 0x0000000000000000-0x0000000007ffffff]
HighMem empty
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x0000000000000000-0x0000000007ffffff]
Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
Built 1 zonelists, mobility grouping on. Total pages: 32512
Kernel command line: console=/dev/ttyS0
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 93544K/131072K available (8868K kernel code, 1700K rwdata, 3484K
rodata, 1004K init, 4434K bss, 37528K reserved, 0K cma-reserved, 0K highmem)
Kernel virtual memory layout:
* 0xf8000000..0x00000000 : kasan shadow mem
* 0xf7fd0000..0xf8000000 : fixmap
* 0xf7800000..0xf7c00000 : highmem PTEs
* 0xf6f36000..0xf7800000 : early ioremap
* 0xc9000000..0xf6f36000 : vmalloc & ioremap
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
mpic: Setting up MPIC " MPIC 1 " version 1.2 at 80040000, max 1 CPUs
mpic: ISU size: 64, shift: 6, mask: 3f
mpic: Initializing for 64 sources
GMT Delta read from XPRAM: 0 minutes, DST: on
clocksource: timebase: mask: 0xffffffffffffffff max_cycles:
0x171024e7e0, max_idle_ns: 440795205315 ns
clocksource: timebase mult[a000000] shift[24] registered
==================================================================
BUG: KASAN: stack-out-of-bounds in memchr+0x24/0x74
Read of size 1 at addr c0ecdd40 by task swapper/0
...
Christophe
