On Thu, Dec 14, 2023 at 12:36 AM Ilya Leoshkevich <i...@linux.ibm.com> wrote:
>
> The constraints of the DFLTCC inline assembly are not precise: they
> do not communicate the size of the output buffers to the compiler, so
> it cannot automatically instrument it.
>
> Add the manual kmsan_unpoison_memory() calls for the output buffers.
> The logic is the same as in [1].
>
> [1]
> https://github.com/zlib-ng/zlib-ng/commit/1f5ddcc009ac3511e99fc88736a9e1a6381168c5
>
> Reported-by: Alexander Gordeev <agord...@linux.ibm.com>
> Signed-off-by: Ilya Leoshkevich <i...@linux.ibm.com>
Reviewed-by: Alexander Potapenko <gli...@google.com>
> @@ -34,6 +37,7 @@ static inline dfltcc_cc dfltcc(
> )
> {
> Byte *t2 = op1 ? *op1 : NULL;
> + unsigned char *orig_t2 = t2;
> size_t t3 = len1 ? *len1 : 0;
> const Byte *t4 = op2 ? *op2 : NULL;
> size_t t5 = len2 ? *len2 : 0;
> @@ -59,6 +63,26 @@ static inline dfltcc_cc dfltcc(
> : "cc", "memory");
> t2 = r2; t3 = r3; t4 = r4; t5 = r5;
>
> + switch (fn & DFLTCC_FN_MASK) {
It might be a good idea to add a comment explaining what this block of
code does.
(And that it is no-op in non-KMSAN builds)
