linux-kernel - Re: [PATCH] lkdtm: print real addresses

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 27 Nov 2018 09:18:25 -0800
From:   Kees Cook <keescook@...omium.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Christophe Leroy <christophe.leroy@....fr>,
        Arnd Bergmann <arnd@...db.de>,
        LKML <linux-kernel@...r.kernel.org>,
        PowerPC <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH] lkdtm: print real addresses

On Mon, Nov 26, 2018 at 11:43 PM, Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> On Wed, Nov 07, 2018 at 08:14:10PM +0000, Christophe Leroy wrote:
>> Today, when doing a lkdtm test before the readiness of the
>> random generator, (ptrval) is printed instead of the address
>> at which it perform the fault:
>>
>> [ 1597.337030] lkdtm: Performing direct entry EXEC_USERSPACE
>> [ 1597.337142] lkdtm: attempting ok execution at (ptrval)
>> [ 1597.337398] lkdtm: attempting bad execution at (ptrval)
>> [ 1597.337460] kernel tried to execute user page (77858000) -exploit attempt? (uid: 0)
>> [ 1597.344769] Unable to handle kernel paging request for instruction fetch
>> [ 1597.351392] Faulting instruction address: 0x77858000
>> [ 1597.356312] Oops: Kernel access of bad area, sig: 11 [#1]
>>
>> If the lkdtm test is done later on, it prints an hashed address.
>>
>> In both cases this is pointless. The purpose of the test is to
>> ensure the kernel generates an Oops at the expected address,
>> so real addresses needs to be printed. This patch fixes that.
>
> I am pretty sure this is intentional.  Kees?

I've gone back and forth on this and in the end I decided I'd wait and
see if anyone was bothered by it besides just me. :) But, yes, for
lkdtm do really do want a "real" view of the pointer because we're
comparing it against page tables and/or kernel section layout, etc.

I've applied this to my lkdtm -next tree. Thanks!

-- 
Kees Cook