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, 20 Jul 2011 09:22:31 -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,
	Andi Kleen <andi@...stfloor.org>,
	Tony Luck <tony.luck@...el.com>, linux-acpi@...r.kernel.org,
	Matthew Garrett <mjg@...hat.com>
Subject: Re: [BUGFIX] ACPI, APEI, EINJ Param support is disabled by default

On Wed, Jul 20, 2011 at 2:09 AM, Huang Ying <ying.huang@...el.com> wrote:
> EINJ parameter support is only usable for some specific BIOS.
> Originally, it is expected to have no harm for BIOS does not support
> it.  But now, we found it will cause issue (memory overwriting) for
> some BIOS.  So param support is disabled by default and only enabled
> when newly added module parameter named "param_extension" is
> explicitly specified.

Adding parameters always makes things harder for users.  Is there any
way this could be done with a whitelist or other automatic mechanism?

Per 6e320ec1d98 (which added EINJ parameter support), parameters are
an unpublished extension and are not part of the ACPI spec.  So if we
pick up an MMIO address from a SET_ERROR_TYPE WRITE_REGISTER
instruction and blindly fill in a structure (undefined by the spec)
presumed to be at that address, it doesn't seem surprising that things
will blow up on BIOSes that don't expect that behavior.  After all,
the spec says to write to a generic address structure (not an
einj_parameter structure) when we interpret the WRITE_REGISTER
instruction (not at the magic time between SET_ERROR_TYPE and
EXECUTE_OPERATION).

If EINJ parameter support is ever added to the ACPI spec, I would
expect a new EINJ flag bit or similar indication to be added at the
same time, so the OS would know when to use it.

Can you add a whitelist of BIOSes that do support this extension?
Maybe you could define a GUID that future platforms could supply so
you wouldn't have to update the whitelist for every new platform that
supports 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ