Re: [Qemu-devel] [Qemu-arm] [prefix=PATCH for-2.12?] linux-user: check that all of AArch64 SVE extended sigframe is writable

[Peter Maydell]

On 16 April 2018 at 16:19, Peter Maydell <address@hidden> wrote:
> In commit 8c5931de0ac7738809 we added support for SVE extended
> sigframe records.  These mean that the signal frame might now be
> larger than the size of the target_rt_sigframe record, so make sure
> we call lock_user on the entire frame size when we're creating it.
> (The code for restoring the signal frame already correctly handles
> the extended records by locking the 'extra' section separately to the
> main section.)
>
> In particular, this fixes a bug even for non-SVE signal frames,
> because it extends the locked section to cover the
> target_rt_frame_record. Previously this was part of 'struct
> target_rt_sigframe', but in commit e1eecd1d9d4c1ade3 we pulled
> it out into its own struct, and so locking the target_rt_sigframe
> alone doesn't cover it. This bug would mean that we would fail
> to correctly handle the case where a signal was taken with
> SP pointing 16 bytes into an unwritable page, with the page
> immediately below it in memory being writable.
>
> Signed-off-by: Peter Maydell <address@hidden>
> ---
> The requirements to trigger the bug sound implausible, except
> that the stack page might be unwritable because we just
> executed some trampoline code from it, so perhaps not so
> unlikely as it first seems? Not sure whether to put into 2.12
> or not...
> ---

I initially thought this was a non-bug with SVE not enabled, but
when I was testing it I realized it enlarged the size of the
region we VERIFY_WRITE even in the normal case, after commit
aac8f55633f4470e.

-- PMM