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] [day] [month] [year] [list]

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

On Thu, 29 Aug 2019 16:32:50 +0200
Arnd Bergmann <arnd@...db.de> wrote:

> 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.

Actually the umview headers go out of their way to define the llseek
syscall as invalid on x86_64 so that the non-llseek path is taken. 
mview-os/xmview/defs_x86_64_um.h:#define __NR__llseek __NR_doesnotexist
It is probably an oversight that this is not done on non-x86. I am not
even sure this builds on non-x86 out of the box.

> 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.

And if they are supposed to build with !compat it should be removed
there as well.

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

That's safe but adds junk to the kernel as pointed out in the reply to
that patch.

Thanks

Michal