linux-kernel - Re: [PATCH] acpi-apei-einj: add extensions to EINJ from rev 5.0 of acpi spec

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:	Tue, 6 Dec 2011 10:45:19 -0800
From:	Tony Luck <tony.luck@...el.com>
To:	Chen Gong <gong.chen@...ux.intel.com>
Cc:	Len Brown <len.brown@...el.com>, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org, ying.huang@...el.com
Subject: Re: [PATCH] acpi-apei-einj: add extensions to EINJ from rev 5.0 of
 acpi spec

On Tue, Dec 6, 2011 at 12:22 AM, Chen Gong <gong.chen@...ux.intel.com> wrote:
> I don't think one knows how to set *vendor_flags* correctly if no any
> instructions.

Agreed - more documentation would help here - but I suspect that it
needs to come
from a vendor implementing an extension for specifics ... but for general
how to use this - see more comments below.

> need explanation in the document how to set error type in ACPI 5.0.
>
> In the spec it doesn't say this bit field is filled by the user, from
> the codes I have following conclusion: one can set error type as 0x2,
> 0x4, 0x8 etc. or 0x80000002, 0x80000004, 0x80000008 etc, right?

The spec is pretty vague here - I'm assuming that as soon as the 0x80000000
bit is seen, the rest of the bits are fair game for the vendor to do
anything they
like.  So I provided a way to set the error_type because I don't think there is
any association between bits and error type.  E.g. one vendor could use
0x80000001 for some special memory operation - so expect a memory address
and mask, while another vendor could use the same 0x80000001 for a PCIe
operation, so want to see a segment/bus/device/function.  So I tried to be
flexible.  I'd expect that an application trying to use this would look at the
contents of the /sys/kernel/debug/apei/einj/vendor to know that they were
on the right platform, with the device/rev_id to use whatever vendor extension
they want.  But this needs more (some :-) ) Documentation

Of course there is still some vendor defined memory at the very end of the
structure that I have absolutely no idea what to do with.  I've
ignored it for now,
but if some vendor does do something with it, we will need another vendor_blob
interface to allow arbitrary bytes to be written to (and read from?)
that area (just
checking the size).

The whole vendor extension part is very speculative on my part as I don't have
any solid examples to test.  I do have a platform that provides the
structure. But
I don't know whether it actually implements any extended operations.

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