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 v2 0/3] Mips support for PT_GNU_STACK



On 18.07.2019. 15:33, Adhemerval Zanella wrote:
>
>
> On 17/07/2019 18:47, Dragan Mladjenovic wrote:
>>
>> On 17.07.2019. 21:43, Adhemerval Zanella wrote:
>>>
>>> On 15/07/2019 15:23, Dragan Mladjenovic wrote:
>>>> Hello everyone,
>>>>
>>>> Patches in this series are a slight variation of work done previously by
>>>> Faraz Shahbazker [1] in 2016.
>>>>
>>>> A brief summary of the issue this is trying to address:
>>>>
>>>> Up until the Linux kernel version 4.8 [2] MIPS FPU emulator used a small trampoline,
>>>> created on user stack, to handle delay slots when emulating FPU branches.
>>>> Because of this non-executable stack could not be enabled by default on MIPS.
>>>> The compatibility issue is that these old kernels respect PT_GNU_STACK,
>>>> making the stack non-executable if requested, and could crash the user process if
>>>> there would be need to emulate an instruction in the delay slot of an FPU branch.
>>>>
>>>> In order to allow for the tool-chain to safely use PT_GNU_STACK by default and to
>>>> provide the compatibility with pre-4.8 kernels, the original patch would revert
>>>> stack protection back to executable stack if it could not detect that kernel
>>>> supports non-executable stack.
>>>>
>>>> The form of detection the patch proposes is not yet provided by the kernel.
>>>> Instead, this version of the patch does kernel version check at runtime and
>>>> provides compatible behavior if it cannot detect the 4.8 kernel or newer.
>>> I think checking the kernel version is the wrong approach, it prevents a distribution
>>> to backport the kernel fix without also applying a out-of-tree patch to fix it on glibc
>>> as well.  IMHO the proper way would be to make kernel advertise it through hwcap, as
>>> other architectures do for similar kernel features and not tie it to any specific
>>> version.
>>
>> First, thanks for the comments.
>>
>> I agree with everything and the original patch did propose the usage of AT_FLAGS
>> auxval for this purpose. But, sadly, the kernel still doesn't advertise this information
>> to the user mode and it would take some time for it to be back-ported even if it gets
>> implemented, let's say in next kernel release. Meanwhile, this approach, while lacking,
>> would allow for distributions to enable PT_GNU_STACK way earlier and to actually
>> enjoy the benefit of it on existing 4.8+ kernels while remaining compatible with pre-4.8
>> ones.
>
> It seems the kernel commit that actually added this support on mips was
> 432c6bacbd0c16ec210c43da411ccc3855c4c010.  Isn't there any other mechanism to check
> for kernel support without tying a kernel version check?
>
> The code seems to reserve an extra page for the delay slot emulation, could we
> infer based on vdso placement, page size, and maximum stack size?
>

Will have to check on this. So far it doesn't seem we can. I think that 
on pre-vdso kernels the same page was used for sigreturn trampoline. I 
either way even if we could do this, we could end up painting ourselves 
in a corner similar as x86_64 with vsyscalls page. It would become the 
part of userspace ABI. For now the emutrap page is just an 
implementation detail.


Best regards,

Dragan




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