Re: [PATCH v4] linux: Fix ancillary 64-bit time timestamp conversion (BZ #28349, BZ #28350)

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 26/01/2022 17:48, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On 24/01/2022 09:38, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>>> On 24/01/2022 09:13, Florian Weimer wrote:
>>>>> * Adhemerval Zanella:
>>>>>
>>>>>>> typo: MSG_[C]TRUNC
>>>>>>>
>>>>>>> (I think this MSG_CTRUNC result is a remaining bug we need to fix
>>>>>>> separately for time32 mode.)
>>>>>>
>>>>>> Do you mean not returning the MSG_CTRUNC?
>>>>>
>>>>> No, if the caller uses CMSG_SPACE to allocate space for the expected
>>>>> ancillary data, we should not produce MSG_CTRUNC by stuffing in
>>>>> ancillary data that has not been requested.  Maybe we can do this for
>>>>> time32 code only.  Again it seems that userspace emulation is rather
>>>>> questionable here.
>>>>
>>>> But this would be only an issue for applications using _TIME_BITS=64
>>>> running on older kernels (so 32 bit timestamps would be visible to
>>>> the caller).  Since 64 bit is a opt-in feature, I think users will
>>>> see way more potential issues running _TIME_BITS=64 on older kernels.
>>>
>>> As far as I can see, it is currently an issue for time32 applications
>>> running on old and new kernels.  We synthesize the time64 control
>>> messages unconditionally.
>>
>> time32 applications running on any kernel will continue to see the 
>> timestamps because they will use the old SO_ constants and kernel will
>> synthesize them on the ancillary buffer.
> 
> Will the kernel really produce two timestamps?  I thought the kernel
> kept track which kind of timestamps have been requested and will only
> emit those.

Yes, kernel uses the last one set. But I was not really considering multiple
timestamps, but rather that considering a sufficient buffer provided to
ancillary, time32 applications will continue to see the time32 timestamps 
(and ignore the unknown time64 timestamps).

> 
>> It might be a problem only when time32 application use the new 64 bit 
>> time_t SO_ constants either though a library built with _TIME_SIZE=64
>> or by using it directly (which should not be straightforward since both
>> kernel and glibc only define the 64 bit constants for _TIME_BITS=64).
> 
> Are you sure?  I think our current recvmsg implementation cannot tell
> these two cases apart:
> 
>   (a) time64 application running on an old kernel that does not have
>       time64 timestamping support (so time32 setsockopt was used by
>       glibc)
> 
>   (b) time32 application running on any kernel that uses time32
>       setsockopt
> 
> In both cases, we generate the time64 timestamp, and that can use to
> MSG_CTRUNC.  This is the systemd failure.
> 
>   DHCP6 broken on armhf (and probably other 32 bit arches)
>   <https://github.com/systemd/systemd/issues/20564>
> 
> We can fix this in a follow-up patch.

The MSG_CTRUNC is suppose to be an warning to application would need a large
buffer for (a), it does not really make sense for (b).  I think we can
improve by adding a recvmsg64 that calls __convert_scm_timestamps and
remove the conversion on time32 call.  It would still need a large buffer
for (a), but I expect that time64 applications that expects to run on
older kernels would need to handle it.