On 16 April 2018 at 16:19, Peter Maydell <peter.mayd...@linaro.org> 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 <peter.mayd...@linaro.org> > --- > 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