linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jcm@redhat.com (Jon Masters)
To: linux-arm-kernel@lists.infradead.org
Subject: SMBIOS/DMI data under CONFIG_STRICT_DEVMEM
Date: Sat, 17 Jan 2015 16:01:17 -0500	[thread overview]
Message-ID: <54BACD9D.3080505@redhat.com> (raw)
In-Reply-To: <CAKv+Gu_kZ+b8CBbiWLW3KW5Nw7qewpN7+N6a910dFaiRcs1xKQ@mail.gmail.com>

On 01/17/2015 03:59 PM, Ard Biesheuvel wrote:
> On 17 January 2015 at 20:12, Jon Masters <jcm@redhat.com> wrote:
>> Hi Catalin, all,
>>
>> I would like to ensure that the SMBIOS data provided by firmware is
>> always readable from userspace on AArch64, through /dev/mem.
>>
> 
> This has been on our radar for a while
> 
>> When building a kernel with CONFIG_STRICT_DEVMEM, arm64 follows broadly
>> x86 with the exception of an assumption surrounding the low range of
>> memory (which doesn't apply on AArch64 platforms universally anyway).
>> Thus on x86, they can directly read the SMBIOS table from dmidecode when
>> it tries to map /dev/mem due to its location. I'm hacking something up
>> for the moment, but I would like to solve this.
>>
> 
> Check out my series here
> http://article.gmane.org/gmane.linux.kernel.efi/5133
> 
> The general idea is to remove all UEFI runtime regions (including
> config tables) from the linear mapping, and allow r/o access via
> /dev/mem to such regions, using a mapping type which can support
> unaligned access (which is required for SMBIOS). As for the iomem
> resources, we need to reserve the regions we know are in use,
> regardless of how that affects the existing logic around
> devmem_is_allowed (and I am sure we can do better than what
> page_is_ram currently does, which is matching the string 'System RAM'
> against the iomem resource table)

Ah. So you have it in hand. Great. We'll go with a temporary workaround
and wait for your series for the fix. Will take a look and review.

Jon.

  reply	other threads:[~2015-01-17 21:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-17 20:12 SMBIOS/DMI data under CONFIG_STRICT_DEVMEM Jon Masters
2015-01-17 20:59 ` Ard Biesheuvel
2015-01-17 21:01   ` Jon Masters [this message]
2015-01-17 21:10 ` Olof Johansson
2015-01-17 22:52   ` Jon Masters
2015-01-17 22:56     ` Jon Masters
2015-01-17 23:21 ` Leif Lindholm
2015-01-18  0:49   ` Jon Masters

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=54BACD9D.3080505@redhat.com \
    --to=jcm@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.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).