All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: "Miles Chen (陳民樺)" <miles.chen@mediatek.com>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Linux Crypto Mailing List" <linux-crypto@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	linux-mediatek@lists.infradead.org,
	"Eric Biggers" <ebiggers@google.com>,
	"Sami Tolvanen" <samitolvanen@google.com>
Subject: Re: [PATCH] lib/crypto: blake2s: fix a CFI failure
Date: Wed, 19 Jan 2022 10:13:51 +0100	[thread overview]
Message-ID: <CAMj1kXGUtg1BOauCjxB+S7yMTPArQrPnHf5jnfhOihL-FHrFZA@mail.gmail.com> (raw)
In-Reply-To: <CAMj1kXEuWRUbCqDBnxiWRaERt6OGL8ufQ1Q7naAGHqKK1oQB1w@mail.gmail.com>

On Wed, 19 Jan 2022 at 10:09, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> (+ Sami, Eric)
>
> On Wed, 19 Jan 2022 at 10:00, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >
> > Hi Miles,
> >
> > Thanks for the patch. Could you let me know which architecture and
> > compiler this was broken on? If I had to guess, I'd wager arm32, and
> > you hit this by enabling optimized blake2s?
> >
> > If so, I'm not sure the problem is with weak symbols. Why should CFI
> > break weak symbols? Rather, perhaps the issue is that the function is
> > defined in blake2s-core.S? Are there some CFI macros we need for that
> > definition?
> >
>
> We should try to understand why CFI thinks the prototypes of the two
> symbols are different. There are still a number of issues with CFI, so
> papering over them by reverting stuff that we want for good reasons is
> not the way to go imo.
>
> In the short term, you can work around it by avoiding the indirect
> call to blake2s_compress, e.g.,
>
> diff --git a/lib/crypto/blake2s.c b/lib/crypto/blake2s.c
> index 93f2ae051370..fef2ff678431 100644
> --- a/lib/crypto/blake2s.c
> +++ b/lib/crypto/blake2s.c
> @@ -16,9 +16,15 @@
>  #include <linux/init.h>
>  #include <linux/bug.h>
>
> +static void __blake2s_compress(struct blake2s_state *state, const u8 *block,
> +                              size_t nblocks, const u32 inc)
> +{
> +       return blake2s_compress(state, block, nblocks, inc);
> +}
> +
>  void blake2s_update(struct blake2s_state *state, const u8 *in, size_t inlen)
>  {
> -       __blake2s_update(state, in, inlen, blake2s_compress);
> +       __blake2s_update(state, in, inlen, __blake2s_compress);
>  }
>  EXPORT_SYMBOL(blake2s_update);

Ehm, maybe not. As Jason points out, the typedef does not have quite
the right type, so that is most likely the culprit, and this
workaround would trigger CFI in exactly the same way.

Interestingly, the compiler does not seem to mind, right? Or are you
seeing any build time warnings on the reference to blake2s_compress in
the call to __blake2s_update() ?

WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ardb@kernel.org>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: "Miles Chen (陳民樺)" <miles.chen@mediatek.com>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Linux Crypto Mailing List" <linux-crypto@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	linux-mediatek@lists.infradead.org,
	"Eric Biggers" <ebiggers@google.com>,
	"Sami Tolvanen" <samitolvanen@google.com>
Subject: Re: [PATCH] lib/crypto: blake2s: fix a CFI failure
Date: Wed, 19 Jan 2022 10:13:51 +0100	[thread overview]
Message-ID: <CAMj1kXGUtg1BOauCjxB+S7yMTPArQrPnHf5jnfhOihL-FHrFZA@mail.gmail.com> (raw)
In-Reply-To: <CAMj1kXEuWRUbCqDBnxiWRaERt6OGL8ufQ1Q7naAGHqKK1oQB1w@mail.gmail.com>

On Wed, 19 Jan 2022 at 10:09, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> (+ Sami, Eric)
>
> On Wed, 19 Jan 2022 at 10:00, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >
> > Hi Miles,
> >
> > Thanks for the patch. Could you let me know which architecture and
> > compiler this was broken on? If I had to guess, I'd wager arm32, and
> > you hit this by enabling optimized blake2s?
> >
> > If so, I'm not sure the problem is with weak symbols. Why should CFI
> > break weak symbols? Rather, perhaps the issue is that the function is
> > defined in blake2s-core.S? Are there some CFI macros we need for that
> > definition?
> >
>
> We should try to understand why CFI thinks the prototypes of the two
> symbols are different. There are still a number of issues with CFI, so
> papering over them by reverting stuff that we want for good reasons is
> not the way to go imo.
>
> In the short term, you can work around it by avoiding the indirect
> call to blake2s_compress, e.g.,
>
> diff --git a/lib/crypto/blake2s.c b/lib/crypto/blake2s.c
> index 93f2ae051370..fef2ff678431 100644
> --- a/lib/crypto/blake2s.c
> +++ b/lib/crypto/blake2s.c
> @@ -16,9 +16,15 @@
>  #include <linux/init.h>
>  #include <linux/bug.h>
>
> +static void __blake2s_compress(struct blake2s_state *state, const u8 *block,
> +                              size_t nblocks, const u32 inc)
> +{
> +       return blake2s_compress(state, block, nblocks, inc);
> +}
> +
>  void blake2s_update(struct blake2s_state *state, const u8 *in, size_t inlen)
>  {
> -       __blake2s_update(state, in, inlen, blake2s_compress);
> +       __blake2s_update(state, in, inlen, __blake2s_compress);
>  }
>  EXPORT_SYMBOL(blake2s_update);

Ehm, maybe not. As Jason points out, the typedef does not have quite
the right type, so that is most likely the culprit, and this
workaround would trigger CFI in exactly the same way.

Interestingly, the compiler does not seem to mind, right? Or are you
seeing any build time warnings on the reference to blake2s_compress in
the call to __blake2s_update() ?

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ardb@kernel.org>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: "Miles Chen (陳民樺)" <miles.chen@mediatek.com>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Linux Crypto Mailing List" <linux-crypto@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	linux-mediatek@lists.infradead.org,
	"Eric Biggers" <ebiggers@google.com>,
	"Sami Tolvanen" <samitolvanen@google.com>
Subject: Re: [PATCH] lib/crypto: blake2s: fix a CFI failure
Date: Wed, 19 Jan 2022 10:13:51 +0100	[thread overview]
Message-ID: <CAMj1kXGUtg1BOauCjxB+S7yMTPArQrPnHf5jnfhOihL-FHrFZA@mail.gmail.com> (raw)
In-Reply-To: <CAMj1kXEuWRUbCqDBnxiWRaERt6OGL8ufQ1Q7naAGHqKK1oQB1w@mail.gmail.com>

On Wed, 19 Jan 2022 at 10:09, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> (+ Sami, Eric)
>
> On Wed, 19 Jan 2022 at 10:00, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >
> > Hi Miles,
> >
> > Thanks for the patch. Could you let me know which architecture and
> > compiler this was broken on? If I had to guess, I'd wager arm32, and
> > you hit this by enabling optimized blake2s?
> >
> > If so, I'm not sure the problem is with weak symbols. Why should CFI
> > break weak symbols? Rather, perhaps the issue is that the function is
> > defined in blake2s-core.S? Are there some CFI macros we need for that
> > definition?
> >
>
> We should try to understand why CFI thinks the prototypes of the two
> symbols are different. There are still a number of issues with CFI, so
> papering over them by reverting stuff that we want for good reasons is
> not the way to go imo.
>
> In the short term, you can work around it by avoiding the indirect
> call to blake2s_compress, e.g.,
>
> diff --git a/lib/crypto/blake2s.c b/lib/crypto/blake2s.c
> index 93f2ae051370..fef2ff678431 100644
> --- a/lib/crypto/blake2s.c
> +++ b/lib/crypto/blake2s.c
> @@ -16,9 +16,15 @@
>  #include <linux/init.h>
>  #include <linux/bug.h>
>
> +static void __blake2s_compress(struct blake2s_state *state, const u8 *block,
> +                              size_t nblocks, const u32 inc)
> +{
> +       return blake2s_compress(state, block, nblocks, inc);
> +}
> +
>  void blake2s_update(struct blake2s_state *state, const u8 *in, size_t inlen)
>  {
> -       __blake2s_update(state, in, inlen, blake2s_compress);
> +       __blake2s_update(state, in, inlen, __blake2s_compress);
>  }
>  EXPORT_SYMBOL(blake2s_update);

Ehm, maybe not. As Jason points out, the typedef does not have quite
the right type, so that is most likely the culprit, and this
workaround would trigger CFI in exactly the same way.

Interestingly, the compiler does not seem to mind, right? Or are you
seeing any build time warnings on the reference to blake2s_compress in
the call to __blake2s_update() ?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-01-19  9:14 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-19  8:24 [PATCH] lib/crypto: blake2s: fix a CFI failure miles.chen
2022-01-19  8:24 ` miles.chen
2022-01-19  8:24 ` miles.chen
2022-01-19  9:00 ` Jason A. Donenfeld
2022-01-19  9:00   ` Jason A. Donenfeld
2022-01-19  9:00   ` Jason A. Donenfeld
2022-01-19  9:09   ` Jason A. Donenfeld
2022-01-19  9:09     ` Jason A. Donenfeld
2022-01-19  9:09     ` Jason A. Donenfeld
2022-01-19  9:16     ` Miles Chen
2022-01-19  9:16       ` Miles Chen
2022-01-19  9:16       ` Miles Chen
2022-01-19  9:09   ` Ard Biesheuvel
2022-01-19  9:09     ` Ard Biesheuvel
2022-01-19  9:09     ` Ard Biesheuvel
2022-01-19  9:13     ` Ard Biesheuvel [this message]
2022-01-19  9:13       ` Ard Biesheuvel
2022-01-19  9:13       ` Ard Biesheuvel
2022-01-19  9:43       ` Miles Chen
2022-01-19  9:43         ` Miles Chen
2022-01-19  9:43         ` Miles Chen
2022-01-19 10:10     ` Miles Chen
2022-01-19 10:10       ` Miles Chen
2022-01-19 10:10       ` Miles Chen
2022-01-19  9:24   ` Miles Chen
2022-01-19  9:24     ` Miles Chen
2022-01-19  9:24     ` Miles Chen
2022-01-19  9:55     ` Jason A. Donenfeld
2022-01-19  9:55       ` Jason A. Donenfeld
2022-01-19  9:55       ` Jason A. Donenfeld
2022-01-19 10:06       ` Miles Chen
2022-01-19 10:06         ` Miles Chen
2022-01-19 10:06         ` Miles Chen
2022-01-19 10:11         ` Jason A. Donenfeld
2022-01-19 10:11           ` Jason A. Donenfeld
2022-01-19 10:11           ` Jason A. Donenfeld
2022-01-19 10:56           ` Jason A. Donenfeld
2022-01-19 10:56             ` Jason A. Donenfeld
2022-01-19 10:56             ` Jason A. Donenfeld
2022-01-19 12:14             ` Jason A. Donenfeld
2022-01-19 12:14               ` Jason A. Donenfeld
2022-01-19 12:14               ` Jason A. Donenfeld
2022-01-19 12:18               ` Ard Biesheuvel
2022-01-19 12:18                 ` Ard Biesheuvel
2022-01-19 12:18                 ` Ard Biesheuvel
2022-01-19 13:34                 ` Jason A. Donenfeld
2022-01-19 13:34                   ` Jason A. Donenfeld
2022-01-19 13:34                   ` Jason A. Donenfeld
2022-01-19 13:54                   ` [PATCH] lib/crypto: blake2s: avoid indirect calls to compression function for Clang CFI Jason A. Donenfeld
2022-01-19 13:54                     ` Jason A. Donenfeld
2022-01-19 13:54                     ` Jason A. Donenfeld
2022-01-19 14:46                     ` Miles Chen
2022-01-19 14:46                       ` Miles Chen
2022-01-19 14:46                       ` Miles Chen
2022-01-19 22:24                     ` Nathan Chancellor
2022-01-19 22:24                       ` Nathan Chancellor
2022-01-19 22:24                       ` Nathan Chancellor
2022-01-20  9:44                       ` Jason A. Donenfeld
2022-01-20  9:44                         ` Jason A. Donenfeld
2022-01-20  9:44                         ` Jason A. Donenfeld
2022-01-21 19:54                     ` Eric Biggers
2022-01-21 19:54                       ` Eric Biggers
2022-01-21 19:54                       ` Eric Biggers
2022-01-21 20:22                       ` Jason A. Donenfeld
2022-01-21 20:22                         ` Jason A. Donenfeld
2022-01-21 20:22                         ` Jason A. Donenfeld
2022-01-21 20:51                         ` Sami Tolvanen
2022-01-21 20:51                           ` Sami Tolvanen
2022-01-21 20:51                           ` Sami Tolvanen
2022-01-24 19:28                     ` [PATCH v2] " Jason A. Donenfeld
2022-01-24 19:28                       ` Jason A. Donenfeld
2022-01-24 19:59                       ` Nick Desaulniers
2022-01-24 19:59                         ` Nick Desaulniers
2022-01-25  6:40                       ` Eric Biggers
2022-01-25  6:40                         ` Eric Biggers
2022-01-25 12:23                         ` Jason A. Donenfeld
2022-01-25 12:23                           ` Jason A. Donenfeld
2022-01-26 22:54                           ` Eric Biggers
2022-01-26 22:54                             ` Eric Biggers
2022-01-26 22:51                     ` [PATCH] " John Stultz
2022-01-26 22:51                       ` John Stultz
2022-01-26 22:51                       ` John Stultz
2022-01-19 14:40                 ` [PATCH] lib/crypto: blake2s: fix a CFI failure David Laight
2022-01-19 14:40                   ` David Laight
2022-01-19 14:40                   ` David Laight
2022-01-19 15:03                   ` Jason A. Donenfeld
2022-01-19 15:03                     ` Jason A. Donenfeld
2022-01-19 15:03                     ` Jason A. Donenfeld
2022-01-19 12:34             ` Miles Chen
2022-01-19 12:34               ` Miles Chen
2022-01-19 12:34               ` Miles Chen
2022-01-19 10:13         ` Ard Biesheuvel
2022-01-19 10:13           ` Ard Biesheuvel
2022-01-19 10:13           ` Ard Biesheuvel
2022-01-19 10:20           ` Jason A. Donenfeld
2022-01-19 10:20             ` Jason A. Donenfeld
2022-01-19 10:20             ` Jason A. Donenfeld
2022-01-19 10:35             ` Ard Biesheuvel
2022-01-19 10:35               ` Ard Biesheuvel
2022-01-19 10:35               ` Ard Biesheuvel

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=CAMj1kXGUtg1BOauCjxB+S7yMTPArQrPnHf5jnfhOihL-FHrFZA@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=Jason@zx2c4.com \
    --cc=davem@davemloft.net \
    --cc=ebiggers@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=miles.chen@mediatek.com \
    --cc=samitolvanen@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.