[PATCH v4] aarch64: enforce >=64K guard size
Szabolcs Nagy
szabolcs.nagy@arm.com
Mon Jul 16 14:10:00 GMT 2018
On 16/07/18 10:35, Florian Weimer wrote:
> * Szabolcs Nagy:
>
>> On 14/07/18 15:02, Florian Weimer wrote:
>>> * Szabolcs Nagy:
>>>
>>>> There are several compiler implementations that allow large stack
>>>> allocations to jump over the guard page at the end of the stack and
>>>> corrupt memory beyond that. See CVE-2017-1000364.
>>>>
>>>> Compilers can emit code to probe the stack such that the guard page
>>>> cannot be skipped, but on aarch64 the probe interval is 64K by default
>>>> instead of the minimum supported page size (4K).
>>>>
>>>> This patch enforces at least 64K guard on aarch64 unless the guard
>>>> is disabled by setting its size to 0. For backward compatibility
>>>> reasons the increased guard is not reported, so it is only observable
>>>> by exhausting the address space or parsing /proc/self/maps on linux.
>>>
>>> Is there anything special in the aarch64 probing sequence that
>>> *requires* that the guard is 64 KiB, or is it just that it is not
>>> effective if it is not?
>>>
>>
>> it's not effective (the probe interval is 64k)
>
> Then I don't understand why it's necessary to override an explicitly
> specified guard size. Changing the default should be sufficient.
>
oh and earlier posix standards required the default
guard size to be 1 page, which is observable via
current pthread_{get}attr* apis.
(nptl/tst-attr2.c even tests for this)
so changing the default would break conforming code
unless we change the logic around how the attr apis
report the size.
More information about the Libc-alpha
mailing list