[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87zixcqos0.fsf@gamma.ozlabs.ibm.com>
Date: Tue, 15 Dec 2015 16:11:43 +1100
From: Daniel Axtens <dja@...ens.net>
To: Michael Ellerman <mpe@...erman.id.au>, linuxppc-dev@...abs.org
Cc: linux-kernel@...r.kernel.org, andrew.donnellan@....ibm.com,
akpm@...ux-foundation.org,
Andrey Ryabinin <aryabinin@...tuozzo.com>
Subject: Re: [PATCH] powerpc: Enable UBSAN support
Michael Ellerman <mpe@...erman.id.au> writes:
> Hi Daniel,
>
> Great work thanks for getting this going.
>
> Have you tried running with KVM?
>
> I'm wondering if we should be excluding some of the KVM code that runs in real mode, eg:
>
> arch/powerpc/kvm/book3s_hv_rm_mmu.c
> arch/powerpc/kvm/book3s_hv_rm_xics.c
>
> And maybe some other bits.
>
> Also the early setup code, a/p/k/setup*.c might be dicey.
My philosphy was just to copy the GCOV excludes, although you're right
that perhaps we want to be more aggressive in excluding here given that
the UBSAN handlers print a bunch of stuff. I'm happy to respin with
further exclusions - they're really easy to add.
> In all of the above it's probably OK unless you actually hit a warning at the
> wrong point, so testing will probably not find problems. Although I guess we
> could add some deliberatly incorrect code at certain points and check we
> survive the warning.
Yep. I'll run a kvm guest on an instrumented kernel and let you know
what happens!
>
> Is there an easy way to spot the calls to UBSAN in the generated code?
Yes - because of the handler functions, they're *really* easy to spot.
Here's some assembly for GregorianDay():
c00000000002924c: 6d 26 7e 48 bl c00000000080b8b8 <__ubsan_handle_mul_overflow+0x8>
c000000000029250: 00 00 00 60 nop
c000000000029254: 38 fe ff 4b b c00000000002908c <GregorianDay+0xdc>
c000000000029258: 8c ff 62 3c addis r3,r2,-116
c00000000002925c: 01 00 a0 38 li r5,1
c000000000029260: 78 db 64 7f mr r4,r27
c000000000029264: 50 9c 63 38 addi r3,r3,-25520
c000000000029268: 41 26 7e 48 bl c00000000080b8a8 <__ubsan_handle_sub_overflow+0x8>
c00000000002926c: 00 00 00 60 nop
c000000000029270: 44 fe ff 4b b c0000000000290b4 <GregorianDay+0x104>
c000000000029274: 8c ff 62 3c addis r3,r2,-116
c000000000029278: 78 d3 45 7f mr r5,r26
c00000000002927c: e0 9c 63 38 addi r3,r3,-25376
c000000000029280: 19 26 7e 48 bl c00000000080b898 <__ubsan_handle_add_overflow+0x8>
c000000000029284: 00 00 00 60 nop
c000000000029288: 94 fe ff 4b b c00000000002911c <GregorianDay+0x16c>
c00000000002928c: 8c ff 62 3c addis r3,r2,-116
c000000000029290: 78 f3 c4 7f mr r4,r30
c000000000029294: 68 9c 63 38 addi r3,r3,-25496
c000000000029298: b1 21 7e 48 bl c00000000080b448 <__ubsan_handle_out_of_bounds+0x8>
c00000000002929c: 00 00 00 60 nop
c0000000000292a0: 20 fe ff 4b b c0000000000290c0 <GregorianDay+0x110>
c0000000000292a4: 14 4a 24 7d add r9,r4,r9
c0000000000292a8: 40 48 a4 7f cmpld cr7,r4,r9
c0000000000292ac: 2c fe fd 41 bgt+ cr7,c0000000000290d8 <GregorianDay+0x128>
You can see that there are lots of calls to __ubsan_handle_blah_blah
inserted.
Regards,
Daniel
>
> cheers
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Download attachment "signature.asc" of type "application/pgp-signature" (860 bytes)
Powered by blists - more mailing lists