From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, PDS_RDNS_DYNAMIC_FP,RCVD_IN_DNSWL_MED,RDNS_DYNAMIC,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 116331F910 for ; Tue, 8 Nov 2022 11:56:15 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="t82pNadw"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D62ED3858C56 for ; Tue, 8 Nov 2022 11:56:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D62ED3858C56 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667908573; bh=5ofOlUkWD2r4ZSSs7kZhp0C47fNaUTybYFHz8RXBITk=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=t82pNadw9YQwZjo2kRZ8T3DYlq43STpDF/02iUi/6g2MVFsaZVjNK8HY4HvadFVOp 960IWqP+n+ruN9DqLdwmGkWWM1GlVZS1YwgHMmk2UocgUaStJt4JG5E9/U14UFhqEZ kAd41CQYckkjrR+0fmQ+Qnzut+6hi0sIgTivVr8o= Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) by sourceware.org (Postfix) with ESMTPS id DCC2D3858D32 for ; Tue, 8 Nov 2022 11:55:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DCC2D3858D32 Received: by mail-ot1-x32f.google.com with SMTP id l42-20020a9d1b2d000000b0066c6366fbc3so8216296otl.3 for ; Tue, 08 Nov 2022 03:55:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5ofOlUkWD2r4ZSSs7kZhp0C47fNaUTybYFHz8RXBITk=; b=w7azq7G2VdboZnF4rYByYCa59HoDfycjMHrtM07zuAVsAfvKqucG6YUBmf8SCZa7mk Q6eFq7W3XEreI0z3gpu0IWd+arXQ4UbAj0i2GeXVJQvqb1T2aWe2jQZVMfpsxAVcxQAs rYTzGhApiSMIuAEJ++kWrnCPfWOewvEOBIUC9qy6Qe8ma5Z//dQg6wAhVMcivtuLstov iDCk8hDlgOHAcfp45xqmxXrY5bQATmSEoQ53+69kle6r5LA5QU5L7yjkCXBqXsI+Gws9 iMgS+Rm65lbNAbrCiQ5blCB7loVsnexgBHLamcMKMZcSwawWMwCh61kZXLNHV0FLiKg1 rQdw== X-Gm-Message-State: ACrzQf14fFQKQHugx/NM4M2qOTK5sZIofNpDF+TMWCWoqMNRfXHz4737 EArx132+ZpBtsEGPFVPSWk0eFw== X-Google-Smtp-Source: AMsMyM5g9+OrEP2OwgSwlOjGHjYqjw226vks36qm6FTi24upxUJAFrBRf6qRM1OvDLFH790XVobalw== X-Received: by 2002:a9d:7995:0:b0:66c:5375:4001 with SMTP id h21-20020a9d7995000000b0066c53754001mr22544873otm.351.1667908552973; Tue, 08 Nov 2022 03:55:52 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c0:a9f4:fc60:ae8f:c4b6:cf0a? ([2804:1b3:a7c0:a9f4:fc60:ae8f:c4b6:cf0a]) by smtp.gmail.com with ESMTPSA id eq42-20020a056870a92a00b0013626c1a5f6sm4449874oab.10.2022.11.08.03.55.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Nov 2022 03:55:52 -0800 (PST) Message-ID: <2f0868e0-e242-a1b0-a698-dc5afea4ad30@linaro.org> Date: Tue, 8 Nov 2022 08:55:49 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH v3] Define in_int32_t_range to check if the 64 bit time_t syscall should be used Content-Language: en-US To: Florian Weimer , Arnd Bergmann Cc: YunQiang Su , Xi Ruoyao , aurelien@aurel32.net, Jiaxun Yang , "Maciej W. Rozycki" , syq@debian.org References: <20221104013913.1543593-1-yunqiang.su@cipunited.com> <20221108044945.2173509-1-yunqiang.su@cipunited.com> <652b5ea3-2305-4a1e-b1b5-de81864a844c@app.fastmail.com> <87cz9xk84v.fsf@oldenburg.str.redhat.com> <80f469a6-f432-419d-9cdc-91f2366639d3@app.fastmail.com> <87sfitisjq.fsf@oldenburg.str.redhat.com> Organization: Linaro In-Reply-To: <87sfitisjq.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Adhemerval Zanella Netto via Libc-alpha Reply-To: Adhemerval Zanella Netto Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 08/11/22 08:39, Florian Weimer wrote: > * Arnd Bergmann: > >> On Tue, Nov 8, 2022, at 12:17, Florian Weimer wrote: >>> * Arnd Bergmann: >>>> On Tue, Nov 8, 2022, at 05:49, YunQiang Su wrote: >>>>> Currently glibc uses in_time_t_range to detects time_t overflow, >>>>> and if it occurs fallbacks to 64 bit syscall version. >>>>> >>>>> The function name is confusing because internally time_t might be >>>>> either 32 bits or 64 bits (depending on __TIMESIZE). >>>>> >>>>> This patch refactors the in_time_t_range by replacing it with >>>>> in_int32_t_range for the case to check if the 64 bit time_t syscall >>>>> should be used. >>>>> >>>>> The in_time_t range is used to detect overflow of the >>>>> syscall return value. >>>> >>>> It looks like the fallback logic has another flaw, I don't >>>> see how this works on kernels with COMPAT_32BIT_TIME disabled, >>>> as these only have the time64 syscalls available. >>> >>> Isn't that an invalid kernel configuration? >> >> No, this is what we will use anyway after 2038 (possibly >> earlier), so the option is useful to ensure that all userspace >> has been converted away from the time32 interfaces. > > What happened to not breaking userspace? > > Those with 32-bit applications will want to run their legacy stuff in a > time-shifted environment, so these system calls must remain supported > outside specialized applications. > > Thanks, > Florian I agree and the time64 support was added based on this assumption. I understand that this simplifies the code and kernel attack surface, but it a userspace breakage anyhow.