From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) by sourceware.org (Postfix) with ESMTPS id 5743C3858403 for ; Sun, 14 Nov 2021 13:54:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5743C3858403 Received: by mail-io1-xd35.google.com with SMTP id f9so17560132ioo.11 for ; Sun, 14 Nov 2021 05:54:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SR6bYG0PctoF/TODgHIMcCeee0F0J3mU/Lw/SM4/hTQ=; b=kr3Ot5KgG9DORdHT0uSeA936v6qiGdTeGKqKhgE3hUPSV7qtYI7RF4dskn1M2gXwq3 w2Eznhk9RvjWx3tMrjCCX92GzqavXDwUaL5BfHESat8/9w24066qVIwAaBxQHxjxQ5Zu VRLklRLH7kjYy69h6AHdz9nOgUULTfBVmSz6q2GL/TdZVVNl4B6JELNTbfE3oO0+cQGu D7Q5tyHd6bObomQ5dzggxFgN4YiZwKiFtuqiN64EaChT6ltet0M6peUlOt6lKVVnDrKi Er4CoVBxVusWMyZycg8hp/VB9VtlsuUelnd3Yq9ZHLtl7bZRBvUCy6gmE/qS2Ywbedi7 Iybg== X-Gm-Message-State: AOAM531I2yCFiesASOiXatkikqNhQyFEWCEGG+XdGz71VOtFCVIU1tlb mM8RdObAMNz1LVQDit9lY6C2c1Ew7NJDcE/VF5Q= X-Google-Smtp-Source: ABdhPJygJVtpANnWJMpK+3C4dIlWCvTMdK27IOXFykwVzPcuzN1gr5Uq83bs3qZoyf/2ZsLYGD+xBlVOeow5LL6VAA4= X-Received: by 2002:a6b:b7c8:: with SMTP id h191mr19400085iof.155.1636898054873; Sun, 14 Nov 2021 05:54:14 -0800 (PST) MIME-Version: 1.0 References: <20211113203732.2098220-1-dmalcolm@redhat.com> In-Reply-To: <20211113203732.2098220-1-dmalcolm@redhat.com> From: Miguel Ojeda Date: Sun, 14 Nov 2021 14:54:03 +0100 Message-ID: Subject: Re: [PATCH 0/6] RFC: adding support to GCC for detecting trust boundaries To: David Malcolm Cc: gcc-patches@gcc.gnu.org, linux-toolchains@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.7 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 autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2021 13:54:18 -0000 On Sat, Nov 13, 2021 at 9:37 PM David Malcolm wrote: > > #define __user __attribute__((untrusted)) > > where my patched GCC treats > T * > vs > T __attribute__((untrusted)) * > as being different types and thus the C frontend can complain (even without > -fanalyzer) about e.g.: This one sounds similar to the `Untrusted` wrapper I suggested for the Rust side -- we would have a method to "extract and trust" the value (instead of a cast). > Patch 2 in the kit adds: > __attribute__((returns_zero_on_success)) > and > __attribute__((returns_nonzero_on_success)) > as hints to the analyzer that it's worth bifurcating the analysis of > such functions (to explore failure vs success, and thus to better > explore error-handling paths). It's also a hint to the human reader of > the source code. These two sound quite nice to have for most C projects. Would it be useful to generalize to different values than 0/non-0? e.g. `returns_on_success(0)` and `returns_on_failure(0)`. Cheers, Miguel