This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 0/2] aarch64: Enable pointer auth in PLT


On 21/06/2019 13:40, Szabolcs Nagy wrote:
> On 21/06/2019 12:49, Florian Weimer wrote:
>> * Szabolcs Nagy:
>>
>>> On 21/06/2019 11:46, Florian Weimer wrote:
>>>> * Szabolcs Nagy:
>>> the binaries work on an old system if pauth is not
>>> enabled by the kernel.
>>>
>>> i think we don't have prctl or other control
>>> in linux to enable/disable pauth per process
>>> right now so it is not opt-in, the kernel just
>>> informs userspace with a HWCAP that it is enabled.
>>>
>>> if pauth is enabled by the kernel then a pltgot
>>> protected binary does not work without libc support.
>>>
>>> i think there is a similar issue with the unwinder
>>> in case a binray uses pauth for return address
>>> signing: on a system where path is enabled you must
>>> have a pauth aware unwinder.
>>>
>>> i think there is currently no easy way to disable
>>> pauth system wide other than a kernel config.
>>
>> I think this needs to be fixed.  You'll have to add a prctl and some
>> markup in the binaries that can be discovered by the dynamic loader.
>>
>> I expect that we want to use pointer authentication in glibc eventually.
>> We can avoid the need for a protected GOT by using BIND_NOW, but it
>> would be desirable to authentication other function pointers, and we'll
>> need a bootstrap procedure of some sorts for that.
> 
> let's say i somehow add a glibc 2.30 versioned symbol
> reference to binaries that use pltgot auth and a
> libgcc versioned symbol ref to binaries that use return
> address signing.
> 
> that would make those binaries only work with future
> glibc and libgcc (which are pauth aware).
> 
> i assume that's acceptable, although i don't immediately
> see how i can do this for -z pac-plt.

there is no easy way to mark binaries such that
old loader rejects them if it does not understand
the marking.

DT_ or PT_ marking can do this in the future if
they have "mandatory" flags semantics (e.g. gnu
properties can do this if glibc always checks
those at load time and rejects unknown flags).
(symbol reference may work today, but hard coding
symbol refs at link time based on elf extensions
sounds like a hack.)

for unwinder, symbol ref or symbol versioning
works in principle, but i don't know what may break
if we start versioning the unwind abi symbols.

i'm tempted to say that using new -z pac-plt binaries
with old loaders is unsupported, just like using a
binary linked against a new glibc does not work on an
old system, i can update the documentation of -z pac-plt
about this issue (and same for the unwinder vs the
-mbranch-protection=pac-ret gcc option).

the kernel api won't change since the architecture
does not make it easy to disable pauth per process.

> 
> making pauth kernel support opt-in does not really work
> for the unwinder use-case (you may already have signed
> return address when the unwinder is loaded), i think
> "new binaries" will require "new runtime libraries"
> and the best we can do is diagnose when old runtime
> libraries are present.
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]