Re: [PATCH] x86: Use pad in pthread_unwind_buf to preserve shadow stack register

["H.J. Lu" <hjl.tools@gmail.com>]

On Tue, Apr 17, 2018 at 1:02 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Fri, 6 Apr 2018, H.J. Lu wrote:
>
>> https://github.com/hjl-tools/glibc/commit/9bf6aefa8fb45f8df140d42ce9cf890bb24076e1
>>
>> It should be binary backward compatible.  I will investigate if there is a way
>
> Increasing the size of a public type is always dangerous, because you can
> end up with one part of a program expecting the new, larger size but
> another part only allocating the old, smaller size.

That is true.  The allocated ucontext size must be no less than the size
expected by ucontext consumer.

> It might in some cases be compatible to the extent that existing linked
> programs and shared libraries work with new glibc, if new glibc will never

This is done by checking CET properties.  Both linker and dynamic linker
clear CET property bits if any module doesn't have CET bits set.  Glibc
should access new extended fields only if CET bits are set, which means
the new ucontext is used in all .o files.  That is why I want to extend
ucontext before we have found a solution so that if an object file has
CET bits set, it must use the new ucontext.

> try to write into the unallocated part of such objects allocated by an
> existing linked program or shared library.  However, any such change would
> need a careful analysis of how the type gets written to, and to what
> extent external libraries have interfaces that depend on the size of the
> type, and would need a NEWS entry explaining the change and discussing the
> compatibility issues with it.
>

Agreed,


-- 
H.J.