linux-kernel - Re: [PATCH v3 7/7] firmware: coreboot: Request table region for exclusive access

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] [day] [month] [year] [list]

Message-ID: <153394348544.37448.7231279350981818561@swboyd.mtv.corp.google.com>
Date:   Fri, 10 Aug 2018 16:24:45 -0700
From:   Stephen Boyd <swboyd@...omium.org>
To:     Julius Werner <jwerner@...omium.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Wei-Ning Huang <wnhuang@...omium.org>,
        Brian Norris <briannorris@...omium.org>, samuel@...lland.org
Subject: Re: [PATCH v3 7/7] firmware: coreboot: Request table region for exclusive
 access

Quoting Stephen Boyd (2018-08-09 19:54:27)
> What's with the top posting? ;-)
> 
> Quoting Julius Werner (2018-08-09 16:44:43)
> > Actually, looking at what IO_STRICT_DEVMEM really does, would it
> > really prevent userspace accesses to these areas? Because it seems
> > that it only prevents accesses to areas marked as IORESOURCE_BUSY, and
> > while I can't fully follow how the kernel assigns that, comments
> > suggest that this is only set when "Driver has marked this resource
> > busy".
> 
> Requesting the memory region as is done in this patch marks it as busy.
> 
> > 
> > So after you make the change to the other patch where we immediately
> > unmap the coreboot table again at the end of the probe() function,
> > shouldn't it become available to userspace again even with
> > IO_STRICT_DEVMEM set?
> 
> Yes, if we unmap the region immediately after devices are populated then
> this whole point is moot with the assumption that this code isn't
> running at the same time as the cbmem utility. I've done this already
> and it is working on arm. I still need to build/boot/test on an x86
> platform which I should be able to do tomorrow.
> 

I tried my latest version of the patches (unplubished so far) and those
work on x86 with cbmem. So things look good and we don't need to keep
the mapping around.