[FFmpeg-devel] [PATCH] Workaround to build ffmpeg on MacOs 10.15
Martin Storsjö
martin at martin.st
Sat Jan 4 21:25:40 EET 2020
On Sat, 4 Jan 2020, Michael Niedermayer wrote:
> On Sat, Jan 04, 2020 at 12:06:55AM +0100, Henrik Gramner wrote:
>> On Fri, Jan 3, 2020 at 7:37 PM Moritz Barsnick <barsnick at gmx.net> wrote:
>>> On Fri, Jan 03, 2020 at 11:05:25 +0100, Timo Rothenpieler wrote:
>>>> I think this was discussed on this list in the past.
>>>> Not sure what the conclusion was, but I think an unconditional flag like
>>>> this being added wasn't all that well received.
>>>
>>> Yes, discussed in this thread in November:
>>> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/253193.html
>>
>> Lmao "security feature". Just disable that flag and call it a day, it
>> adds nothing of value (unless you consider crashing to be a "security
>> feature"?).
>
> I dont know how effective this is or what exactly this option does, i
> couldnt find documentation for it quickly what it does in clang on macosx.
> google keeps pointing to gcc
> but
>
> a crash is better than arbitrary code execution, which IIUC is the idea
> here, if the stack of a thread grows too much, crash instead of overwriting
> something that comes after it.
> Not crashing when the stack overlapps another threads stack or heap is
> unlikely to be better.
The point here is, disabling this "feature" is not a security regression -
it's a new feature in apple's clang, which only is enabled when you target
a new enough version of macOS. And that new security feature is broken to
the point that the process crashes before you even get to code which may
be misbehaving.
So disabling it isn't a regression, it just takes things back to how
things were before, before this was introduced.
// Martin
More information about the ffmpeg-devel
mailing list