linux-kernel - Re: [PATCH] ACPI: Implement overriding of arbitrary ACPI tables via initrd

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: <CAE9FiQVxH4cSotaTOKrNe-W+EQEdg=r5AbUaejD3FtyY2bRCsQ@mail.gmail.com>
Date:	Fri, 23 Mar 2012 21:41:37 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Thomas Renninger <trenn@...e.de>
Cc:	eric.piel@...mplin-utc.net, vojcek@...n.pl, dsdt@...gusch.at,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	x86@...nel.org, Lin Ming <ming.m.lin@...el.com>, lenb@...nel.org,
	robert.moore@...el.com, hpa@...or.com
Subject: Re: [PATCH] ACPI: Implement overriding of arbitrary ACPI tables via initrd

On Fri, Mar 23, 2012 at 6:26 PM, Thomas Renninger <trenn@...e.de> wrote:
>> maybe could have dmi checking for more strict checking.
> I do not understand what should get checked?
> Hm, I guess you mean if a general table is always added that is distributed
> on different platforms and you want to white/blacklist machines to
> explicitly load/not load the table?
> This must not happen.
> The tables are always platform specific and you provide tables for
> a specific machine only for debugging purposes.
>
>> also would help if have one boot command that could skip overriding.
> Same. Both should not be needed.
>
> Or you have a use-case in mind I cannot not think of...

For known broken system,  could be old, or vendor does not want to
provide updated firmware anymore.
if the user could boot system with debug parameter
like "noapic maxcpus=1...."
then have user space util to extract acpi tables, and patch them and
repack them into initrd.
next boot will have system running with optimal ...

If we could do that, we could avoid or kill workaround and quirks in the kernel.

So we may need some strict check or skip when you are moving disk
around or update different bios later.

Thanks

Yinghai
--
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/