Another libffi ABI change and another release

Another libffi ABI change and another release

[Anthony Green]

HJ from Intel just contributed a set of ABI changing patches that will move
us up to .so.8.

These are changes increase trampoline sizes in order to support Intel's
Control-Flow Enforcement Technology (CET), which is designed to counter
return-oriented programming attacks.  My understanding is that this might
require changes to kernel trampoline emulators, like EMUTRAMP and S.A.R.A.
(copying the author).

The only other notable changes are some 32-bit PPC fixes and a soft-float
MIPS correction.

I just thought I'd float this idea in case anyone has any pending urgent
changes.  I'd like to get a new release out so we can upgrade the libffi in
Fedora (which so far has not published the .7 version).

AG

Re: Another libffi ABI change and another release

[Tom Tromey]

>>>>> "Anthony" == Anthony Green <green@moxielogic.com> writes:

Anthony> I just thought I'd float this idea in case anyone has any pending urgent
Anthony> changes.  I'd like to get a new release out so we can upgrade the libffi in
Anthony> Fedora (which so far has not published the .7 version).

I don't know if there are urgent ones (certainly I don't have anything
written) but I think a while back there was a thread about a wish-list
for ABI breaks.  But perhaps if we're breaking ABI now, it could be done
again in the future.

Tom

Re: Another libffi ABI change and another release

[Anthony Green]

On Mon, Feb 24, 2020 at 6:21 PM Tom Tromey <tom@tromey.com> wrote:

> I don't know if there are urgent ones (certainly I don't have anything
> written) but I think a while back there was a thread about a wish-list
> for ABI breaks.  But perhaps if we're breaking ABI now, it could be done
> again in the future.
>

Yes, some of them were related to trampoline layouts, which aren't relevant
if we go this route...
http://sourceware-org.1504.n7.nabble.com/Crashes-of-libffi-when-using-W-X-memory-and-forks-td412729.html
...which is what I'd like to do.

Landon Fuller came up with this hack for the iOS port, but it seems that it
is generally useful, and would solve a number of issues.

AG

Re: Another libffi ABI change and another release

[Tom Tromey]

Anthony> Yes, some of them were related to trampoline layouts, which aren't relevant
Anthony> if we go this route...
Anthony> http://sourceware-org.1504.n7.nabble.com/Crashes-of-libffi-when-using-W-X-memory-and-forks-td412729.html
Anthony> ...which is what I'd like to do.

The ones I was thinking of were in this thread

https://sourceware.org/ml/libffi-discuss/2015/msg00090.html

But AFAIK there aren't patches for any of these ideas.

Tom

Re: Another libffi ABI change and another release

[Matthias Klose]

On 2/25/20 6:05 PM, Tom Tromey wrote:
> Anthony> Yes, some of them were related to trampoline layouts, which aren't relevant
> Anthony> if we go this route...
> Anthony> http://sourceware-org.1504.n7.nabble.com/Crashes-of-libffi-when-using-W-X-memory-and-forks-td412729.html
> Anthony> ...which is what I'd like to do.
> 
> The ones I was thinking of were in this thread
> 
> https://sourceware.org/ml/libffi-discuss/2015/msg00090.html
> 
> But AFAIK there aren't patches for any of these ideas.

I have now the request to enable CET in a distro, and before bumping the soname
myself, or invent an arbitrary soname which won't be used by upstream, I'd like
to ask if an upstream release could be cut now, without repeating the multi-year
release process we had with libffi 3.3.

Thanks, Matthias

Re: Another libffi ABI change and another release

[Florian Weimer]

* Matthias Klose:

> On 2/25/20 6:05 PM, Tom Tromey wrote:
>> Anthony> Yes, some of them were related to trampoline layouts, which aren't relevant
>> Anthony> if we go this route...
>> Anthony> http://sourceware-org.1504.n7.nabble.com/Crashes-of-libffi-when-using-W-X-memory-and-forks-td412729.html
>> Anthony> ...which is what I'd like to do.
>> 
>> The ones I was thinking of were in this thread
>> 
>> https://sourceware.org/ml/libffi-discuss/2015/msg00090.html
>> 
>> But AFAIK there aren't patches for any of these ideas.
>
> I have now the request to enable CET in a distro, and before bumping
> the soname myself, or invent an arbitrary soname which won't be used
> by upstream, I'd like to ask if an upstream release could be cut now,
> without repeating the multi-year release process we had with libffi
> 3.3.

Which soname do you use right now?

Thanks,
Florian

Re: Another libffi ABI change and another release

[Matthias Klose]

On 7/13/20 12:47 PM, Florian Weimer wrote:
> * Matthias Klose:
> 
>> On 2/25/20 6:05 PM, Tom Tromey wrote:
>>> Anthony> Yes, some of them were related to trampoline layouts, which aren't relevant
>>> Anthony> if we go this route...
>>> Anthony> http://sourceware-org.1504.n7.nabble.com/Crashes-of-libffi-when-using-W-X-memory-and-forks-td412729.html
>>> Anthony> ...which is what I'd like to do.
>>>
>>> The ones I was thinking of were in this thread
>>>
>>> https://sourceware.org/ml/libffi-discuss/2015/msg00090.html
>>>
>>> But AFAIK there aren't patches for any of these ideas.
>>
>> I have now the request to enable CET in a distro, and before bumping
>> the soname myself, or invent an arbitrary soname which won't be used
>> by upstream, I'd like to ask if an upstream release could be cut now,
>> without repeating the multi-year release process we had with libffi
>> 3.3.
> 
> Which soname do you use right now?

libffi.so.7, as found in the libffi 3.3 release.

Re: Another libffi ABI change and another release

[Florian Weimer]

* Matthias Klose:

> On 7/13/20 12:47 PM, Florian Weimer wrote:
>> * Matthias Klose:
>> 
>>> On 2/25/20 6:05 PM, Tom Tromey wrote:
>>>> Anthony> Yes, some of them were related to trampoline layouts, which aren't relevant
>>>> Anthony> if we go this route...
>>>> Anthony> http://sourceware-org.1504.n7.nabble.com/Crashes-of-libffi-when-using-W-X-memory-and-forks-td412729.html
>>>> Anthony> ...which is what I'd like to do.
>>>>
>>>> The ones I was thinking of were in this thread
>>>>
>>>> https://sourceware.org/ml/libffi-discuss/2015/msg00090.html
>>>>
>>>> But AFAIK there aren't patches for any of these ideas.
>>>
>>> I have now the request to enable CET in a distro, and before bumping
>>> the soname myself, or invent an arbitrary soname which won't be used
>>> by upstream, I'd like to ask if an upstream release could be cut now,
>>> without repeating the multi-year release process we had with libffi
>>> 3.3.
>> 
>> Which soname do you use right now?
>
> libffi.so.7, as found in the libffi 3.3 release.

I see.  My team at Red Hat has it on our to-do list to produce an
ABI-compatible libffi.so.6 with CET support, but that won't help you.

Thanks,
Florian

Re: Another libffi ABI change and another release

[Matthias Klose]

On 2/25/20 12:21 AM, Tom Tromey wrote:
>>>>>> "Anthony" == Anthony Green <green@moxielogic.com> writes:
> 
> Anthony> I just thought I'd float this idea in case anyone has any pending urgent
> Anthony> changes.  I'd like to get a new release out so we can upgrade the libffi in
> Anthony> Fedora (which so far has not published the .7 version).
> 
> I don't know if there are urgent ones (certainly I don't have anything
> written) but I think a while back there was a thread about a wish-list
> for ABI breaks.  But perhaps if we're breaking ABI now, it could be done
> again in the future.

May I ping again about a release, or just saying that you are not planning for a
release?

Thanks, Matthias