linux-kernel - Re: [PATCH v3 1/4] kexec: simplify compat_sys_kexec

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: <CAK8P3a0ecwY1hwDqhW7DyQMGR1a7xiQND=1s7Pd9OP7i5+hoWg@mail.gmail.com>
Date:   Tue, 18 May 2021 09:44:20 +0200
From:   Arnd Bergmann <arnd@...nel.org>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        linux-arch <linux-arch@...r.kernel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Borislav Petkov <bp@...en8.de>,
        Brian Gerst <brgerst@...il.com>,
        Ingo Molnar <mingo@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>, kexec@...ts.infradead.org
Subject: Re: [PATCH v3 1/4] kexec: simplify compat_sys_kexec_load

On Tue, May 18, 2021 at 8:40 AM Christoph Hellwig <hch@...radead.org> wrote:
>
> On Mon, May 17, 2021 at 10:57:24PM -0500, Eric W. Biederman wrote:
> > We open ourselves up to bugs whenever we lie to the type system.
> >
> > Skimming through the code it looks like it should be possible
> > to not need the in_compat_syscall and the casts to the wrong
> > type by changing the order of the code a little bit.

There are obviously other ways of doing the same. The reason for doing it
this specific way is so I can eliminate the compat entry point entirely in
patch 4/4.

> What kind of bug do you expect?  We must only copy from user addresses
> once anyway.  I've never seen bugs due the use of in_compat_syscall,
> but plenty due to cruft code trying to avoid it.

Right, I've used the same approach of passing a native-typed __user pointer
and converting it in a copy_from_user/copy_to_user wrapper in a number of
other places, as this tends to produce the most readable version by
concentrating the tricky logic in the one place that already has to be careful.

Most of the bugs I've seen with compat code are from duplicated code paths
that diverge over time when a bugfix for the native version is applied
incorrectly
or not at all to the compat version.

        Arnd