linux-kernel - Re: [PATCH] lkdtm: Test VMAP_STACK allocates leading/trailing guard pages

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170807220056.GA29059@remoulade>
Date:   Mon, 7 Aug 2017 23:00:56 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Kees Cook <keescook@...omium.org>
Cc:     linux-kernel@...r.kernel.org, ard.biesheuvel@...aro.org,
        catalin.marinas@....com, james.morse@....com, labbott@...hat.com,
        luto@...capital.net, matt@...eblueprint.co.uk, will.deacon@....com,
        kernel-hardening@...ts.openwall.com,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] lkdtm: Test VMAP_STACK allocates leading/trailing guard
 pages

Hi,

On Mon, Aug 07, 2017 at 01:39:48PM -0700, Kees Cook wrote:
> Two new tests STACK_GUARD_PAGE_LEADING and STACK_GUARD_PAGE_TRAILING
> attempt to read the byte before and after, respectively, of the current
> stack frame, which should fault under VMAP_STACK.
> 
> Signed-off-by: Kees Cook <keescook@...omium.org>
> ---
> Do these tests both trip with the new arm64 VMAP_STACK code?

> +/* Test that VMAP_STACK is actually allocating with a leading guard page */
> +void lkdtm_STACK_GUARD_PAGE_LEADING(void)
> +{
> +	const unsigned char *stack = task_stack_page(current);
> +	const unsigned char *ptr = stack - 1;
> +	volatile unsigned char byte;
> +
> +	pr_info("attempting bad read from page below current stack\n");
> +
> +	byte = *ptr;
> +
> +	pr_err("FAIL: accessed page before stack!\n");
> +}
> +
> +/* Test that VMAP_STACK is actually allocating with a trailing guard page */
> +void lkdtm_STACK_GUARD_PAGE_TRAILING(void)
> +{
> +	const unsigned char *stack = task_stack_page(current);
> +	const unsigned char *ptr = stack + THREAD_SIZE;
> +	volatile unsigned char byte;
> +
> +	pr_info("attempting bad read from page above current stack\n");
> +
> +	byte = *ptr;
> +
> +	pr_err("FAIL: accessed page after stack!\n");
> +}

I can give these a go tomorrow.

These *should* fault, and IIUC should trigger the usual "Unable to handle
kernel %s at virtual address %08lx\n" splat from arm64's __do_kernel_fault(),
which should end up with an Oops().

Since these don't mess with the SP, they shouldn't trigger the overflow
detection, which detects whether we have sufficient stack space to store the
exception context to the stack. That caught the LKDTM overflow test reliably.

Thanks,
Mark.