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>] [day] [month] [year] [list]
Date:   Mon, 29 Oct 2018 13:57:59 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     peng.hao2@....com.cn
Cc:     Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andy Shevchenko <andy@...radead.org>,
        Darren Hart <dvhart@...radead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        hutao@...fujitsu.com,
        Linux Documentation List <linux-doc@...r.kernel.org>
Subject: Re: [PATCH V3 3/5] misc/pvpanic: add MMIO support

On Mon, Oct 29, 2018 at 12:54 PM <peng.hao2@....com.cn> wrote:
>
> >On Mon, Oct 29, 2018 at 5:22 AM Peng Hao <peng.hao2@....com.cn> wrote:
> >>
> >> On some architectures (e.g. arm64), it's preferable to use MMIO, since
> >> this can be used standalone. Add MMIO support to the pvpanic driver.
> >
> >>  pvpanic_walk_resources(struct acpi_resource *res, void *context)
> >>  {
> >> +       struct acpi_resource_fixed_memory32 *fixmem32;
> >> +
> >>         switch (res->type) {
> >>         case ACPI_RESOURCE_TYPE_END_TAG:
> >>                 return AE_OK;
> >>
> >>         case ACPI_RESOURCE_TYPE_IO:
> >> -               port = res->data.io.minimum;
> >> +               base = (void __iomem *) ioport_map(res->data.io.minimum, 1);
> >> +               return AE_OK;
> >> +
> >> +       case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
> >> +               fixmem32 = &res->data.fixed_memory32;
> >> +               base = ioremap(fixmem32->address, fixmem32->address_length);
> >>                 return AE_OK;
> >
> >Ouch. Sorry, I forgot to look at this previously.
> >
> >This should be converted to use
> >acpi_dev_resource_io()
> >acpi_dev_resource_memory()
> >
> another question, here:
> iounmap(base) and base may be a ioport. I read x86 code for iounmap that  checked the base.
> so I think it is safe for x86. But I'm not sure if other architectures using ioport are also secure
> in the same way of processing.
> Do you have any suggestions?

I would consider it as a bug if on some architectures iounmap() is not
able to take a base got from ioport_map().

-- 
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ