All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: linux-4.4-rc8/arch/arm64/kernel/module.c:78: 32/64 bit problem ?
Date: Mon, 4 Jan 2016 15:28:41 +0000	[thread overview]
Message-ID: <20160104152841.GG1616@arm.com> (raw)
In-Reply-To: <CAKv+Gu9Ve6=1evFD4V2jtOCHOEqOzhmud=guioVR5NMrc=HPBw@mail.gmail.com>

On Mon, Jan 04, 2016 at 04:24:49PM +0100, Ard Biesheuvel wrote:
> On 4 January 2016 at 15:32, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > On 4 January 2016 at 15:16, Will Deacon <will.deacon@arm.com> wrote:
> >> On Mon, Jan 04, 2016 at 08:25:30AM +0000, David Binderman wrote:
> >>> Hello there,
> >>
> >> Hi David,
> >>
> >>> [linux-4.4-rc8/arch/arm64/kernel/module.c:78] ->
> >>> [linux-4.4-rc8/arch/arm64/kernel/module.c:88]: (warning) Shifting 32-bit
> >>> value by 64 bits is undefined behaviour. See condition at line 88.
> >>
> >> Curious, but how are you seeing this warning? GCC is silent for me...
> >>
> >>> Source code is
> >>>
> >>>     u64 imm_mask = (1 << len) - 1;
> >>>     s64 sval = do_reloc(op, place, val);
> >>>
> >>>     switch (len) {
> >>>     case 16:
> >>>         *(s16 *)place = sval;
> >>>         break;
> >>>     case 32:
> >>>         *(s32 *)place = sval;
> >>>         break;
> >>>     case 64:
> >>>
> >>> So it seems that len can be 64. Suggest new code
> >>>
> >>>     u64 imm_mask = (1UL << len) - 1;
> >>
> >> That still ends up shifting by the width of the type when len == 64,
> >> which is potentially still broken. We're better off using GENMASK.
> >>
> >
> > Can't we simply return from the function rather than break from the
> > switch statement if len == 64?
> > The range check does not make any sense in that case anyway.
> >
> 
> Or perhaps:
> 
> ------------8<-----------------
> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
> index f4bc779e62e8..fd1f4e678655 100644
> --- a/arch/arm64/kernel/module.c
> +++ b/arch/arm64/kernel/module.c
> @@ -75,14 +75,17 @@ static u64 do_reloc(enum aarch64_reloc_op
> reloc_op, void *place, u64 val)
> 
>  static int reloc_data(enum aarch64_reloc_op op, void *place, u64 val, int len)
>  {
> -       u64 imm_mask = (1 << len) - 1;
>         s64 sval = do_reloc(op, place, val);
> 
>         switch (len) {
>         case 16:
> +               if (sval < S16_MIN || sval > U16_MAX)
> +                       return -ERANGE;
>                 *(s16 *)place = sval;

Doesn't this break ABS relocs, which are allowed to overflow?

Will

  reply	other threads:[~2016-01-04 15:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-04  8:25 linux-4.4-rc8/arch/arm64/kernel/module.c:78: 32/64 bit problem ? David Binderman
2016-01-04 14:16 ` Will Deacon
2016-01-04 14:32   ` Ard Biesheuvel
2016-01-04 15:24     ` Ard Biesheuvel
2016-01-04 15:28       ` Will Deacon [this message]
2016-01-04 15:30         ` Will Deacon
2016-01-04 15:14   ` David Binderman

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=20160104152841.GG1616@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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 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.