This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fwd: What can a signal handler do with SIGSTKSZ?


On 14/01/2019 16:22, Carlos O'Donell wrote:
> On 1/14/19 11:18 AM, Florian Weimer wrote:
>> * Szabolcs Nagy:
>>
>>> i think proposing sysconf(_SC_{MIN}SIGSTKSZ) for posix is the
>>> right solution with the kernel providing an upper bound of the
>>> stack frame in AT_MINSIGSTKSZ (as it already does on aarch64).
>>
>> It's still a bit nasty for process migration, but at least it should for
>> VM migration.  I think that would be a reasonable compromise.
>>
>> Of course, we'd still need a way to determine how much we should add on
>> top of AT_MINSIGSTKSZ for the application developer's benefit. 8-)
> 
> The value of SIGSTKSZ seems to be a "culturally relevant detail" that will
> probably be impossible to pin down to a real value.
> 
> If *I* were a developer I might expect as Zach pointed out, that I can call
> every function on the list of callable AS-safe functions, at least once,
> without recursion, and expect them to operate correctly.
> 
> A test case for this would therefore be a main, that register a handler
> that exercises *all* functions in the AS-safe list, and then looks for
> stack corruption at each execution.
> 
> The test could also be used to set the value to some accepted value for
> all machines.
> 
> Can we do this in practice?

e.g. exec functions that need to copy their
arguments to an on stack argv array may fail
depending on how many args are passed.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]