[PATCH v2 3/3] aarch64: GCS: add clone3 tests for shadow stack
Yury Khrustalev
yury.khrustalev@arm.com
Mon Sep 15 14:15:08 GMT 2025
* Adhemerval
On Mon, Sep 15, 2025 at 10:31:10AM -0300, Adhemerval Zanella Netto wrote:
> On 15/09/25 08:37, Yury Khrustalev wrote:
> > On Tue, Sep 09, 2025 at 11:31:53AM -0300, Adhemerval Zanella Netto wrote:
> >>
> >>> Parsing /proc/self/smaps requires much more code, I'll add it in the
> >>> next version of the patch. After the thread started we'll have 2
> >>> mappings with with the ss flag: parent and child. After cancellation we
> >>> expect 1 mapping (the parent one).
> >>
> >> It depends if the kernel supports MADV_GUARD_INSTALL and if the pthread
> >> requires a guard page. I think to simplify you can disable the guard page
> >> to always expect one mapping.
> >
> > Unless I'm missing something, I don't think guard page is involved here
> > at all. We have parent and child shadow stacks after the thread started
> > and only parent's shadow stack remains when the thread is cancelled.
>
> I meant to count the number of VMA as presented in /proc/self/smaps, assuming
> the idea is to take a snapshot before and after pthread_create/pthread_join
> to check the difference.
>
> If the underlying kernel supports MADV_GUARD_INSTALL we will not have the guard
> page.
I've been trying to write something sensible to obtain information from
the smaps file, however the fundamental issue is that this file is big
and it changes frequently, so reading it line by line (or via any other
chunk size), may still be unreliable, especially if we want to use it in
a multi-threading context.
To save time and for the purposes of this test, I'll just save the value
of the shadow stack pointer in the thread before it's cancelled and then
use to check that the relevant memory was indeed unmapped.
Thanks,
Yury
More information about the Libc-alpha
mailing list