From: Kees Cook <keescook@chromium.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Boqun Feng <boqun.feng@gmail.com>,
Catalin Marinas <catalin.marinas@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] arm64: atomics: Dereference matching size
Date: Wed, 12 Jan 2022 12:18:58 -0800 [thread overview]
Message-ID: <202201121217.FB408C2362@keescook> (raw)
In-Reply-To: <YdwKLwvDRfc59c8U@FVFF77S0Q05N>
On Mon, Jan 10, 2022 at 10:27:59AM +0000, Mark Rutland wrote:
> Hi Kees,
>
> On Fri, Jan 07, 2022 at 03:27:46PM -0800, Kees Cook wrote:
> > When building with -Warray-bounds (which is desired to be enabled
> > globally), the following warning is generated:
> >
> > In file included from ./arch/arm64/include/asm/lse.h:16,
> > from ./arch/arm64/include/asm/cmpxchg.h:14,
> > from ./arch/arm64/include/asm/atomic.h:16,
> > from ./include/linux/atomic.h:7,
> > from ./include/asm-generic/bitops/atomic.h:5,
> > from ./arch/arm64/include/asm/bitops.h:25,
> > from ./include/linux/bitops.h:33,
> > from ./include/linux/kernel.h:22,
> > from kernel/printk/printk.c:22:
> > ./arch/arm64/include/asm/atomic_lse.h:247:9: warning: array subscript 'long unsigned int[0]' is partly outside array bounds of 'atomic_t[1]' [-Warray-bounds]
> > 247 | asm volatile( \
> > | ^~~
> > ./arch/arm64/include/asm/atomic_lse.h:266:1: note: in expansion of macro '__CMPXCHG_CASE'
> > 266 | __CMPXCHG_CASE(w, , acq_, 32, a, "memory")
> > | ^~~~~~~~~~~~~~
> > kernel/printk/printk.c:3606:17: note: while referencing 'printk_cpulock_owner'
> > 3606 | static atomic_t printk_cpulock_owner = ATOMIC_INIT(-1);
> > | ^~~~~~~~~~~~~~~~~~~~
> >
> > This is due to the compiler seeing an unsigned long * cast against
> > something (atomic_t) that is int sized. Replace the cast with the
> > matching size cast. This results in no change in binary output.
>
> Just to check, I assume both GCC and Clang are happy with this applied?
>
> I recall that (historically at least) clang would warn about size mismatches
> for inline assembly and would sometimes require more care. I don't see anythign
> for which that would matter, but I just want to check.
Yup, Clang is happy with this AFAICT.
>
> > Cc: Will Deacon <will@kernel.org>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Boqun Feng <boqun.feng@gmail.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > ---
> > arch/arm64/include/asm/atomic_lse.h | 2 +-
> > arch/arm64/include/asm/cmpxchg.h | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/atomic_lse.h b/arch/arm64/include/asm/atomic_lse.h
> > index d955ade5df7c..5d460f6b7675 100644
> > --- a/arch/arm64/include/asm/atomic_lse.h
> > +++ b/arch/arm64/include/asm/atomic_lse.h
> > @@ -249,7 +249,7 @@ __lse__cmpxchg_case_##name##sz(volatile void *ptr, \
> > " mov %" #w "[tmp], %" #w "[old]\n" \
> > " cas" #mb #sfx "\t%" #w "[tmp], %" #w "[new], %[v]\n" \
> > " mov %" #w "[ret], %" #w "[tmp]" \
> > - : [ret] "+r" (x0), [v] "+Q" (*(unsigned long *)ptr), \
> > + : [ret] "+r" (x0), [v] "+Q" (*(u##sz *)ptr), \
> > [tmp] "=&r" (tmp) \
> > : [old] "r" (x1), [new] "r" (x2) \
> > : cl); \
>
> It might be worth nothing that __ll_sc__cmpxchg_case_##name##sz already uses
> the same constraint:
>
> [v] "+Q" (*(u##sz *)ptr
>
> ... since that explains why we only need to update the LSE form and not the
> LL/SC form, and indicates that this is unlikely to be problematic.
Good idea, I'll note that in a v2.
>
> Either way:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks!
-Kees
>
> Thanks,
> Mark.
>
> > diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h
> > index f9bef42c1411..497acf134d99 100644
> > --- a/arch/arm64/include/asm/cmpxchg.h
> > +++ b/arch/arm64/include/asm/cmpxchg.h
> > @@ -243,7 +243,7 @@ static inline void __cmpwait_case_##sz(volatile void *ptr, \
> > " cbnz %" #w "[tmp], 1f\n" \
> > " wfe\n" \
> > "1:" \
> > - : [tmp] "=&r" (tmp), [v] "+Q" (*(unsigned long *)ptr) \
> > + : [tmp] "=&r" (tmp), [v] "+Q" (*(u##sz *)ptr) \
> > : [val] "r" (val)); \
> > }
> >
> > --
> > 2.30.2
> >
--
Kees Cook
prev parent reply other threads:[~2022-01-12 20:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-07 23:27 [PATCH] arm64: atomics: Dereference matching size Kees Cook
2022-01-08 9:31 ` Ard Biesheuvel
2022-01-10 10:27 ` Mark Rutland
2022-01-12 20:18 ` Kees Cook [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202201121217.FB408C2362@keescook \
--to=keescook@chromium.org \
--cc=boqun.feng@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).