linux-kernel - Re: [PATCH v4 1/4] powerpc: make llseek 32bit-only.

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: <CAK8P3a3DHqhbVToqRYqTmfCcSdT5sXb=1SO5jY9jDONDa6ORkA@mail.gmail.com>
Date:   Thu, 29 Aug 2019 16:32:50 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Michal Suchánek <msuchanek@...e.de>
Cc:     Michael Neuling <mikey@...ling.org>,
        Andrew Donnellan <andrew.donnellan@....ibm.com>,
        Nicolai Stange <nstange@...e.de>,
        David Hildenbrand <david@...hat.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Nicholas Piggin <npiggin@...il.com>,
        David Howells <dhowells@...hat.com>,
        Hari Bathini <hbathini@...ux.ibm.com>,
        Paul Mackerras <paulus@...ba.org>,
        Joel Stanley <joel@....id.au>,
        Christian Brauner <christian@...uner.io>,
        Firoz Khan <firoz.khan@...aro.org>,
        Breno Leitao <leitao@...ian.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        Allison Randal <allison@...utok.net>,
        "Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH v4 1/4] powerpc: make llseek 32bit-only.

On Thu, Aug 29, 2019 at 4:19 PM Michal Suchánek <msuchanek@...e.de> wrote:
> On Thu, 29 Aug 2019 14:57:39 +0200 Arnd Bergmann <arnd@...db.de> wrote:
> > On Thu, Aug 29, 2019 at 2:37 PM Michal Suchánek <msuchanek@...e.de> wrote:
> > > On Thu, 29 Aug 2019 14:19:46 +0200 Arnd Bergmann <arnd@...db.de> wrote:
> > > > On Thu, Aug 29, 2019 at 12:23 PM Michal Suchanek <msuchanek@...e.de> wrote:
> > > > In particular, I don't see why you single out llseek here, but leave other
> > > > syscalls that are not needed on 64-bit machines such as pread64().
> > >
> > > Because llseek is not built in fs/ when building 64bit only causing a
> > > link error.
> > >
> > > I initially posted patch to build it always but it was pointed out it
> > > is not needed, and  the interface does not make sense on 64bit, and
> > > that platforms that don't have it on 64bit now don't want that useless
> > > code.
> >
> > Ok, please put that into the changeset description then.
> >
> > I looked at uses of __NR__llseek in debian code search and
> > found this one:
> >
> > https://codesearch.debian.net/show?file=umview_0.8.2-1.2%2Fxmview%2Fum_mmap.c&line=328
> >
> > It looks like this application will try to use llseek instead of lseek
> > when built against kernel headers that define __NR_llseek.
> >
>
> The available documentation says this syscall is for 32bit only so
> using it on 64bit is undefined. The interface is not well-defined in
> that case either.

That's generally not how it works. If there is an existing application
that relies on the behavior of the system call interface, we should not
change it in a way that breaks the application, regardless of what the
documentation says. Presumably nobody cares about umview on
powerpc64, but there might be other applications doing the same
thing.

It looks like sparc64 and parisc64 do the same thing as powerpc64,
and provide llseek() calls that may or may not be used by
applications.

I think your original approach of always building sys_llseek on
powerpc64 is the safe choice here.

     Arnd