This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFA] Fix -fstack-check with really big frames on aarch64
On June 22, 2017 7:17:16 PM GMT+02:00, Jeff Law <law@redhat.com> wrote:
>On 06/22/2017 11:07 AM, Jakub Jelinek wrote:
>> On Thu, Jun 22, 2017 at 10:02:16AM -0700, Mike Stump wrote:
>>> On Jun 22, 2017, at 8:32 AM, Jeff Law <law@redhat.com> wrote:
>>>>
>>>> Sure. I'll do something with 20031023-1.c to ensure it or an
>equivalent
>>>> is compiled with -fstack-check. That isn't totally unexpected. I
>>>> would have also been receptive to adding -fstack-check to the
>torture flags.
>>>
>>> Ouch. Though stack checking might be important, the feature is
>very, very
>>> narrow, and once tested, if unlike to ever break or interact badly
>with
>>> other work. I'd rather people default it to on, run the entire
>suite, fix
>>> all bugs (with test cases added for all the bugs), then turn it back
>off.
>>> Additional torture passes are expensive; we use them for things that
>do
>>> regress, that are important, that have thousands of moving parts to
>keep
>>> them working. O2, -g are good examples for things that by their
>nature,
>>> likely will always be best served by torture options. Now, if you
>want to
>>> focus on security for 1-3 months, add it, fix all the bugs, then
>turn it
>>> off; it would be a great way to get all the bugs filed, if you want.
>>
>> Yeah, I think it should be enough to have one or a couple of
>-fstack-check
>> covering testcases in the testsuite, with 10-20 different static
>frame sizes
>> (a couple of leaf functions and then functions that call something)
>and then
>> for each also variant with alloca or VLA, make it executable and test
>you
>> can store stuff in the buffers and read it back in some other
>function,
>> compile this with -fno-omit-frame-pointer, -fomit-frame-pointer and
>default.
>> No need to torture everything with it.
>I expect we'll want to do a bit more than that -- in particular if we
>look at how prologues as generated on aarch64, we'll want to test each
>of the paths through there which allocate stack space and verify that
>the proper probes are emitted or omitted.
>
>The thought of scanning the assembly code or RTL is too painful to
>contemplate. THus I've been pondering having the prologue expanders
>emit notes into the dump file about what they did and why WRT probing.
>
>Or maybe we should use the unit testing framewhere here. Hmmm....
I've been thinking that for Linux the kernel should have a way (/proc/pid controlled) to only extend the stack mapping for faults to the page exactly below the current end of the mapping. So we'd get a segfault for any missed probe.
Just for QA purposes of course, I expect too many false positives in a full system.
Richard.
>
>jeff