From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 33286C433B4 for ; Thu, 6 May 2021 15:43:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0AF9A610C8 for ; Thu, 6 May 2021 15:43:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235346AbhEFPoE (ORCPT ); Thu, 6 May 2021 11:44:04 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:25347 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235145AbhEFPn6 (ORCPT ); Thu, 6 May 2021 11:43:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620315779; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4KmRXMHEZ+tVNwwgfG0qof+36HnLMbB1FdIrxdalX6M=; b=BquaxmH/Z5+T/EjIDNfbS4m3MA7rb9E8fgwqHemxL3RDDlmpxSkKySQ4vyK8tSxgbX5gmi Z+8tzyQMDxIl6Ntw0Nls7U+FPIy6Q/+1NreJz45Pxd6HJls9Mfy5azf2wfKiGK3v47C6Ou hxda2q4SWXLBB3wh5HVnM234id5O5NA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-222-HqYu6-wIOUGL-HnIy_9qew-1; Thu, 06 May 2021 11:42:56 -0400 X-MC-Unique: HqYu6-wIOUGL-HnIy_9qew-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D196D80ED9B; Thu, 6 May 2021 15:42:54 +0000 (UTC) Received: from [10.3.113.56] (ovpn-113-56.phx2.redhat.com [10.3.113.56]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A7CAE60862; Thu, 6 May 2021 15:42:50 +0000 (UTC) Subject: Re: [PATCH v2 4/9] bsd-user/syscall: Replace alloca() by g_new() To: Warner Losh Cc: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , kvm-devel , Kyle Evans , QEMU Developers , qemu-arm , qemu-ppc , Gerd Hoffmann , Paolo Bonzini , =?UTF-8?Q?Alex_Benn=c3=a9e?= References: <20210506133758.1749233-1-philmd@redhat.com> <20210506133758.1749233-5-philmd@redhat.com> <39f12704-af5c-2e4f-d872-a860d9a870d7@redhat.com> <7a96d45e-2bdc-f699-96f7-3fbf607cb06b@redhat.com> From: Eric Blake Organization: Red Hat, Inc. Message-ID: Date: Thu, 6 May 2021 10:42:50 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On 5/6/21 10:30 AM, Warner Losh wrote: > > But for the real answer, I need to contact the original authors of > this part of the code (they are no longer involved day-to-day in > the bsd-user efforts) to see if this scenario is possible or not. If > it's easy to find out that way, we can either know this is safe to > do, or if effort is needed to make it safe. At present, I've seen > enough and chatted enough with others to be concerned that > the change would break proper emulation. Do we have a feel for the maximum amount of memory being used by the various alloca() replaced in this series? If so, can we just stack-allocate an array of bytes of the maximum size needed? Then we avoid alloca() but also avoid the dynamic memory management that malloc() would introduce. Basically, it boils down to auditing why the alloca() is safe, and once we know that, replacing the variable-sized precise alloca() with its counterpart statically-sized array allocation, at the expense of some wasted stack space when the runtime size does not use the full compile-time maximum size. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org