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 12:49, Florian Weimer wrote:
> * Szabolcs Nagy:
> 
>> On 21/06/2019 11:46, Florian Weimer wrote:
>>> * Szabolcs Nagy:
>>>
>>>> On 21/06/2019 10:12, Florian Weimer wrote:
>>>>> * Szabolcs Nagy:
>>>>>
>>>>>> Pointer authentication is an armv8.3-a extension and it can be used
>>>>>> to harden PLTGOT entries when that is not read-only protected.
>>>>>>
>>>>>> binutils bfd linker now supports creating binaries with -z pac-plt
>>>>>> and then PLT entries authenticate the pointers loaded from PLTGOT.
>>>>>>
>>>>>> To support such binaries the glibc dynamic linker has to "sign" the
>>>>>> pointers in the PLTGOT. On cpus without pointer authentication support,
>>>>>> both the sign and authentication operations are nops, so such binaries
>>>>>> may appear to work now, but on a new cpu they will crash without glibc
>>>>>> support.
>>>>>
>>>>> I think you need to enable this feature in a different way, similar to
>>>>> the non-executable stack.  Otherwise, people will have to decide whether
>>>>> they want to build portable binaries or binaries with security
>>>>> hardening, which is not desirable.
>>>>
>>>> with non-executable stack, a hardened binary works on
>>>> an old system that uses executable stack.
>>>>
>>>> in this case a hardened binary does not work on an old
>>>> system that's unaware of pointer auth.
>>>
>>> Does it work on an old system without kernel support for pointer
>>> authentication?  With just support in the CPU?
>>
>> 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.

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]