linux-kernel - Re: [PATCH 4/8] ACPI, APEI, Resolve false conflict between ACPI NVS and APEI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAErSpo5pUY8g7U0NeUe+Yf+R8kraExZN3Sheo6h+fb9B+RO7rw@mail.gmail.com>
Date:	Tue, 20 Sep 2011 10:26:49 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Huang Ying <ying.huang@...el.com>
Cc:	Len Brown <lenb@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Luck, Tony" <tony.luck@...el.com>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	Yinghai Lu <yinghai@...nel.org>
Subject: Re: [PATCH 4/8] ACPI, APEI, Resolve false conflict between ACPI NVS
 and APEI

On Mon, Sep 19, 2011 at 8:34 PM, Huang Ying <ying.huang@...el.com> wrote:
> On 09/20/2011 10:09 AM, Bjorn Helgaas wrote:
>> On Mon, Sep 19, 2011 at 7:38 PM, Huang Ying <ying.huang@...el.com> wrote:
>>> Some firmware will access memory in ACPI NVS region via APEI.  That
>>> is, instructions in APEI ERST/EINJ table will read/write ACPI NVS
>>> region.  The original resource conflict checking in APEI code will
>>> check memory/ioport accessed by APEI via general resource management
>>> mech.  But ACPI NVS region is marked as busy already, so that the
>>> false resource conflict will prevent APEI ERST/EINJ to work.
>>>
>>> To fix this, this patch excludes ACPI NVS regions when APEI components
>>> request resources.  So that they will not conflict with ACPI NVS
>>> regions.
>>
>> I think this is much, much too complicated.
>>
>> Yinghai's three-line e820.c patch to leave ACPI NVS regions in the
>> iomem_resource tree, but as not busy, is far better.
>
> ACPI NVS should only be used by firmware or firmware interpreter instead
> of the ordinary drivers.  So I think that is reasonable to make it busy
> in iomem resource tree.

"My driver is not like ordinary drivers" is a common excuse for adding
special cases. I don't buy it.

These patches (3 and 4) add a lot of complexity but I don't believe
they add any real protection.

Regions are marked busy by their owners, i.e., by drivers that claim
devices and know how to operate them.  The e820 code is not an owner
of ACPI NVS regions, so it should not mark them busy.

I don't really think we have a problem here that needs to be solved.
Ordinary drivers have no way of learning an address in ACPI NVS, so
they aren't even going to try to use it.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/