| 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
| ||
|
Date: Fri, 25 Apr 2014 21:19:46 +0800 From: Chung-Lin Tang <chunglin_tang@...tor.com> To: "Pinski, Andrew" <Andrew.Pinski@...iumnetworks.com>, Chung-Lin Tang <cltang@...esourcery.com> CC: Catalin Marinas <catalin.marinas@....com>, Ley Foon Tan <lftan@...era.com>, Arnd Bergmann <arnd@...db.de>, "H. Peter Anvin" <hpa@...or.com>, Linux-Arch <linux-arch@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>, Andrew Pinski <apinski@...ium.com> Subject: Re: [PATCH 00/28] nios2 Linux kernel port On 14/4/25 下午4:37, Pinski, Andrew wrote: > > >> On Apr 24, 2014, at 11:06 PM, "Chung-Lin Tang" <cltang@...esourcery.com> wrote: >> >>> On 2014/4/25 02:42 AM, Pinski, Andrew wrote: >>> >>> >>>>> On Apr 24, 2014, at 11:37 AM, "Chung-Lin Tang" <cltang@...esourcery.com> wrote: >>>>> >>>>>> On 2014/4/24 11:28 PM, Catalin Marinas wrote: >>>>>>> On Thu, Apr 24, 2014 at 09:55:25AM +0100, Chung-Lin Tang wrote: >>>>>>>> On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: >>>>>>>> On 2014/4/24 上午 02:15, Pinski, Andrew wrote: >>>>>>>> >>>>>>>>>> On Apr 23, 2014, at 10:59 AM, "Chung-Lin Tang" <cltang@...esourcery.com> wrote: >>>>>>>>>> >>>>>>>>>>>> On 2014/4/22 07:20 PM, Ley Foon Tan wrote: >>>>>>>>>>>> On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann <arnd@...db.de> wrote: >>>>>>>>>>>>>>>> On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: >>>>>>>>>>>>>>>>>>>> Hi Arnd and Peter Anvin, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Other than 64-bit time_t, clock_t and suseconds_t, can you confirm >>>>>>>>>>>>>>>>>>>> that we don't need to have 64 bit off_t? See detail in link below. >>>>>>>>>>>>>>>>>>>> I can submit the patches for 64-bit time changes >>>>>>>>>>>>>>>>>>>> (include/asm-generic/posix_types.h and other archs) if everyone is >>>>>>>>>>>>>>>>>>>> agreed on this. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>> Okay, will doing that. >>>>>>>>>> >>>>>>>>>> I believe that arm64 ILP32 will also be affected. What is the status of >>>>>>>>>> this configuration? Has the glibc/kernel ABI been finalized? >>>>>>>> Not yet. I am still working out the signal handling part. But we >>>>>>>> already agreed on 64bit time_t, clock_t, and suseconds_t. And we >>>>>>>> agreed to a 64bit offset_t too. >>>>>>>> >>>>>>>> On a related note suseconds in the timespec in posix is defined to >>>>>>>> be long. So it would nice if the kernel ignores the upper 32bits so >>>>>>>> we (glibc developers) can fix this for new targets including x32 >>>>>>>> and arm64/ilp32. >>>>>>> >>>>>>> Hmm, but that means for purely 32-bit architectures like nios2, which >>>>>>> unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit >>>>>>> type in the kernel is simply wasted. >>>>>> >>>>>> The more I think of this, the more I feel that suseconds_t should jsut >>>>>> be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit >>>>>> kernel should be using compat_* code paths, something like a >>>>>> COMPAT_USE_32BIT_SUSECONDS case. >>>>> >>>>> ILP32 mode should use LP64 syscalls as much as possible and that's the >>>>> aim with arm64 as well (of course, we still have a few that wouldn't be >>>>> possible and we route them via compat). >>>>> >>>>> But here if time_t is 64-bit while susecconds_t is 32-bit, the compat >>>>> code wouldn't help. >>>> >>>> Why not? You can define the arm64 'struct compat_timeval' with >>>> suseconds_t as s32, and add the 32<-->64 case in the >>>> compat_get/put_timeval path, triggered when the process is ILP32 (test >>>> wrapped in the above hypothetical COMPAT_USE_32BIT_SUSECONDS macro). >>>> Similar to how x32 does COMPAT_USE_64BIT_TIME. >>> >>> We would three timeval then. One for aarch32, one for lp64 and one for ilp32. We really don't want three. Two is already one too many in my mind after developing the ilp32 syscall abi. >>> >>> Thanks, >>> Andrew >> >> Okay I now see you're already doing that for 32-bit ARM. >> >> Still, you would probably just need to have an arm64-ILP32 specific case >> to be careful about the last padding word upon kernel entry/exit. >> (accommodating the difference in sizeof(long)) Penalizing all >> architectures does not seem like the best solution. > > Considering the alignment of long long would be 64bits, the struct does not change sizes if suseconds_t is 32bits or 64bits. > >> >> Having suseconds_t as a strictly 64-bit C type in the kernel, while >> defined as <= long in user-space may cause other problems. >> >> I'll try to explain a probable situation for Nios II. I'm not sure about >> other soft-cores, but nios2 is sort of uncommon in that the maximum >> alignment is 4-bytes (32-bits), even for doubles/long-longs. > > Yes does that include even if users of aligned? If so that seems broken. Also yes nios ii is unstandard when it comes to alignment here. You mean using '__attribute__((aligned(8)))'? Sure of course that enlarges the alignment as expected, but sprinkling that over glibc, or getting it into the main glibc bits/time.h header is probably not going to happen... Thanks, Chung-Lin >> >> So if time_t is 64-bits (which makes sense), then struct timeval, which >> is time_t+suseconds_t in userspace is 12-bytes/aligned-4 (unlike many >> archs where a 64-bit time_t will expand the size to 16-bytes, due to >> align-8) > > Unlike most other targets where the struct would 16bits no matter what. > > Thanks, > Andrew > > >> >> If the kernel suseconds_t is forced to be 64-bits, then nios2 will have >> a 16-byte kernel timeval vs. 12-byte userspace timeval situation. Just >> this will require us to do something using compat_*, or weird hacks in >> glibc, which is unfair. Nios II has no "other-mode". We are just >> strictly ILP32, everywhere. >> >> Of course, we can probably still at the end just use a Nios II specific >> posix_types.h header to override things, but I'm just stating this as a >> matter of which are the most reasonable default settings in the generic >> headers. Making pure ILP32 archs diverge from POSIX standards by default >> does not seem to be right. >> >> Thanks, >> Chung-Lin >> -- 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/
Powered by blists - more mailing lists