From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) by sourceware.org (Postfix) with ESMTPS id 90D03386F022 for ; Thu, 5 Nov 2020 16:23:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 90D03386F022 Received: by mail-oi1-x244.google.com with SMTP id t143so2229308oif.10 for ; Thu, 05 Nov 2020 08:23:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Y6WFoG2I0z0rKiucd2piO5pU9bYAB1I9grsshlEqYsQ=; b=dnrFoidWYiNoLX4SRF4ByJExnLdTmRSmlmMFX0O/XZdNspZZd66lo+kBRQ/xF2Yglv RVauItie+Svm7oK5M3+NtwzvJK0/fx92pH0hYdDKu+6EwGXOmrxH5VfiSwPxIHyniFsN ObOBwXr7Qph2bNlKrAYgVMcdMvivtHnzY9CXzeo3O/jSbdfMTSVU22CGRbjh0UsAIjqN xXFgrv4HtRdJoncwINscRbahk2Ug0rifeEwfDDTWtxu9Pf/GJJ5BKM7XCbPdSPeCY0wU nZtTXynnJY8XXv6pQzhgGaBFCL9TzzxERwj0hkC3q9+m8AADJFJNiPTnFO3yEvQN2Dz+ wqSA== X-Gm-Message-State: AOAM53369zJxC3KyTO66LwLnYh144Zh/JkPunNopZRmVRzJ3CZ17q7n0 3XlIdUIUcDX+vlV/OJ7f6/mkskbPY3Y= X-Google-Smtp-Source: ABdhPJxc8UlxQsXp+ss061tih9Ld01KQwKpahJRHhFOyPRU/2uIdcub8/hZ7cL2Xzq/rrLJ9L6/NAg== X-Received: by 2002:aca:b40a:: with SMTP id d10mr115008oif.156.1604593393613; Thu, 05 Nov 2020 08:23:13 -0800 (PST) Received: from [192.168.0.41] (174-16-106-146.hlrn.qwest.net. [174.16.106.146]) by smtp.gmail.com with ESMTPSA id c64sm457983oia.49.2020.11.05.08.23.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Nov 2020 08:23:12 -0800 (PST) Subject: Re: [PATCH] cache compute_objsize results in strlen/sprintf (PR 97373) To: Jakub Jelinek Cc: Richard Biener , gcc-patches References: <34f3587a-7c93-804e-639a-da37a1ef50ab@gmail.com> <20201105152951.GD3788@tucnak> From: Martin Sebor Message-ID: Date: Thu, 5 Nov 2020 09:23:11 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20201105152951.GD3788@tucnak> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Thu, 05 Nov 2020 16:23:16 -0000 On 11/5/20 8:29 AM, Jakub Jelinek wrote: > On Thu, Nov 05, 2020 at 08:20:20AM -0700, Martin Sebor via Gcc-patches wrote: >> compute_objsize() and the objsz pass are completely independent. >> The pass is also quite limited in that it doesn't make use of >> ranges. That limitation was also the main reason for introducing >> the compute_objsize() function. >> >> I'd love to see the objsize pass and compute_objsize() integrated >> and exposed under an interface similar to range_query, with >> the information available anywhere, and on demand. I might tackle > > As I said multiple times, that would be a serious security hazard. > _FORTIFY_SOURCE protects against some UBs in the programs, and ranges > are computed on the assumption that UB doesn't happen in the program, > so relying on the ranges etc. in there is highly undesirable. As I think has been pointed out as many times in response, failing to handle ranges in _FORTIFY_SOURCE, or any expressions that can't be evaluated at compile time for that matter, is the security gap. It means that the vast majority of allocated objects (by malloc, alloca, or VLAs) are unprotected, as are accesses into fixed-size objects involving nonconstant offsets. It's only thanks to compute_objsize() GCC diagnoses (but doesn't prevent) a small subset of buffer overflows involving such accesses but only those where the lower bound of the access exceeds the upper bound of the size. It's powerless against those where the overflow is due to the size of the access exceeding just the lower bound of the object size but not the upper bound. This serious _FORTIFY_SOURCE shortcoming was recognized by the Clang developers and rectified by introducing __builtin_dynamic_object_size. Martin