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".