kernel-hardening - Re: Investigating a stack state mismatch in Linux kernel

Follow @Openwall on Twitter for new release announcements and other news

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

Date: Fri, 23 Nov 2018 17:06:38 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: Alexander Popov <alex.popov@...ux.com>
cc: Florian Weimer <fweimer@...hat.com>, 
    Richard Sandiford <richard.sandiford@....com>, 
    Segher Boessenkool <segher@...nel.crashing.org>, 
    Kees Cook <keescook@...omium.org>, Ingo Molnar <mingo@...nel.org>, 
    Andy Lutomirski <luto@...nel.org>, Tycho Andersen <tycho@...ho.ws>, 
    Laura Abbott <labbott@...hat.com>, Mark Rutland <mark.rutland@....com>, 
    Ard Biesheuvel <ard.biesheuvel@...aro.org>, Borislav Petkov <bp@...en8.de>, 
    Thomas Gleixner <tglx@...utronix.de>, "H . Peter Anvin" <hpa@...or.com>, 
    Peter Zijlstra <a.p.zijlstra@...llo.nl>, Emese Revfy <re.emese@...il.com>, 
    Thomas Garnier <thgarnie@...gle.com>, Alexei Starovoitov <ast@...nel.org>, 
    Masami Hiramatsu <mhiramat@...nel.org>, 
    "David S . Miller" <davem@...emloft.net>, 
    Steven Rostedt <rostedt@...dmis.org>, 
    Dave Hansen <dave.hansen@...ux.intel.com>, 
    Will Deacon <will.deacon@....com>, Jann Horn <jannh@...gle.com>, 
    linux-arm-kernel@...ts.infradead.org, LKML <linux-kernel@...r.kernel.org>, 
    "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, 
    gcc@....gnu.org
Subject: Re: Investigating a stack state mismatch in Linux kernel

Hi,

On Wed, 21 Nov 2018, Alexander Popov wrote:

> Hello everyone!
> 
> At irc.freenode.org/#gcc people told me that I should CC gcc@....gnu.org to get
> some attention of gcc developers.
> 
> Link to previous discussion:
>  https://www.openwall.com/lists/kernel-hardening/2018/11/14/1

So just for information, it isn't a plugin bug. I'll elaborate below, but in
short, objtool was complaining about unreachable code.  To be fair though,
gcc could have made the problem easier to spot.

Now for the details.

The repro uses an unusual (randomized) kernel config, in particular gcov is
enabled and NR_CPUS is 1. Thus we have

static int duplicate_processor_ids[] = {
        [0 ... 1 - 1] = -1,
};

and the compiler deduces that the loop in acpi_duplicate_processor_id does not
iterate:

bool acpi_duplicate_processor_id(int proc_id)
{
        int i;

        for (i = 0; i < nr_duplicate_ids; i++) {
                if (duplicate_processor_ids[i] == proc_id)
                        return true;
        }
        return false;
}

However as gcov is enabled, loop backedge remains, followed by gcov counter
increment and __builtin_unreachable() (on GIMPLE). On RTL, however, the basic
block with the increment ends with a barrier rtx, which is not visible in
assembly and looks just as if control flow falls through to a function exit.
Since the exit in question corresponds to a shrink-wrapped early exit that
does not push/pop registers, objtool complains.

Ultimately this is poor luck, if gcc optimized the code better or terminated
the block that-should-not-be-reached with ud2, it would not arise.

Alexander

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.