On June 22, 2017 7:17:16 PM GMT+02:00, Jeff Law <l...@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 <l...@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
