Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sun, 5 May 2019 22:46:23 +0200
From:   Lukasz Majewski <lukma@denx.de>
To:     Stepan Golosunov <stepan@golosunov.pp.ru>
Cc:     Joseph Myers <joseph@codesourcery.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        linux-kernel@vger.kernel.org, libc-alpha@sourceware.org,
        Arnd Bergmann <arnd@arndb.de>, Paul Eggert <eggert@cs.ucla.edu>
Subject: Re: [PATCH v2 2/7] y2038: Introduce __ASSUME_64BIT_TIME define
Message-ID: <20190505224623.0212d919@jawa>
In-Reply-To: <20190505141053.gzff6q4j33x5vpiy@sghpc.golosunov.pp.ru>
References: <20190414220841.20243-1-lukma@denx.de>
        <20190429104613.16209-1-lukma@denx.de>
        <20190429104613.16209-3-lukma@denx.de>
        <alpine.DEB.2.21.1904292138430.21580@digraph.polyomino.org.uk>
        <20190430110505.2a0c7d1a@jawa>
        <alpine.DEB.2.21.1905021431060.4027@digraph.polyomino.org.uk>
        <20190505141053.gzff6q4j33x5vpiy@sghpc.golosunov.pp.ru>
Organization: denx.de
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 boundary="Sig_/i/ewWc4wg6kMKW48ipw7YbJ"; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--Sig_/i/ewWc4wg6kMKW48ipw7YbJ
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, 5 May 2019 18:10:54 +0400
Stepan Golosunov <stepan@golosunov.pp.ru> wrote:

> 02.05.2019 =D0=B2 15:04:18 +0000 Joseph Myers =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0=D0=BB:
> > On Tue, 30 Apr 2019, Lukasz Majewski wrote:
> >  =20
> > >  - The need for explicit clearing padding when calling syscalls
> > > (as to be better safe than sorry in the future - there was related
> > >    discussion started by Stepan). =20
> >=20
> > This really isn't a difficult question.  What it comes down to is
> > whether the Linux kernel, in the first release version with these
> > syscalls (we don't care about old -rc versions; what matters is the
> > actual 5.1 release), ignores the padding.
> >=20
> > If 5.1 *release* ignores the padding, that is part of the
> > kernel/userspace ABI, in accordance with the kernel principle of
> > not breaking userspace. Thus, it is something userspace can rely
> > on, now and in the future.
> >=20
> > If 5.1 release does not ignore the padding, syscall presence does
> > not mean the padding is ignored by the kernel and so glibc needs to
> > clear padding. Of course, it needs to clear padding in a *copy* of
> > the value provided by the user unless the glibc API in question
> > requires the timespec value in question to be in writable memory.
> >=20
> > So, which is (or will be) the case in 5.1 release?  Padding ignored
> > or not?  If more complicated (ignored for some architectures / ABIs
> > but not for others, or depending on whether compat syscalls are in
> > use), then say so - give a precise description of the exact
> > circumstances under which the padding around a 32-bit tv_nsec will
> > or will not be ignored by the kernel on input from userspace. =20
>=20
> In current linux git it looks like padding is correctly ignored in
> 32-bit kernels (because kernel itself has 32-bit tv_nsec there) but
> the code to clear it on compat syscalls in 64-bit kernels seems to be
> broken.
>=20
> The patch to fix this is at
>=20
> https://lore.kernel.org/lkml/20190429131951.471701-1-arnd@arndb.de/
>=20
> but it doesn't seem like it has reached Linus yet.
>=20

I hope that this patch will be pulled soon (before final cut) - for that
reason we can assume that the padding is ignored by the kernel and
hence do not explicitly clear it in glibc (as it was done in sent
patches)

>=20
> (Hmm.  I think that old ipc and socketcall syscalls in 32-bit kernels
> are broken without that patch too.  They would try to read
> __kernel_timespec when callers are passing old_timespec32.)

Please correct me if I'm wrong, but this problem is related to x32
machines (and not to ARM 32 bit ones with Y2038).


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

--Sig_/i/ewWc4wg6kMKW48ipw7YbJ
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAlzPS6AACgkQAR8vZIA0
zr2U9wgAx55Q2wg69sFMJgWdNJlcRX8An59Q3dNlxHfg97f8d+UK38mZjausITBj
5PWZv4p1jR7Aec3LSEOxYqVjOjFdc6Avs1QpYejNL4rZ4OQhvhtU+qFFLLwITwlR
nMTfmQ6hAWqR5us/vbuSBEexMA9B044d/fUKGv839IrhmQ0uqJqo3T8UCmEV7Cpp
uGnheXxPiDV1OZraPqY+z5t/c+eppVLWAjR78L4D84/EQYq4Kk9lkFv1uCROpSWN
XHUzPN0vWQe5vaqwwO6WTCy8Jg+zbcZTK6dhwqc7oCvlZGqAWVeDEedKzzrwaOd0
eZm3B1pedP7YBqIOjis9+eyfH3YFdA==
=pz2n
-----END PGP SIGNATURE-----

--Sig_/i/ewWc4wg6kMKW48ipw7YbJ--