linux-kernel - Re: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility reasons.

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: <08fe906c-56a4-abca-2587-36128ce48167@redhat.com>
Date:	Fri, 24 Jun 2016 13:33:02 +0200
From:	Florian Weimer <fweimer@...hat.com>
To:	Yury Norov <ynorov@...iumnetworks.com>,
	Andreas Schwab <schwab@...e.de>
Cc:	Andrew Pinski <pinskia@...il.com>,
	Szabolcs Nagy <szabolcs.nagy@....com>,
	GNU C Library <libc-alpha@...rceware.org>,
	LKML <linux-kernel@...r.kernel.org>, nd <nd@....com>,
	Arnd Bergmann <arnd@...db.de>,
	Catalin Marinas <catalin.marinas@....com>,
	Marcus Shawcroft <marcus.shawcroft@....com>, philb@....org,
	David Miller <davem@...emloft.net>,
	Maxim Kuvyrkov <maxim.kuvyrkov@...aro.org>,
	"Joseph S. Myers" <joseph@...esourcery.com>,
	Andrew Pinski <apinski@...ium.com>
Subject: Re: [PATCH 01/27] [AARCH64] Fix utmp struct for compatibility
 reasons.

On 06/23/2016 09:36 AM, Yury Norov wrote:
> On Thu, Jun 23, 2016 at 09:32:46AM +0200, Andreas Schwab wrote:
>> Andrew Pinski <pinskia@...il.com> writes:
>>
>>> So if you want aarch64 to be compatible with aarch32, you need to
>>> define __WORDSIZE_TIME64_COMPAT32.  If we don't want aarch64 and
>>> aarch32 to be compatible at all, then we can drop this patch or if you
>>> don't want LP64 and ILP32 to be compatible either.
>>
>> Or go the other way like s390 and use the LP64 layout for ILP32.
>>
>> Andreas.
>>
>> --
>> Andreas Schwab, SUSE Labs, schwab@...e.de
>> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
>> "And now for something completely different."
>
> It was an agreement that we don't fix Y2038 issues specifically, as
> there will be general fix.

As far as I understand this, it is not a Y2038 issue because it affects 
current systems using current dates.  It's a separate bug IMHO.

Florian