linux-kernel - Re: [PATCH v2] x86/boot: Support uncompressed kernel

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, 4 Apr 2017 15:41:02 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Kees Cook <keescook@...omium.org>
Cc:     Chao Peng <chao.p.peng@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "x86@...nel.org" <x86@...nel.org>, Michal Marek <mmarek@...e.com>,
        Yinghai Lu <yinghai@...nel.org>, Baoquan He <bhe@...hat.com>,
        Jiri Kosina <jkosina@...e.cz>, "H.J. Lu" <hjl.tools@...il.com>,
        Paul Bolle <pebolle@...cali.nl>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Borislav Petkov <bp@...e.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Arnd Bergmann <arnd@...db.de>, Petr Mladek <pmladek@...e.com>,
        "David S. Miller" <davem@...emloft.net>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Garnier <thgarnie@...gle.com>,
        Nicolas Pitre <nicolas.pitre@...aro.org>,
        Tejun Heo <tj@...nel.org>, Daniel Mack <daniel@...que.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Helge Deller <deller@....de>, Rik van Riel <riel@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-kbuild <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH v2] x86/boot: Support uncompressed kernel

On Tue, Apr 4, 2017 at 12:14 PM, Kees Cook <keescook@...omium.org> wrote:
> On Tue, Apr 4, 2017 at 1:52 AM, Chao Peng <chao.p.peng@...ux.intel.com> wrote:
>> -                       memmove(dest, output + phdr->p_offset, phdr->p_filesz);
>> +                       memmove(dest, buf + phdr->p_offset, phdr->p_filesz);
>
> With the renaming from "buf" to "input" this becomes much more
> comprehensible: the PT_LOAD segments from "input" are loaded into
> "output". However, does this mean that the RAW load uses parse_elf to
> move the kernel into place? Does this happen safely? If it's already
> safe, shouldn't we not need "input" at all, and leave this as-is, like
> how the decompressed kernel operate?

This is a bit of a brain dump of what I learned when I played with
this code a couple weeks ago:

parse_elf() is incredibly fragile.  It seems to work correct in two cases:

1. We're randomizing.  As far as I can tell, it just works.

2. We get lucky and all the memmoves are backwards.  The first segment
overwrites the headers, the second segment may overwrite the first,
etc.  This also requires that the (missing, ahem) memsets to zero out
the ends of segments don't overwrite anything.  Of course, nothing
accounts for them now and adding the missing memset breaks the boot.

#2 is very fragile, needless to say.

I'd love to see the code that sets up the decompressor figure out much
wiggle room is actually needed and allocate accordingly.