Re: [FFmpeg-devel] [TC] "Future Log Output Default"

["Rémi Denis-Courmont" <remi@remlab.net>]

Le lauantaina 26. huhtikuuta 2025, 18.10.27 Itä-Euroopan kesäaika Michael 
Niedermayer a écrit :
> This is just an announcement that the TC has been asked to look into
>     avutil/log: Add log flag to control printing of memory addresses
>     GitHub:    https://github.com/ffstaging/FFmpeg/pull/59
>     Patchwork:
> https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=14094 ...
> 
> and the disagreement between people about it.
> 
> So far, Niklas, Martin and myself have commented, there have been no formal
> decissions and no votes, we just since yesterday send some comments.
> 
> From these to me it seems the TC members who spoke so far seem to agree
> that the addresses in the log are "mostly noise".

That looks like a very ambivalent qualification and it is unclear to me what 
that would actually imply in terms of technical policies.

TBH, I don't see the point in adding a flag for pointers. The kernel does have 
something like that. But there it is meant to avoid leaking information about 
the kernel address space layout, that could be used to defeat ASLR or heap 
randomisation.

In user space programs and libraries, there is typically no lower privileged 
run-time environment running in a different or subset address space, and which 
could access the logs. So the data leakage concern is moot. It could be a 
problem in a program that provides some kind of sandbox environment for 
untrusted, such as web browsers, but FFmpeg has no such thing.

And going back to the Linux kernel case, I do note that:

1) The implementation overhead is vastly with reduced with the usage of custom 
format string specifiers - but FFmpeg probably doesn't want to take that route, 
in which case the feature will necessarily be much more invasive than in 
Linux.

2) It has been a game of whack-a-mole, with printed pointers regularly being 
found or (re)introduced.

3) Any underlying library hooked to FFmpeg logs would have to be audited for 
leaking pointers or pointer-like handles as well.

Seems pretty steep price for questionable gains.

Nevertheless, FFmpeg should of course avoid printing pointers unless there is 
no better alternatives. As you noted, they are mostly useless in logs except 
as temporally unique identifiers.

-- 
德尼-库尔蒙‧雷米
Tapiolan uusi kaupunki, Uudenmaan entinen Suomen tasavalta



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