search

reedwind / lib

0 stars 0 forks source link

Bug 713 - AML interpreter doesn't prevent dead RefOf-references #237

Open reedwind opened 11 years ago

reedwind commented 11 years ago

Reported by: Lin Ming ming.m.lin@intel.com Reported at: 2008-03-25 21:33:35

Product: ACPICA Component: Core/Interpreter Platform: All OS: Linux Priority: P3 Severity: normal

reedwind commented 11 years ago

Commented by: Lin Ming ming.m.lin@intel.com Commented at: 2008-03-25 21:33:35

Most recent kernel where this bug did not occur: Distribution: Hardware Environment: Software Environment: Problem Description:

The Linux kernel ACPI interpreter fails the following AML test when it is compiled into a simulator. So if an OEM BIOS includes this code, Linux would fail.

Steps to reproduce:

Run interpreter with the .asl demo code attached below.

reedwind commented 11 years ago

Commented by: Lin Ming ming.m.lin@intel.com Commented at: 2008-03-25 21:38:03

Created an attachment (id=786) ASL code to reproduce bug.

DESCRIPTION:

Current implementation of RefOf operation doesn't increment the ref-count of the object it points to. This leads to undefined results.

The demo program is some kind of bad ASL program which being simulated on acpiexec shows the gap in AML interpretation.

The program assigns the RefOf-reference of the local object of method to the higher-level object. After completion of that method the program initiates the memory allocation activity (calls another method and declares new objects by Name operator in it).

Then the program tries to do access by the reference which points to the internal object of the mentioned method which was completed before that.

The acceptable result there is either exception or the old content of that object (the latter is easier option).

But the result shown by demo is inadmissible - it is some of new allocated objects.

.......................... Output of demo:

INTERNAL BUG NUMBER:

212

reedwind commented 11 years ago

Commented by: Lin Ming ming.m.lin@intel.com Commented at: 2008-03-25 21:40:41

---- comments from Valery A Podrezov ------ I have investigated the bug and prepared preliminary update (it works, needs cosmetic) which provides strongly that when the type of Name Space node (Node) (as well as pseudo nodes of Args and Locals) is ACPI_TYPE_ANY, then the Node->Child is not anyhow used in calculation. This new feature was meant to be used then in update for bug (6389(212)) fixing. The field Node->Child was considered to be used to keep temporary the address of the internal object of the NS Node (Node->Object) in the interim between the object of Node is detached and the following new object (if any) is attached thus providing the RefOf references not to lose the objects they refer to and handle not to delete NS Node until the last object it was referring to (Node->Object stored to Node->Child) has non-zero NS-ReferenceCount that is there are RefOf references pointing to that NS. If new object is attached this Node->Child is processed and then Node->Child = NULL.

Started investigating and pre-implementing (started with Locals, not tested or tried it yet for Args and not started implementing it for NamedX) basing on the mentioned above new feature the reference count for the Name Space Node to fix the root cause of the bug (6389(212)). It would need additionally:

a) to allocate the ReferenceCount for NS Node though it could be really located in its internal object (ACPI_OPERAND_OBJECT structure), b) to change arrays of pseudo nodes of ArgX and LocalX in ACPI_WALK_STATE structure to the arrays of pointers to the pseudo nodes of ArgX and LocalX which will be allocated dynamically when actually needed.

Discussion needed.

Stopped working in front of dilemma - do we actually want to implement the common mechanism of RefCounts for the NS nodes to exclude undefined behaviour of bad AML program (6389(212)) (has it other reasons?) or prefer to generate exception when the attempt is made to generate suspicious RefOf reference which potentially may have (but may not) bad consequences (for example, an attempt is made to store RefOf-reference pointing to object O1 into the object O2 which belongs to the higher than O1 level scope - generate exception here). The exception in this case should be then specified by ACPI.

Moreover, resolving (6389(212)) by adding RefCounts for NS would mean the bad program would deal with the data of dead method.

reedwind commented 11 years ago

Commented by: Lin Ming ming.m.lin@intel.com Commented at: 2008-03-25 21:42:18

This bug is ported from http://bugzilla.kernel.org/show_bug.cgi?id=6389

reedwind commented 11 years ago

Commented by: Bob Moore robert.moore@intel.com Commented at: 2008-06-17 15:34:17

Probably will not fix, since the risk-to-reward is very high and the problem has not been seen in the field.