All of lore.kernel.org
 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.

WARNING: multiple messages have this Message-ID (diff)
From: Jon Masters <jcm@redhat.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: 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: 16+ 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:12 ` Jon Masters
2015-01-17 20:59 ` Ard Biesheuvel
2015-01-17 20:59   ` Ard Biesheuvel
2015-01-17 21:01   ` Jon Masters [this message]
2015-01-17 21:01     ` Jon Masters
2015-01-17 21:10 ` Olof Johansson
2015-01-17 21:10   ` Olof Johansson
2015-01-17 22:52   ` Jon Masters
2015-01-17 22:52     ` Jon Masters
2015-01-17 22:56     ` Jon Masters
2015-01-17 22:56       ` Jon Masters
2015-01-17 23:21 ` Leif Lindholm
2015-01-17 23:21   ` Leif Lindholm
2015-01-18  0:49   ` Jon Masters
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.