From: ebiederm@xmission.com (Eric W. Biederman)
To: Ed Swierk <eswierk@skyportsystems.com>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
Stefan Berger <stefanb@us.ibm.com>
Subject: Re: [PATCH v9 0/5] tpm: Command duration logging and chip-specific override
Date: Wed, 13 Jul 2016 15:58:35 -0500 [thread overview]
Message-ID: <8760s9l0g4.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <CAO_EM_=9ON4vAxOCvUJ3Z+pic_An6wkriZrh4csZ_0DibHSQYQ@mail.gmail.com> (Ed Swierk's message of "Wed, 13 Jul 2016 13:00:28 -0700")
Ed Swierk <eswierk@skyportsystems.com> writes:
> On Wed, Jul 13, 2016 at 10:36 AM, Jason Gunthorpe
> <jgunthorpe@obsidianresearch.com> wrote:
>> I think your bios is broken?
>
> The BIOS is broken in many ways. I already have to pass
> memmap=256M$0x80000000, otherwise PCIe extended config space
> (MMCONFIG) is inaccessible. Also I found memmap=0x7000$0x7a7d0000
> works around "APEI: Can not request [mem 0x7a7d0018-0x7a7d0067] for
> APEI ERST registers", as the BIOS seems to be mistakenly reserving
> 0x7b7d0000-7b7d7000 instead.
>
>> A working BIOS will look like this:
>>
>> $ cat /proc/iomem | grep -i fed400
>> fed40000-fed44fff : pnp 00:00
>>
>> It sets aside the struct resource during pnp:
>>
>> [ 0.097318] pnp: PnP ACPI init
>> [ 0.097366] system 00:00: [mem 0xfed40000-0xfed44fff] has been reserved
>>
>> What did your system do?
>>
>> You should see prints like this:
>>
>> printk(KERN_DEBUG
>> "e820: reserve RAM buffer [mem %#010llx-%#010llx]\n",
>> start, end);
>>
>> Which only happen if E820_RAM is set, which is certainly not right for
>> TPM memory.
>
> On my system I see
>
> e820: reserve RAM buffer [mem 0x0009b000-0x0009ffff]
> e820: reserve RAM buffer [mem 0x75b02000-0x77ffffff]
> e820: reserve RAM buffer [mem 0x7a1f6000-0x7bffffff]
> e820: reserve RAM buffer [mem 0x7b800000-0x7bffffff]
> e820: reserve RAM buffer [mem 0xfed30000-0xffffffff]
> e820: reserve RAM buffer [mem 0x505deb000-0x507ffffff]
>
> which doesn't make a whole lot of sense, as several of those areas
> overlap each other, never mind devices.
>
>> I don't know what kernel convention is to handle these sorts of
>> defects?
>>
>> Is the use of the memmap kernel command line an appropriate work
>> around?
>
> It works for me, though I would like to know if there's another
> approach.
There is always poke your BIOS vendor until they deliver code that is
not so b0rked it can not be used.
You can also add a quirk based on the BIOS's mainboard identification
string that fixes up the data provided by the BIOS. I remember a fair
number of those dealing with reboot behavior and the like.
Eric
next prev parent reply other threads:[~2016-07-13 21:11 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-08 0:45 [PATCH v4 0/4] tpm: Command duration logging and chip-specific override Ed Swierk
2016-06-08 0:45 ` [PATCH v4 1/4] tpm_tis: Improve reporting of IO errors Ed Swierk
2016-06-08 0:45 ` [PATCH v4 2/4] tpm: Add optional logging of TPM command durations Ed Swierk
2016-06-08 0:45 ` [PATCH v4 3/4] tpm: Allow TPM chip drivers to override reported " Ed Swierk
2016-06-08 19:05 ` [tpmdd-devel] " Jason Gunthorpe
2016-06-08 20:41 ` Ed Swierk
2016-06-08 0:45 ` [PATCH v4 4/4] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup Ed Swierk
2016-06-08 23:00 ` [PATCH v5 0/4] tpm: Command duration logging and chip-specific override Ed Swierk
2016-06-08 23:00 ` [PATCH v5 1/4] tpm_tis: Improve reporting of IO errors Ed Swierk
2016-06-08 23:00 ` [PATCH v5 2/4] tpm: Add optional logging of TPM command durations Ed Swierk
2016-06-08 23:00 ` [PATCH v5 3/4] tpm: Allow TPM chip drivers to override reported " Ed Swierk
2016-06-10 12:19 ` Jarkko Sakkinen
2016-06-10 17:34 ` Ed Swierk
2016-06-10 19:42 ` Jarkko Sakkinen
2016-06-11 1:54 ` Ed Swierk
2016-06-08 23:00 ` [PATCH v5 4/4] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup Ed Swierk
2016-06-11 1:55 ` [PATCH v6 0/5] tpm: Command duration logging and chip-specific override Ed Swierk
2016-06-11 1:55 ` [PATCH v6 1/5] tpm_tis: Improve reporting of IO errors Ed Swierk
2016-06-11 1:55 ` [PATCH v6 2/5] tpm: Add optional logging of TPM command durations Ed Swierk
2016-06-11 1:55 ` [PATCH v6 3/5] tpm: Factor out reading of timeout and duration capabilities Ed Swierk
2016-06-16 20:20 ` Jarkko Sakkinen
2016-06-19 12:12 ` Jarkko Sakkinen
2016-06-11 1:55 ` [PATCH v6 4/5] tpm: Allow TPM chip drivers to override reported command durations Ed Swierk
2016-06-16 20:26 ` Jarkko Sakkinen
2016-06-11 1:55 ` [PATCH v6 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup Ed Swierk
2016-06-21 1:53 ` [PATCH v7 0/5] tpm: Command duration logging and chip-specific override Ed Swierk
2016-06-21 1:53 ` [PATCH v7 1/5] tpm_tis: Improve reporting of IO errors Ed Swierk
2016-06-21 1:53 ` [PATCH v7 2/5] tpm: Add optional logging of TPM command durations Ed Swierk
2016-06-21 1:54 ` [PATCH v7 3/5] tpm: Clean up reading of timeout and duration capabilities Ed Swierk
2016-06-21 20:52 ` Jarkko Sakkinen
2016-06-22 0:21 ` Ed Swierk
2016-06-22 10:46 ` Jarkko Sakkinen
2016-06-21 1:54 ` [PATCH v7 4/5] tpm: Allow TPM chip drivers to override reported command durations Ed Swierk
2016-06-21 20:54 ` Jarkko Sakkinen
2016-06-21 1:54 ` [PATCH v7 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup Ed Swierk
2016-06-21 20:55 ` Jarkko Sakkinen
2016-06-22 1:10 ` [PATCH v8 0/5] tpm: Command duration logging and chip-specific override Ed Swierk
2016-06-22 1:10 ` [PATCH v8 1/5] tpm_tis: Improve reporting of IO errors Ed Swierk
2016-06-24 18:25 ` Jason Gunthorpe
2016-06-24 20:21 ` Jarkko Sakkinen
2016-06-24 20:23 ` Jarkko Sakkinen
2016-06-24 20:26 ` Jason Gunthorpe
2016-06-25 15:24 ` Jarkko Sakkinen
2016-06-25 15:47 ` Jarkko Sakkinen
2016-06-27 17:55 ` Jason Gunthorpe
2016-06-22 1:10 ` [PATCH v8 2/5] tpm: Add optional logging of TPM command durations Ed Swierk
2016-06-24 18:27 ` Jason Gunthorpe
2016-06-24 20:24 ` Jarkko Sakkinen
2016-06-22 1:10 ` [PATCH v8 3/5] tpm: Clean up reading of timeout and duration capabilities Ed Swierk
2016-06-22 1:10 ` [PATCH v8 4/5] tpm: Allow TPM chip drivers to override reported command durations Ed Swierk
2016-06-22 1:10 ` [PATCH v8 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup Ed Swierk
2016-07-13 16:19 ` [PATCH v9 0/5] tpm: Command duration logging and chip-specific override Ed Swierk
2016-07-13 16:19 ` [PATCH v9 1/5] tpm_tis: Improve reporting of IO errors Ed Swierk
2016-07-13 16:19 ` [PATCH v9 2/5] tpm: Add optional logging of TPM command durations Ed Swierk
2016-07-13 16:19 ` [PATCH v9 3/5] tpm: Clean up reading of timeout and duration capabilities Ed Swierk
2016-07-18 18:15 ` Jarkko Sakkinen
2016-07-18 18:19 ` Jarkko Sakkinen
2016-07-18 18:20 ` Jarkko Sakkinen
2016-07-13 16:19 ` [PATCH v9 4/5] tpm: Allow TPM chip drivers to override reported command durations Ed Swierk
2016-07-13 17:04 ` kbuild test robot
2016-07-18 18:40 ` Jarkko Sakkinen
2016-07-13 16:19 ` [PATCH v9 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup Ed Swierk
2016-07-13 16:44 ` [PATCH v9 0/5] tpm: Command duration logging and chip-specific override Ed Swierk
2016-07-13 17:36 ` Jason Gunthorpe
2016-07-13 20:00 ` Ed Swierk
2016-07-13 20:58 ` Eric W. Biederman [this message]
2016-07-13 20:59 ` Jason Gunthorpe
2016-07-18 18:07 ` Jarkko Sakkinen
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=8760s9l0g4.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=eswierk@skyportsystems.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jgunthorpe@obsidianresearch.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=stefanb@us.ibm.com \
--cc=tpmdd-devel@lists.sourceforge.net \
/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).