linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <swboyd@chromium.org>
To: Julius Werner <jwerner@chromium.org>
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
Subject: Re: [PATCH v3 7/7] firmware: coreboot: Request table region for exclusive access
Date: Thu, 09 Aug 2018 16:03:18 -0700	[thread overview]
Message-ID: <153385579866.220756.16086660810932774163@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <CAODwPW8eg2WOh9-Raeb8Q65E-5D7RDheDU8e+H68FHGa0MS37A@mail.gmail.com>

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=y but CONFIG_IO_STRICT_DEVMEM=n. This allows me to
map memory that isn't system ram. If CONFIG_IO_STRICT_DEVMEM=y 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?


  reply	other threads:[~2018-08-09 23:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-09 17:17 [PATCH v3 0/7] firmware: coreboot: Fix probe and simplify code Stephen Boyd
2018-08-09 17:17 ` [PATCH v3 1/7] firmware: coreboot: Let OF core populate platform device Stephen Boyd
2018-08-09 17:31   ` Brian Norris
2018-08-09 17:17 ` [PATCH v3 2/7] firmware: coreboot: Unmap ioregion on failure Stephen Boyd
2018-08-09 17:49   ` Brian Norris
2018-08-09 19:40     ` Stephen Boyd
2018-08-09 19:52       ` Brian Norris
2018-08-09 23:25         ` Stephen Boyd
2018-08-09 17:17 ` [PATCH v3 3/7] firmware: coreboot: Make bus registration symmetric Stephen Boyd
2018-08-09 18:10   ` Julius Werner
2018-08-09 23:30     ` Stephen Boyd
2018-08-09 17:17 ` [PATCH v3 4/7] firmware: coreboot: Collapse platform drivers into bus core Stephen Boyd
2018-08-09 17:17 ` [PATCH v3 5/7] firmware: coreboot: Remap RAM with memremap() instead of ioremap() Stephen Boyd
2018-08-09 18:24   ` Julius Werner
2018-08-09 22:07     ` Stephen Boyd
2018-08-09 17:17 ` [PATCH v3 6/7] firmware: coreboot: Only populate devices in coreboot_table_init() Stephen Boyd
2018-08-09 21:02   ` Julius Werner
2018-08-09 23:43     ` Stephen Boyd
2018-08-09 17:17 ` [PATCH v3 7/7] firmware: coreboot: Request table region for exclusive access Stephen Boyd
2018-08-09 21:07   ` Julius Werner
2018-08-09 23:03     ` Stephen Boyd [this message]
2018-08-09 23:37       ` Julius Werner
2018-08-09 23:44         ` Julius Werner
2018-08-10  2:54           ` Stephen Boyd
2018-08-10 23:24             ` Stephen Boyd
2018-08-09 18:03 ` [PATCH v3 0/7] firmware: coreboot: Fix probe and simplify code Brian Norris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=153385579866.220756.16086660810932774163@swboyd.mtv.corp.google.com \
    --to=swboyd@chromium.org \
    --cc=briannorris@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jwerner@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=samuel@sholland.org \
    --cc=wnhuang@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).