From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by sourceware.org (Postfix) with ESMTPS id C1F9F3858C5F for ; Fri, 26 May 2023 20:40:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C1F9F3858C5F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=chromium.org Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-64d44b198baso979992b3a.0 for ; Fri, 26 May 2023 13:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1685133646; x=1687725646; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ng0KAa7wHlYRRRyLtnxO1AkWPtrWqvjlf6P72XZd5Pc=; b=AjtTtHIzCUxN3QSZ2UivqwtCF5L6bqk0qSoBJoyZKTx0Z5HuBx7rZhcoI73Bl3L9Zs lW+akZf2tm13PxJ1GCOfCfvFMbLRdo/dVSEALV7HfYaYxSmALTbM+mAfODyt54qKKH94 C1FniQ1KyKah6jQuhIOnppndil/HfpCmfcqx8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685133646; x=1687725646; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ng0KAa7wHlYRRRyLtnxO1AkWPtrWqvjlf6P72XZd5Pc=; b=cR3ZN7lvFsqMXCcpQMvLWKdCH8goR74ZpizYm9+/q5VnmEyoXbCsU5A17buNmVNidI RS0wxcEkDztrfF1FCIn1xdO7hYbNlYcelP15CGRAb5hzDDZsuj0MfnBzP5vbp7CF1+Hj aiAIFWClWKmRnStcnhZo/Jg0RZGYTVGOxjwTaEvtrbctOIjE2UioOPr22Ze404y1dphS Z3iXf5mZlDi1yRiNT0bOCo6ey+SnCNDNoMeZYHG/Fk43sqS6xpW1ES8ttUZ2BaP1w7MQ VR/eAYAj8Kl5shC81zwNASywzysfLHjMK1LNPADVBOQaWox4TLfaHSIHh7TEgwGaCM1G fgYA== X-Gm-Message-State: AC+VfDzqSeQ6VBR3LZuVgaPiaqWHiCgENCDSEJnOFuX12eiyVHimXpex rULgEPFMBEygzm87Z2NK2o2m5w== X-Google-Smtp-Source: ACHHUZ7jZHt2y2tpQRMBXvEc3WLNQQm8cb7g7PNL7QSACacIM3Lszxo4r94W1zKR0caGj9kUKs7ArA== X-Received: by 2002:a05:6a00:1d96:b0:64e:86cd:7f3 with SMTP id z22-20020a056a001d9600b0064e86cd07f3mr158174pfw.13.1685133645838; Fri, 26 May 2023 13:40:45 -0700 (PDT) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id n2-20020a62e502000000b0064ccfb73cb8sm3074955pff.46.2023.05.26.13.40.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 May 2023 13:40:45 -0700 (PDT) Date: Fri, 26 May 2023 13:40:44 -0700 From: Kees Cook To: Qing Zhao Cc: joseph@codesourcery.com, richard.guenther@gmail.com, jakub@redhat.com, gcc-patches@gcc.gnu.org, siddhesh@gotplt.org, uecker@tugraz.at, isanbard@gmail.com Subject: Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896) Message-ID: <202305261218.2420AB8E0@keescook> References: <20230525161450.3704901-1-qing.zhao@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230525161450.3704901-1-qing.zhao@oracle.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 Thu, May 25, 2023 at 04:14:47PM +0000, Qing Zhao wrote: > GCC will pass the number of elements info from the attached attribute to both > __builtin_dynamic_object_size and bounds sanitizer to check the out-of-bounds > or dynamic object size issues during runtime for flexible array members. > > This new feature will provide nice protection to flexible array members (which > currently are completely ignored by both __builtin_dynamic_object_size and > bounds sanitizers). Testing went pretty well, though I think I found some bdos issues: - some things that bdos can't know the size of, and correctly returned SIZE_MAX in the past, now thinks are 0-sized. - while bdos correctly knows the size of an element_count-annotated flexible array, it doesn't know the size of the containing object (i.e. it returns SIZE_MAX). Also, I think I found a precedence issue: - if both __alloc_size and 'element_count' are in use, the _smallest_ of the two is what I would expect to be enforced by the sanitizer and reported by __bdos. As is, alloc_size appears to be used when it is available, regardless of what 'element_count' shows. I've updated my test cases to show it more clearly, but here is the before/after: GCC 13 (correctly does not implement "element_count"): $ ./array-bounds 2>&1 | grep -v ^'#' TAP version 13 1..12 ok 1 global.fixed_size_seen_by_bdos ok 2 global.fixed_size_enforced_by_sanitizer ok 3 global.unknown_size_unknown_to_bdos ok 4 global.unknown_size_ignored_by_sanitizer ok 5 global.alloc_size_seen_by_bdos ok 6 global.alloc_size_enforced_by_sanitizer not ok 7 global.element_count_seen_by_bdos not ok 8 global.element_count_enforced_by_sanitizer not ok 9 global.alloc_size_with_smaller_element_count_seen_by_bdos not ok 10 global.alloc_size_with_smaller_element_count_enforced_by_sanitizer ok 11 global.alloc_size_with_bigger_element_count_seen_by_bdos ok 12 global.alloc_size_with_bigger_element_count_enforced_by_sanitizer ToT GCC + this element_count series: $ ./array-bounds 2>&1 | grep -v ^'#' TAP version 13 1..12 ok 1 global.fixed_size_seen_by_bdos ok 2 global.fixed_size_enforced_by_sanitizer not ok 3 global.unknown_size_unknown_to_bdos not ok 4 global.unknown_size_ignored_by_sanitizer ok 5 global.alloc_size_seen_by_bdos ok 6 global.alloc_size_enforced_by_sanitizer not ok 7 global.element_count_seen_by_bdos ok 8 global.element_count_enforced_by_sanitizer not ok 9 global.alloc_size_with_smaller_element_count_seen_by_bdos not ok 10 global.alloc_size_with_smaller_element_count_enforced_by_sanitizer ok 11 global.alloc_size_with_bigger_element_count_seen_by_bdos ok 12 global.alloc_size_with_bigger_element_count_enforced_by_sanitizer Test suite is here: https://github.com/kees/kernel-tools/blob/trunk/fortify/array-bounds.c -- Kees Cook