Bug 6389 - AML interpreter doesn't prevent dead RefOf-references
Summary: AML interpreter doesn't prevent dead RefOf-references
Status: REJECTED DOCUMENTED
Alias: None
Product: ACPI
Classification: Unclassified
Component: ACPICA-Core (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Lin Ming
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-14 04:42 UTC by Valery A Podrezov
Modified: 2008-03-25 21:44 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
ASL code to reproduce bug. (821 bytes, text/plain)
2006-04-14 04:46 UTC, Valery A Podrezov
Details

Description Valery A Podrezov 2006-04-14 04:42:12 UTC
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.
Comment 1 Valery A Podrezov 2006-04-14 04:46:26 UTC
Created attachment 7870 [details]
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:
- ex main
Executing \MAIN
[ACPI Debug]  String: [0x07] "ERROR 0"
[ACPI Debug]  Integer: 0x00000000ABCD0004
No return object from execution of \MAIN
- q
ACPI (uttrack-0703): No outstanding allocations [20060331]
..........................

INTERNAL BUG NUMBER:

   212
Comment 2 Valery A Podrezov 2006-04-29 10:34:24 UTC
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.
Comment 3 Len Brown 2008-03-25 20:52:59 UTC
this one should be moved to http://acpica.org/bugzilla/
because it isn't seen in a Linux kernel context,
but only in a simulation test suite context.
Comment 4 Lin Ming 2008-03-25 21:44:08 UTC
close
moved to http://www.acpica.org/bugzilla/show_bug.cgi?id=713

Note You need to log in before you can comment on or make changes to this bug.