linux-kernel - Re: [PATCH v9 07/38] x86/mm: Remove phys_to

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: <CAMzpN2gZHis6_Y_B+DQmuY_ojBqoGBTCd2go+sM53pPaScTq+g@mail.gmail.com>
Date:   Tue, 11 Jul 2017 08:00:32 -0400
From:   Brian Gerst <brgerst@...il.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Tom Lendacky <thomas.lendacky@....com>,
        linux-arch <linux-arch@...r.kernel.org>,
        linux-efi@...r.kernel.org, kvm@...r.kernel.org,
        linux-doc@...r.kernel.org,
        "the arch/x86 maintainers" <x86@...nel.org>,
        kexec@...ts.infradead.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kasan-dev <kasan-dev@...glegroups.com>, xen-devel@...ts.xen.org,
        Linux-MM <linux-mm@...ck.org>,
        "open list:IOMMU DRIVERS" <iommu@...ts.linux-foundation.org>,
        Brijesh Singh <brijesh.singh@....com>,
        Toshimitsu Kani <toshi.kani@....com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        Alexander Potapenko <glider@...gle.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Larry Woodman <lwoodman@...hat.com>,
        Jonathan Corbet <corbet@....net>,
        Joerg Roedel <joro@...tes.org>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Ingo Molnar <mingo@...hat.com>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Dave Young <dyoung@...hat.com>, Rik van Riel <riel@...hat.com>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        Borislav Petkov <bp@...en8.de>,
        Andy Lutomirski <luto@...nel.org>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Juergen Gross <jgross@...e.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

On Tue, Jul 11, 2017 at 4:35 AM, Arnd Bergmann <arnd@...db.de> wrote:
> On Tue, Jul 11, 2017 at 6:58 AM, Brian Gerst <brgerst@...il.com> wrote:
>> On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky <thomas.lendacky@....com> wrote:
>>> On 7/8/2017 7:57 AM, Brian Gerst wrote:
>>>> On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky <thomas.lendacky@....com>
>>>
>>> I originally had a check for SME here in a previous version of the
>>> patch.  Thomas Gleixner recommended removing the check so that the code
>>> path was always exercised regardless of the state of SME in order to
>>> better detect issues:
>>>
>>> http://marc.info/?l=linux-kernel&m=149803067811436&w=2
>>
>> Looking a bit closer, this shortcut doesn't set the caching
>> attributes.  So it's probably best to get rid of it anyways.  Also
>> note, there is a corresponding check in iounmap().

Perhaps the iounmap() check should be kept for now for safety, since
some drivers (vga16fb for example) call iounmap() blindly even if the
mapping wasn't returned from ioremap().  Maybe add a warning when an
ISA address is passed to iounmap().

> Could that cause regressions if a driver relies on (write-through)
> cacheable access to the VGA frame buffer RAM or an read-only
> cached access to an option ROM but now gets uncached access?

Yes there could be some surprises in drivers use the normal ioremap()
call which is uncached but were expecting the default write-through
mapping.

> I also tried to find out whether we can stop mapping the ISA MMIO
> area into the linear mapping, but at least the VGA code uses
> VGA_MAP_MEM() to get access to the same pointers. I'm pretty
> sure this got copied incorrectly into most other architectures, but
> it is definitely still used on x86 with vga16fb/vgacon/mdacon.

Changing VGA_MAP_MEM() to use ioremap_wt() would take care of that.
Although, looking at the mdacon/vgacon, they don't have support for
unmapping the frame buffer if they are built modular.

--
Brian Gerst