From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) by sourceware.org (Postfix) with ESMTPS id 9C0683858401 for ; Thu, 1 Jun 2023 14:43:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9C0683858401 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-io1-xd34.google.com with SMTP id ca18e2360f4ac-77749d2613bso40481739f.2 for ; Thu, 01 Jun 2023 07:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685630638; x=1688222638; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=CMDIykLU1x5wy+UARNAVNNL+3VscahCs+4yuPsNam5c=; b=p8Lr3hrx0KzZWMr+R7/Y+5idPJT1I6oNfbkuIQaO69X85iBvMqu2mc+lpSKJ8sB1mf wk2VzCw20RcZVECNLIJCT/eHgexM7oXE1V3HlyK6VRO3PRARgz3+uh81gz7Yv2VbFfiZ ziAjgvCUSWkaW+7mQMfYXw9qopkKa8BMNzPPygRnrOUNT3NSo+/NGcNL+t8vbNbgRxem e3lIYHXMZlVX2C0VIg9kq8tCc1lgVSuaxTFV7y1I6091+DHfuXzITqHiF7rvP4yWWD1v TJ3NdkM5MjkwNJgp4H15KY7fXKW7eNWvPtDgbfsKfivxm5JtK7LmR/Vs1nYbhkUJVXyS R5zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685630638; x=1688222638; h=content-transfer-encoding:in-reply-to: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=CMDIykLU1x5wy+UARNAVNNL+3VscahCs+4yuPsNam5c=; b=V/iSgnVjiHAE/gDnj+SD+4T2dQ9PKjygOC1C4sGX2ZwPeyx115KR+S59Yzr0+V1Tsj E8b83tmClWeuEZ7oGv8PHKpDlDRkC5zIIanmf6pyHK4YWjcI1YDW45k0LhQqyLuf2hzl SeFFNKKHD5RYiksxjY29XWw/pJnH4Wx6tGRow/Z2ryn9WJeGpIJkRIhrl/ladYpObJwn ooXztB7m6JIcAyNUlxYiVIUUUoFFzvdwfyT3zH9aBIcnz6nkYhkQFCAN9VdQlhGlVrmT Lyx0G8Aw0V64F/4KJzbzg+bcXr5Q913cWgsKv9DLhmmojguPsaDrbf6F4DGnOGROYfxg lyVA== X-Gm-Message-State: AC+VfDy2Xl9OZamSKbCAnglFD+tRZ2YUh3eCYbjkExUb/i6Hma1X9nws kcJSjkanV43tM3rRXVScwdYG4qyoiDE= X-Google-Smtp-Source: ACHHUZ5HGfPOHUFiMW8URNYR0QbqCRtG4alqczALrc4tsagnHrNPGi9lWJIGSkiYVCH31kKODwRsag== X-Received: by 2002:a05:6602:4213:b0:76c:7fb0:9d91 with SMTP id cb19-20020a056602421300b0076c7fb09d91mr8639526iob.10.1685630638453; Thu, 01 Jun 2023 07:43:58 -0700 (PDT) Received: from ?IPV6:2601:681:8d00:265::f0a? ([2601:681:8d00:265::f0a]) by smtp.gmail.com with ESMTPSA id i2-20020a5e8502000000b007702f55116fsm4502240ioj.38.2023.06.01.07.43.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Jun 2023 07:43:57 -0700 (PDT) Message-ID: <855f0ed1-d05f-3b17-263b-a2957289e11d@gmail.com> Date: Thu, 1 Jun 2023 08:43:56 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [PATCH v3] ifaddrs: Get rid of alloca Content-Language: en-US To: Joe Simmons-Talbott , libc-alpha@sourceware.org References: <20230530152539.2063770-1-josimmon@redhat.com> From: Jeff Law In-Reply-To: <20230530152539.2063770-1-josimmon@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 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,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 5/30/23 09:25, Joe Simmons-Talbott via Libc-alpha wrote: > Use scratch_buffer and malloc rather than alloca to avoid potential stack > overflows. > --- > Changes to v2: > * Initialize the scratch_buffer earlier to avoid memory access errors > when calling scratch_buffer_free for failure cases. > > Changes to v1: > * in __netlink_request use an 8kb buffer size and malloc rather than a > scratch_buffer. > > Suggested-by: Adhemerval Zanella Netto [ ... ] Just wanted to say thanks for doing this. alloca has been a nightmare through the years from a security standpoint. I advocated for its removal from glibc years ago based on the simple fact that the bugs exposed by the "bad guys" showed that even experienced developers are prone to get this stuff wrong. Instead I wanted to have GCC prove particular allocations were safe to transform into alloca. That never panned out, but I still think the compiler is the right place to exploit the performance improvements one gets from alloca vs malloc/free. jeff