linux-kernel - Re: [Ksummit-discuss] 2038 Kernel Summit Discussion Fodder

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: <53EAE3AD.9040203@linaro.org>
Date:	Tue, 12 Aug 2014 21:03:57 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Ben Hutchings <ben@...adent.org.uk>
CC:	ksummit-discuss@...ts.linuxfoundation.org,
	"Joseph S. Myers" <joseph@...esourcery.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-discuss] 2038 Kernel Summit Discussion Fodder

On 08/12/2014 07:06 PM, Ben Hutchings wrote:
> On Tue, 2014-08-12 at 17:01 -0700, John Stultz wrote:
> [...]
>> The downsides here are many. The distros will probably hate this idea,
> I certainly hate the idea of adding another 32-bit port to Debian.
> I think that it's OK for traditional distros to say 'just upgrade to
> 64bit' while you solve the problem for 32-bit embedded systems where
> there's probably little demand for supporting multiple ABIs at once.

So I don't necessarily disagree, but if the rule really is "we don't
break userspace" we will need a solution that at least allows for
multiple ABIs from the kernel side, and we can then let distros chose if
they want to handle both or not.  Even in the embedded world, as usage
grows with things like Android, we're starting to see more strict needs
for ABI/platform stability (see the ARMv8 SWP discussion from last
month).  Fancy android based dashboard infotainment systems probably
want to both be 2038 safe and run today's unsafe applications (hoping
that they get upgraded eventually).


>
>>  as it requires rebuilding the world, and maintaining another legacy
>> architecture support. I’m also not completely sure how robust
>> multi-arch packaging is in the face of having to handle 3-4
>> architectures on one system.
> dpkg multiarch covers this just fine, while I believe RPM is limited to
> biarch.
>
>> On the kernel side, it also adds more complexity, where we have to add
>> even more complex compat support for 64bit systems to handle all the
>> various 32bit applications possible.
> [...]
>
> Didn't we need to do this already to support x32?  Have compat ioctls
> involving time been botched?
I'm not sure exactly what you mean here, but yea, its very much like
supporting something like x32, but its one more to the list and has to
be supported on both 32 and 64 architectures.

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/