On Wed, Jul 5, 2017 at 9:15 AM, Andy Lutomirski <l...@kernel.org> wrote:
> On Wed, Jul 5, 2017 at 7:23 AM, Michal Hocko <mho...@kernel.org> wrote:
>>
>> This is really worrying. This doesn't look like a gap at all. It is a
>> mapping which actually contains a code and so we should absolutely not
>> allow to scribble over it. So I am afraid the only way forward is to
>> allow per process stack gap and run this particular program to have a
>> smaller gap. We basically have two ways. Either /proc/<pid>/$file or
>> a prctl inherited on exec. The later is a smaller code. What do you
>> think?
>
> Why inherit on exec?
.. because the whole point is that you have an existing binary that breaks.
So you need to be able to wrap it in "let's lower the stack gap, then
run that known-problematic binary".
If you think the problem is solved by recompiling existing binaries,
then why are we doing this kernel hack to begin with? The *real*
solution was always to just fix the damn compiler and ABI.
That *real* solution is simple and needs no kernel support at all.
In other words, *ALL* of the kernel work in this area is purely to
support existing binaries. Don't overlook that fact.
Linus
