Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
To:     Julius Werner <jwerner@chromium.org>
From:   Stephen Boyd <swboyd@chromium.org>
In-Reply-To: <CAODwPW8eg2WOh9-Raeb8Q65E-5D7RDheDU8e+H68FHGa0MS37A@mail.gmail.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Wei-Ning Huang <wnhuang@chromium.org>,
        Julius Werner <jwerner@chromium.org>,
        Brian Norris <briannorris@chromium.org>, samuel@sholland.org
References: <20180809171722.144325-1-swboyd@chromium.org>
 <20180809171722.144325-8-swboyd@chromium.org>
 <CAODwPW8eg2WOh9-Raeb8Q65E-5D7RDheDU8e+H68FHGa0MS37A@mail.gmail.com>
Message-ID: <153385579866.220756.16086660810932774163@swboyd.mtv.corp.google.com>
User-Agent: alot/0.7
Subject: Re: [PATCH v3 7/7] firmware: coreboot: Request table region for exclusive
 access
Date:   Thu, 09 Aug 2018 16:03:18 -0700
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Quoting Julius Werner (2018-08-09 14:07:31)
> On Thu, Aug 9, 2018 at 10:17 AM Stephen Boyd <swboyd@chromium.org> wrote:
> >
> > Call request_mem_region() on the entire coreboot table to make sure
> > other devices don't attempt to map the coreboot table in their drivers.
> > If drivers need that support, it would be better to provide bus APIs
> > they can use to do that through the mapping created in this file.
> >
> =

> Does this prevent userspace from mapping this region via /dev/mem? If
> so, let's please not do it to not break compatibility with existing
> tools.

No it doesn't break. I can still read the memory here with /dev/mem (and
cbmem). But that seems to be because of a couple reasons. First, I have
CONFIG_STRICT_DEVMEM=3Dy but CONFIG_IO_STRICT_DEVMEM=3Dn. This allows me to
map memory that isn't system ram. If CONFIG_IO_STRICT_DEVMEM=3Dy then
mapping this I/O region through /dev/mem here would be denied .
Furthermore, I see that my system RAM excludes this coreboot table so it
doesn't fall into the bucket that CONFIG_STRICT_DEVMEM would find.

> (I guess an alternative would be to rewrite 'cbmem' to use
> /sys/bus/coreboot/devices if available to get its coreboot table
> information. But we'd still need to maintain the old path for
> backwards compatibility anyway, so that would really just make it more
> complicated.)

This sounds like a good idea. Userspace reaching into /dev/mem is not
good from a kernel hardening perspective. That's why those strict devmem
configs exist. Can cbmem be updated to query information from device
drivers instead, so that we can enable CONFIG_IO_STRICT_DEVMEM as well?