From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id B05503858D28 for ; Mon, 19 Jun 2023 12:59:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B05503858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687179539; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NL0p0g6u8Sc5YicHG0GZygZt0Q8cB4xiVnapZrWllrQ=; b=Q1ebNzjxQxb5LQ6XG9iFYZzi1dunS009hPTbUi2UFgqgPwIfXNRGXf9D6HtApfJNc0XKad FgZDUWij8Lg+sMbbkx9NPsJ1lj6C3Oe/ZEGncMqYjgNPoglrjU2r55RcZuvVqV3tMa3Tp/ YBc1Z51HuttOgFmtVlzu/Ol7gnhPwR4= Received: from mail-vk1-f199.google.com (mail-vk1-f199.google.com [209.85.221.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-61-IA-ZrNJDNT2FAwCQDfi30g-1; Mon, 19 Jun 2023 08:58:58 -0400 X-MC-Unique: IA-ZrNJDNT2FAwCQDfi30g-1 Received: by mail-vk1-f199.google.com with SMTP id 71dfb90a1353d-4716b4293b8so308291e0c.1 for ; Mon, 19 Jun 2023 05:58:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687179537; x=1689771537; h=content-transfer-encoding:in-reply-to:organization:from:references :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=NL0p0g6u8Sc5YicHG0GZygZt0Q8cB4xiVnapZrWllrQ=; b=PDBmvr2q4CP7mqU1S84ern5kK6y0F2TH9dk1wftWQpAGSZDPVt8XtXxBvcopbSvs7C RJw5D8cCeQW5bycfDR3EAIzCG0H67/Xml0gYnNBkusKTj+8W74tS5lTadtLQvFxnmiXz 2jASBhbGRUiW9fUg4xDUOLqkiGXXcjC24Qr3YrSJdKsvvXZYF7jX0dY4OCqUMWPBXB1U mIBHBRGmyTuA1WMEXB7JcwTveNEMm0+7i3GPCO4XD7A4JBwXOAIHUnZ/mF+WrNJrC3VF H+DECwzerUnXghiiCCmNnqv3/NigsWqxMZ2Lx9RJggGN6utaqrMYiyDBYOO+KRJehpVP 2dAA== X-Gm-Message-State: AC+VfDwAX0UegeO+EVHpy1vwnXAA2t5kRdDP3KTgolse4XM6ZGV340FA 7eBmaBUJ+TW5YRRPcm6bM2s82eTVw/qeQ7WRea3X74JdaYD3YjeoR/5S6VMTk1U1OoTqEaoHjok eJdpSWlD6oXD8P9dA/gyzHmrWxU9P X-Received: by 2002:a1f:3d94:0:b0:464:c5aa:3338 with SMTP id k142-20020a1f3d94000000b00464c5aa3338mr1432546vka.15.1687179537493; Mon, 19 Jun 2023 05:58:57 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6hCisVCYqFzi2x3fCccNujJ7cokDME/a4IuOce7BRHKkIUObx8lpOj+pUlbGR+BCF8DIbcKw== X-Received: by 2002:a1f:3d94:0:b0:464:c5aa:3338 with SMTP id k142-20020a1f3d94000000b00464c5aa3338mr1432542vka.15.1687179537170; Mon, 19 Jun 2023 05:58:57 -0700 (PDT) Received: from [192.168.0.241] ([198.48.244.52]) by smtp.gmail.com with ESMTPSA id k190-20020a0dc8c7000000b0056d51c39c1fsm4105301ywd.23.2023.06.19.05.58.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jun 2023 05:58:56 -0700 (PDT) Message-ID: <1249c048-c72d-0bf1-f0e0-2e619cfe5372@redhat.com> Date: Mon, 19 Jun 2023 08:58:55 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v3 0/5] fcntl fortification To: Sergey Bugaev , libc-alpha@sourceware.org References: <20230617222218.642125-1-bugaevc@gmail.com> From: Carlos O'Donell Organization: Red Hat In-Reply-To: <20230617222218.642125-1-bugaevc@gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_ASCII_DIVIDERS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 6/17/23 18:22, Sergey Bugaev via Libc-alpha wrote: > Hello, > > this is v3 of the fcntl fortification work. v1 was at [0], v2 at [1]. > > [0]: https://sourceware.org/pipermail/libc-alpha/2023-May/148332.html > [1]: https://sourceware.org/pipermail/libc-alpha/2023-May/148569.html Pre-commit CI regression caused by this series on both aarch64 and aarch32. https://patchwork.sourceware.org/project/glibc/patch/20230617222218.642125-6-bugaevc@gmail.com/ # Running glibc:io ... # FAIL: io/check-installed-headers-c # FAIL: io/check-installed-headers-cxx # # Running glibc:misc ... # FAIL: misc/check-installed-headers-c # FAIL: misc/check-installed-headers-cxx # # Running glibc:rt ... # FAIL: rt/check-installed-headers-c # FAIL: rt/check-installed-headers-cxx > Changes since v2: > > - This is now in its own separate header, bits/fcntl3.h > (bits/fcntl2.h is used by the open fortification) > > - Clang is now supported in addition to GCC! > - Clang does not support nor need the "-Wsystem-headers" pragma > - Clang does support error/warning attributes since recently > - There seems to be a bug in Clang which prevents the type mismatch > warning from actually firing. Specifically, it appears that Clang > gets confused about C functions names vs symbol names when it comes > to attribute ((warning)), and does not emit the warning if the > function declared with __warnattr has a symbol name matching that of > another function that has not been declared with __warnattr. > > While this could be worked around in glibc (such as by adding > __fcntl_warn as a real wrapper function when built with Clang), I > think this just needs to be fixed in Clang. Any LLVM developers > here? :D > > - Changed hide_constant utility to use an empty inline asm statement > instead of volatile and noinline, as per the discussion. I did not > make this into a general-purpose glibc-wide utility because I don't > know what a fitting name and place (header) for it would be. If you'd > like to see it glibc-wide, please suggest me where to put it and how > to name it! > > - Fixed the C++ template linkage thing > > - Addressed misc review comments > > - Looked into applying __builtin_constant_p to the result of the cmd > check and not the cmd value itself, as suggested by Florian. > > Unfortunately this does not work at all :( __builtin_constant_p starts > returning 0 given anything remotely complex like even a trivial inline > function call (so technically hide_constant would still work if it was > just 'return value;'), even if the function is (later?) fully inlined > and const-folded. > > *Maybe* this could be made to work if I used an obscene amount of > macros instead of inline functions (to handle all the various commands > being conditionally defined), but I don't want to go there. > > So since this didn't work out, I left the runtime __fcntl_2 function, > but split it into a separate patch, so you can apply it or drop it > depending on what you prefer in the end. > > Clang / C++ demo: > > ------------------------------------------------------------------ > $ clang++ test-fcntl.cpp -D _FORTIFY_SOURCE=2 -O2 > In file included from test-fcntl.cpp:1: > In file included from /usr/include/fcntl.h:348: > /usr/include/bits/fcntl3.h:394:5: error: call to '__fcntl_missing_arg' declared with 'error' attribute: fcntl with with this command needs 3 arguments > __fcntl_missing_arg (); > ^ > 1 error generated. > ------------------------------------------------------------------ > > Sergey > -- Cheers, Carlos.