linux-kernel - Re: [PATCH] x86/calgary: fix bitcast type warnings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAG48ez13xg1oUiO_pyDHVbJkWRQdW4CoX7uGzoujyf4L6VB-dw@mail.gmail.com>
Date:   Fri, 29 Mar 2019 22:19:03 +0100
From:   Jann Horn <jannh@...gle.com>
To:     Mukesh Ojha <mojha@...eaurora.org>,
        Logan Gunthorpe <logang@...tatee.com>,
        Horia Geantă <horia.geanta@....com>
Cc:     Muli Ben-Yehuda <mulix@...ix.org>, Jon Mason <jdmason@...zu.us>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        iommu@...ts.linux-foundation.org,
        kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/calgary: fix bitcast type warnings

+Logan Gunthorpe and Horia Geantă, since they've written a bunch of this code

On Fri, Mar 29, 2019 at 5:48 PM Jann Horn <jannh@...gle.com> wrote:
> On Fri, Mar 29, 2019 at 9:19 AM Mukesh Ojha <mojha@...eaurora.org> wrote:
> > On 3/29/2019 4:29 AM, Jann Horn wrote:
> > > The sparse checker attempts to ensure that all conversions between
> > > fixed-endianness numbers and numbers with native endianness are explicit.
> > > However, the calgary code reads and writes big-endian numbers from/to IO
> > > memory using {read,write}{l,q}(), which return native-endian numbers.
> > >
> > > This could be addressed by putting __force casts all over the place, but
> > > that would kind of defeat the point of the warning. Instead, create new
> > > helpers {read,write}{l,q}_be() for big-endian IO that convert from/to
> > > native endianness.
> > >
> > > Most of this patch is a straightforward conversion; the following parts
> > > aren't just mechanical replacement:
> > >
> > >   - ->tar_val is now a native-endian number instead of big-endian
> > >   - calioc2_handle_quirks() did `cpu_to_be32(readl(target))` when it
> > >     intended to do `be32_to_cpu(readl(target))` (but that has no actual
> > >     effects outside of type warnings)
> > >
> > > This gets rid of 108 lines of sparse warnings.
> > >
> > > Signed-off-by: Jann Horn <jannh@...gle.com>
> > > ---
> > > compile-tested only
> > >
> > >   arch/x86/kernel/pci-calgary_64.c | 108 ++++++++++++++++++-------------
> > >   1 file changed, 64 insertions(+), 44 deletions(-)
> > >
> > > diff --git a/arch/x86/kernel/pci-calgary_64.c b/arch/x86/kernel/pci-calgary_64.c
> > > index c70720f61a34..36cd66d940fb 100644
> > > --- a/arch/x86/kernel/pci-calgary_64.c
> > > +++ b/arch/x86/kernel/pci-calgary_64.c
> > > @@ -534,6 +534,26 @@ static inline int is_cal_pci_dev(unsigned short device)
> > >       return (is_calgary(device) || is_calioc2(device));
> > >   }
> >
> >
> > Can the existing api's not be used here like iowrite64be/ioread64be/ or
> > similar variant in "include/asm-generic/io.h"
>
> Oooh! I didn't realize that those exist. I'll change that and send a v2.

Actually, that doesn't work at the moment on x86-64:

include/asm-generic/io.h only defines these things if
CONFIG_GENERIC_IOMAP isn't defined; and X86 unconditionally defines
it. With CONFIG_GENERIC_IOMAP set, these functions are provided by
include/asm-generic/iomap.h.

include/asm-generic/iomap.h has extern definitions of them:

extern unsigned int ioread8(void __iomem *);
extern unsigned int ioread16(void __iomem *);
extern unsigned int ioread16be(void __iomem *);
extern unsigned int ioread32(void __iomem *);
extern unsigned int ioread32be(void __iomem *);
#ifdef CONFIG_64BIT
extern u64 ioread64(void __iomem *);
extern u64 ioread64be(void __iomem *);
#endif
[...]
extern void iowrite8(u8, void __iomem *);
extern void iowrite16(u16, void __iomem *);
extern void iowrite16be(u16, void __iomem *);
extern void iowrite32(u32, void __iomem *);
extern void iowrite32be(u32, void __iomem *);
#ifdef CONFIG_64BIT
extern void iowrite64(u64, void __iomem *);
extern void iowrite64be(u64, void __iomem *);
#endif

The definitions for these are in lib/iomap.c, except that there are no
definitions for ioread64be() and iowrite64be(); if you try to use
them, you get linker errors.

I guess maybe the fix for that would be to, in iomap.c, just implement
iowrite64{,be} the same way as iowrite32{,be}, just under a "#ifdef
CONFIG_64BIT"?