linux-kernel - Re: [PATCH v2 3/3] ACPI / tables: Convert the initrd table override mechanisms to the table upgrade mechanism

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]

Date:	Wed, 13 Apr 2016 19:01:36 +0300
From:	Octavian Purdila <octavian.purdila@...el.com>
To:	Lv Zheng <lv.zheng@...el.com>
Cc:	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <len.brown@...el.com>, Lv Zheng <zetalog@...il.com>,
	lkml <linux-kernel@...r.kernel.org>, linux-acpi@...r.kernel.org
Subject: Re: [PATCH v2 3/3] ACPI / tables: Convert the initrd table override
 mechanisms to the table upgrade mechanism

On Mon, Apr 11, 2016 at 5:13 AM, Lv Zheng <lv.zheng@...el.com> wrote:
>
> This patch converts the initrd table override mechanism to the table
> upgrade mechanism by restricting its usage to the tables released with
> compatibility and more recent revision.
>
> This use case has been encouraged by the ACPI specification:
> 1. OEMID:
>    An OEM-supplied string that identifies the OEM.
> 2. OEM Table ID:
>    An OEM-supplied string that the OEM uses to identify the particular data
>    table. This field is particularly useful when defining a definition
>    block to distinguish definition block functions. OEM assigns each
>    dissimilar table a new OEM Table Id.
> 3. OEM Revision:
>    An OEM-supplied revision number. Larger numbers are assumed to be newer
>    revisions.
> For OEMs, good practices will ensure consistency when assigning OEMID and
> OEM Table ID fields in any table. The intent of these fields is to allow
> for a binary control system that support services can use. Because many
> support function can be automated, it is useful when a tool can
> programatically determine which table release is a compatible and more
> recent revision of a prior table on the same OEMID and OEM Table ID.
>
> The facility can now be used by the vendors to upgrade wrong tables for bug
> fixing purpose, thus lockdep disabling taint is not suitable for it and it
> should be a default 'y' option to implement the spec encouraged use case.
>

I agree that we should not force lockdep disabling. I wonder if we
should add a new taint (like the one I proposed in the overlay patch
set) to see in bug reports that the ACPI tables have been modified.

Also, do we need a new config option? IMO it would be better if we can
keep the existing config option and do the following:

* if CONFIG_ACPI_INITRD_TABLE_OVERRIDE is set: allow arbitrary
overrides (preserve the current behavior)

* if CONFIG_ACPI_INITRD_TABLE_OVERRIDE is not set: allow upgrades
based on the revision number

* allow adding new tables regardless of CONFIG_ACPI_INITRD_TABLE_OVERRIDE