Severity of ACPI Error Message from _SRS

[Alex Hung]

On 01/25/2013 05:37 PM, Colin Ian King wrote:
> On 25/01/13 09:22, Alex Hung wrote:
>> Hi,
>>
>> It is found that kernel generates ACPI error messages on AMI's BIOS's
>> implementation when kernel executes _SRS messages, as the launchpad bug
>> below
>>
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1076979
>>
>> Apparently kernel follows ACPI specification but BIOS did not handle it
>> correctly; however, the error messages has not caused function failure
>> so far.
>>
>> Some facts:
>> 1. It is only seen on AMI's BIOS
>> 2. S3, S4, and reboot failures are not related to this errors so far.
>> 3. It only happens on super I/O devices, i.e. LPT (for printer port) and
>> UART (for serial port) that reside in LPC bridge.
>> 4. _SRS method is optional.
>> 5. BIOS usually configures LPT and UART, if presents, during *POST* time.
>> 6. We haven't seen LPT or UART failures even when the ACPI errors are
>> presents.
>>
>> For longer term, it is needed to feedback BIOS vendor to have this fixed.
>>
>> For now, the failures are marked as CRITICAL. It is suggested that we
>> may lower it to HIGH or MEDIUM. I personally think it is not a bad idea
>> for the reasons above.
>>
>> Any thoughts?
>>
>> Cheers,
>> Alex Hung
>>
>>
> The reason that this is marked CRITICAL is that the firmware is given a
> buffer that is too short and we have an attempt to access memory outside
> this buffer.  fwts doesn't care about which control this happens to, any
> access outside an buffer is really not good, so it is marked as so.
>
> I consider this as bad as a buffer overflow in C - although in this case
> the interpreter is able to catch so we don't actually crash and burn.
> The issue is that the code is trying to set something which can't be set
> - and so the interpreter can't do it and the end result is something
> that isn't working correctly.  fwts has to make a best guess judgement
> and flags this up as critical for a few reasons:
>
> 1. The code is obviously badly wrong
Totally agree. We are highlighting to BIOS vendor and hope they are 
going to fix it this time.
> 2. An attempt to write to memory outside a given range is always a bad bug
> 3. The end result is that the action is aborted, so who knows what the
> end result will be, the outcome is not predictable.
>
> Hence why it is flagged as critical, so that somebody will look at it
> and see why it is failing so miserably ;-)
>
This is a good point. I think we still need to have this fixed in BIOS 
code. Some critical error messages won't hurt but it will keep us reminded.

Thanks Colin.

Cheers,
Alex Hung

> Colin
>