Re: Bug 29863 - Segmentation fault in memcmp-sse2.S if memory contents can concurrently change

[Wilco Dijkstra <Wilco.Dijkstra@arm.com>]

Hi,

>On Tue, Dec 13, 2022, at 11:16 PM, Carlos O'Donell wrote:
>> The standards are in no way prescriptive in saying that memcmp shall not read or
>> write to memory outside of the input domain.
>
> ... is (as I read it) contradicted by 7.1.4p5 (N1570) "A library function shall not directly or
> indirectly access objects accessible by threads other than the current thread unless the
> objects are accessed directly or indirectly via the function's arguments."  There is more
> wiggle room in this wording than I'd ideally like, but since memcmp has no way of knowing
> whether any particular piece of data outside the ranges supplied as arguments is "accessible
> by threads other than the current thread", it needs to be conservative and not touch any of it.

I'd expect that mem* functions will never read outside their bounds since the bounds are
explicitly defined by the arguments, not by the data. So that should be easy to guarantee.

For the str* functions it may be harder since the data itself defines when to stop reading.
So if an implementation uses multiple accesses to the same address, you could potentially
mistake the end of a string (eg. first one detects a special case, while the 2nd then verifies it).

Still, I wouldn't expect totally random memory accesses even in this case - you would read
beyond the end of a string if the string end is changed concurrently.

Note there is also a security risk here - an attacker could cause an out of bounds access
to extract secret data that otherwise wouldn't be accessible. Eg. functions in the Linux
kernel accessing user data should be resilient to concurrent modifications of the data.

Finally it's worth mentioning that nscd does the exact same thing: it uses memcmp and
non-atomic accesses on shared data that is being modified by other threads. It looks
totally broken, especially with weaker memory ordering, however this kind of insanity
may actually be a common design pattern...

Cheers,
Wilco