Duplicate SMB file_ids leading to Windows client cache poisoning
tom at talpey.com
Thu Dec 9 18:48:13 UTC 2021
Yes I was referring to filesystem timestamps because you had
mentioned mtime ctime and atime. But I have a similar concern
with hrtimers, because they are so hardware dependent. Older
hardware may not have one at all, and even if present they
uniqueness is only assured in specific narrow contexts. For
example, they are per-socket so high-scale architectures can
introduce anomalies if the thread is migrated. They're especially
unreliable in virtualized environments. And the timespec struct
exposes them with nanosecond granularity, which is pretty wide IMO.
The clock_gettime manpage has more than a few caveats:
> NOTE for SMP systems
> The CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID clocks are realized on many platforms using timers from the CPUs (TSC on i386, AR.ITC on Itanium). These registers may differ between CPUs and as a consequence these clocks may return bogus results if a process is migrated to another CPU.
> If the CPUs in an SMP system have different clock sources then there is no way to maintain a correlation between the timer registers since each CPU will run at a slightly different frequency. If that is the case then clock_getcpuclockid(0) will return ENOENT to signify this condition. The two clocks will then only be useful if it can be ensured that a process stays on a certain CPU.
> The processors in an SMP system do not start all at exactly the same time and therefore the timer registers are typically running at an offset. Some architectures include code that attempts to limit these offsets on bootup. However, the code cannot guarantee to accurately tune the offsets. Glibc contains no provisions to deal with these offsets (unlike the Linux Kernel). Typically these offsets are small and therefore the effects may be negligible in most cases.
I really think you need a bulletproof mathematically correct
uniqueid generator here.
On 12/8/2021 10:36 PM, Ralph Boehme wrote:
> Hi Tom!
> On 12/8/21 22:18, Tom Talpey wrote:
>> I have to say that I'm siding with Steve on not using timestamps,
>> even with a monotonicity salt. They're terribly old-school and
>> for good reason. If you want reliable results when running on
>> everything from embedded ARM systems with FAT (2-second granularity)
>> on an MMC card, all the way up to servers with PMEM (<<1us access
>> time) and networks with 100+ Gbps pipes, timestamps will be
>> whack-a-mole for many years. MHO.
> I guess you are referring to filesystem timestamps? I was suggesting
> moving away from that and using system high resolution timer, not
> filesystem timestamp. That's what we're currently using which seems to
> break on certain filesystem with too low resolution. We've been using
> the inode number before which has its own problems due to inode number
More information about the samba-technical