From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id D18E73858D35 for ; Tue, 23 May 2023 20:24:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D18E73858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oi1-x236.google.com with SMTP id 5614622812f47-38e3228d120so148415b6e.3 for ; Tue, 23 May 2023 13:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684873486; x=1687465486; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=96Dff6QfPtEBkfeQHceL+l98rqxyqPEYvbQugjF6IDc=; b=i/U+ZThnZfKIFbPdDKgjb6m/ROqvNIhzyn6cl6gU8UicnbdAkwsQDf8xd6o1Ci5xKy CWXy5UQHDL4coMdPvw4J7JsYY6mtMlQ6iM9u0d6xQZz5/2M8xF0p3jO9qQ9xJ5gvDVp0 XxYfIFAtZbRi0+ftMKACqsZT0/jNBCKflSeYHkG6/PTPfjE9btu3cgqhn1GL6ZgLMZvi YwEdWu++OhdFKG9h+fUKiducqtMIJ3k97Swr5HVnR8ZOlFvQQXExokwqcCQMV9y7qrNw pwQXkBez9wuQddSZ+izP7C0zomd7FmC7sb0MYSa7FbjWsLqaBCpgDSmu0BwZT9nWElFY jBQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684873486; x=1687465486; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=96Dff6QfPtEBkfeQHceL+l98rqxyqPEYvbQugjF6IDc=; b=EMYjj6ODDMSnGs5NGImf/8Ogqo6Q5DFiCn39C1P5HUTqrsKRQfLQGRyzTEJuzhAQVs 1xcq8gbjYK76yowm3ncgtfM6ttBEzZfQWliV7Q2Ef4SthvoJmX85JQhEIHPKrMDabGVR LG99AII9CMTtRf4nazXG6OrpFg/DL4drEm6lbHcRxu7SjmpWI0Xow6wzhuZ+GTQ+SKEu fEuChhvJZ5B+IH/18LASLMNKBOrtoPysHATq8Qo+sCk8vHUB1lpRCkAFk2cQaLugdvtw Ra3YBIKj5poKf1d7e9DoaIkaKnrPvUE9E3M6xaYXGjswabcS3pv01ZrgBl9Qou55v/ic 4LCA== X-Gm-Message-State: AC+VfDz2vuWZdNJQHh9bsLar7Fln+DH4DiOe0hyGmdjET2Hq9u8zPUjh xtS3Y//YLTl7IvB3z45UCKHACoOZCrYadYqai1MaE1gUhfM= X-Google-Smtp-Source: ACHHUZ7mYQOXWpE8r26UUncJvgi5pj4WvzfUmy57BUJTkG7w1q/0JZhFAtVDocKYuefnCxscfeOu9+ffT+KZ8aZug4M= X-Received: by 2002:aca:2407:0:b0:398:1047:9e3a with SMTP id n7-20020aca2407000000b0039810479e3amr3883533oic.25.1684873485893; Tue, 23 May 2023 13:24:45 -0700 (PDT) MIME-Version: 1.0 References: <20230519213059.3812385-1-bugaevc@gmail.com> <20230519213059.3812385-2-bugaevc@gmail.com> <0b512019-09ab-9f25-57d6-cf6fd19be8f3@linaro.org> In-Reply-To: From: Sergey Bugaev Date: Tue, 23 May 2023 23:24:35 +0300 Message-ID: Subject: Re: [RFC PATCH 1/1] io: Add FORTIFY_SOURCE check for fcntl arguments To: Adhemerval Zanella Netto Cc: libc-alpha@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, May 23, 2023 at 10:57=E2=80=AFPM Adhemerval Zanella Netto wrote: > >>> + if (__fcntl_cmd_needs_arg (__cmd) && __va_arg_pack_len () < 1) > >> > >> No implicit check for function that do not return bool: > >> > >> if (__fcntl_cmd_needs_arg (__cmd) =3D=3D 1 ...) > > > > Why? Is it just a code style thing? > > Yes, it is from the glibc code style (check 'Boolean Coercions' [1]). > > [1] https://sourceware.org/glibc/wiki/Style_and_Conventions [I don't mean to argue, and surely you know better, and not that I care about this], but I read that as saying that implicit integer-to-bool conversions are frowned upon, not ints used as bools (because C used to lack a bool type). In other words: if you have an integer variable that can have many different values and you want to check it against 0, you're supposed to write out the !=3D 0 explicitly. But if what you have is essentially a boolean, but you use int/1/0 instead of bool/true/false, then just checking if (my_bool) should be fine, and doing !=3D 0 would be awkward -- no? I've surely seen glibc code use if (my_bool) without the !=3D 0 when my_bool is declared as an int. __libc_enable_secure is one example. > > The idea here was that the 2-argument version of fcntl clearly does > > not deal with time, either 32- or 64-bit... > > And that's why we don't have a __fcntl_time64 implementation. But Floria= n > has asked to add one anyway if we even eventually need to handle some tim= e > related structure. > > I think we can skip this for now, but at least add a comment stating that > if we even need to handle time related field with fcntl we will a new > redirection. Hm, either I'm failing to understand what you're saying (which is possible: it is late at night), or maybe I didn't make my point clear: if what you're concerned is what the _2 functions end up calling (__fcntl_time64 vs __libc_fcntl64), then it does not matter because they're only used for 2-argument variant of fcntl, which can not possibly deal with any time-related structures (nor any structures), exactly because there's no third argument where a structure could be passed. The 2-arg variant is basically for simple getters that return an int. But if something is off (wrt time64 vs not) in the main fortification / redirection code, then I surely need to fix that -- then please clarify what specific configuration / case you're talking about. Sergey