From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <ffmpeg-devel-bounces@ffmpeg.org> Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id F35604A44B for <ffmpegdev@gitmailbox.com>; Thu, 28 Mar 2024 07:02:31 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 8466D68D71D; Thu, 28 Mar 2024 09:02:28 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 4EE9968D681 for <ffmpeg-devel@ffmpeg.org>; Thu, 28 Mar 2024 09:02:22 +0200 (EET) Authentication-Results: mail0.khirnov.net; dkim=pass (2048-bit key; unprotected) header.d=khirnov.net header.i=@khirnov.net header.a=rsa-sha256 header.s=mail header.b=Z4PJnkqk; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 15646240DAC for <ffmpeg-devel@ffmpeg.org>; Thu, 28 Mar 2024 08:02:21 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id 9MKUj5wiWuzv for <ffmpeg-devel@ffmpeg.org>; Thu, 28 Mar 2024 08:02:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=khirnov.net; s=mail; t=1711609338; bh=kIEYCOtjLoC5ks98PXxMK4rN1zoTeJduOFRw7Mh4l/0=; h=Subject:From:To:In-Reply-To:References:Date:From; b=Z4PJnkqkIZyFWQiBlUULqhpufM5BBNuzKwvW+nNAiaIKhbW6HuS/7r7HN1dLRF73I +bq0UMgp+Q1K0D8ym7/07iBPuPb1+Ts90Uy9RlYWm93cVBdcP8YEtL2IDH4hfwz4LP MNp1RMtx8phVo5lZn+BlUvLrvcAds7JOy7kJ92BwcghqCUluxMGc6yoxTC3SszzTu9 FKx+ukynE3t9467wJ7WrcUG1pzaf1HqRwa7xxmEQ014CdRlqAfGUhfPD6RoGx6eez4 R7RFO9L9AfGSGezNDv2Bqxn9QpIcDal2jktzKvbPjnDqoJBJSQsn8bqPdMgee4L1Vx ghdHx2rOCKk6A== Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id A6FFB2404AF for <ffmpeg-devel@ffmpeg.org>; Thu, 28 Mar 2024 08:02:18 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id 872121601B9; Thu, 28 Mar 2024 08:02:18 +0100 (CET) From: Anton Khirnov <anton@khirnov.net> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> In-Reply-To: <20240327215414.GK6420@pb2> References: <20240322022525.GB6420@pb2> <171110337183.7287.5315420652895026978@lain.khirnov.net> <20240327215414.GK6420@pb2> Mail-Followup-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Date: Thu, 28 Mar 2024 08:02:18 +0100 Message-ID: <171160933852.7287.16302074271619667148@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [RFC] Channels X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches <ffmpeg-devel.ffmpeg.org> List-Unsubscribe: <https://ffmpeg.org/mailman/options/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=unsubscribe> List-Archive: <https://ffmpeg.org/pipermail/ffmpeg-devel> List-Post: <mailto:ffmpeg-devel@ffmpeg.org> List-Help: <mailto:ffmpeg-devel-request@ffmpeg.org?subject=help> List-Subscribe: <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=subscribe> Reply-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org> Archived-At: <https://master.gitmailbox.com/ffmpegdev/171160933852.7287.16302074271619667148@lain.khirnov.net/> List-Archive: <https://master.gitmailbox.com/ffmpegdev/> List-Post: <mailto:ffmpegdev@gitmailbox.com> Quoting Michael Niedermayer (2024-03-27 22:54:14) > On Fri, Mar 22, 2024 at 11:29:31AM +0100, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2024-03-22 03:25:25) > [...] > > > alternative is "wont fix" for all such cases, > > > > IMO it's not, in general, a bug, so EWONTFIX is the appropriate > > response. If the user does not want us to do arbitrarily large > > allocation, they have the appropriate OS-level mechanisms (e.g. ulimit, > > cgroups on Linux) or av_max_alloc(). > > You misunderstand the issue. > > the issue is coverage in the fuzzer > > if your 32bit channel number is all allowed then in some decoders > and demuxers you will in 99.9% of the cases never go beyond the > channel processing code > because it will timeout or hit OOM > > your suggestion of ulimits, cgroups and other limits dont help > We already have both time and space limits in the fuzzers > > Below is simplifying things a bit > > if 99.9% of the random 32bit channel numbers die in the channel > processing because of the current limit. Then making the limit > tighter will increase that percentage further. > > If you want better coverage you need a channel limit that stops > us before a resource intensive channel processing loop > > you can also write down a model of this problem in a more formal way > Ht as in time spend reading the header > Ct time spend processing each channel after the header > Cmax maximum number of channels that will continue execution after the header > > you will see that a Cmax = 2^32 will never be able to do what s Cmax=512 > can do no matter what external limits you apply > > because if you set really high external limits than 99.9% of time will be > spend in the channel processing code because most of the time the channel > number will be very large and nothing will stop it so little time will be > spend for coverage afterwards > > and OTOH if you set a medium outside memory/time limut then most channel > cases will hit that limit but run the full length of the time limut > here 99.9% of the cases will timeout and take ALOT of time leaving no > resources for coverage after the channel code > > and if you set a realls small outside memory/time limit then maybe you > will quickly stop the channel code but now 99.999% of cases will timeout > in the channel loop and what remains will not have enough time left to > even execute all the code after the loop > > So again if you want fuzzer coverage theres need for a channel limit of > some sort. > > The alternative is to tell everyone that we will not fix this and then > have bad fuzzer coverage for some cases. I understand that this is done for fuzzers, I just disagree that we should introduce arbitrary limits to our code in order to appease them. They should be tools for our benefit, not vice versa. -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".