Re: bind(2): Missing [[gnu::nonnull]]

[Zack Weinberg via Libc-alpha <libc-alpha@sourceware.org>]

On 2022-12-04 1:46 PM, Florian Weimer via Libc-alpha wrote:
> * Alejandro Colomar via Libc-alpha:
>> On 12/4/22 06:59, Xi Ruoyao wrote:
>>> On Sat, 2022-12-03 at 20:05 +0100, Andreas Schwab wrote:
>>>>> Currently the man page says:
>>>>
>>>> You can never depend on EFAULT for invalid addresses.
>>> Hmm, is this documented somewhere?
>>
>> I don't know, but let me have an educated guess:
>>
>> Holding a pointer to invalid memory is Undefined Behavior by the
>> standard, except if that pointer is NULL, or is still indeterminate
>> because the pointer has not yet been initialized with a valid address.
>> Using an uninitialized pointer is UB as using any uninitialized
>> variable.  Using a NULL pointer is only okay for comparisons, or as a
>> sentinel value, but never for accessing memory. So chances are high
>> that the program will already have invoked UB at the time bind(2) is
>> called with an invalid address.
> 
> Currently, Linux does not report for vDSO-accelerated system calls, but
> generates SIGSEGV.  We received bug reports when we added vDSO support
> for time/gettimeofday/clock_gettime because some tests were relying on
> the EFAULT behavior.

I don't have time to dig through POSIX and find it now, but I'm like 95% 
sure there's explicit wording to the effect that the OS is allowed to 
send SIGSEGV under any circumstance that's documented to result in an 
EFAULT error, and vice versa.  That should be good enough for the 
_manpages_, but I think the _headers_ probably need to be more cautious 
about adding annotations that can cause compilers to draw new inferences 
about which control flow paths are unreachable.

I imagine this would be a hard sell with the "never break userspace" 
crowd but I would _like_ Linux to at least have a mode in which it would 
always send SIGSEGV rather than producing EFAULT.  It seems like it 
would be helpful for debugging.

zw