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]

Date:   Tue, 18 May 2021 16:05:44 +0200
From:   Arnd Bergmann <arnd@...nel.org>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     linux-arch <linux-arch@...r.kernel.org>,
        Christoph Hellwig <hch@...radead.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 3:41 PM Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
> Arnd Bergmann <arnd@...nel.org> writes:
>
> > From: Arnd Bergmann <arnd@...db.de>KEXEC_ARCH_DEFAULT
> >
> > The compat version of sys_kexec_load() uses compat_alloc_user_space to
> > convert the user-provided arguments into the native format.
> >
> > Move the conversion into the regular implementation with
> > an in_compat_syscall() check to simplify it and avoid the
> > compat_alloc_user_space() call.
> >
> > compat_sys_kexec_load() now behaves the same as sys_kexec_load().
>
> Nacked-by: "Eric W. Biederman" <ebiederm@...ssion.com>
>KEXEC_ARCH_DEFAULT
> The patch is wrong.
>
> The logic between the compat entry point and the ordinary entry point
> are by necessity different.   This unifies the logic and breaks the compat
> entry point.
>
> The fundamentally necessity is that the code being loaded needs to know
> which mode the kernel is running in so it can safely transition to the
> new kernel.
>
> Given that the two entry points fundamentally need different logic,
> and that difference was not preserved and the goal of this patchset
> was to unify that which fundamentally needs to be different.  I don't
> think this patch series makes any sense for kexec.

Sorry, I'm not following that explanation. Can you clarify what different
modes of the kernel you are referring to here, and how my patch
changes this?

The only difference I can see between the native and compat entry
points is the layout of the kexec_segment structure, and that is
obviously preserved by my patch.

         Arnd