linux-kernel - Re: [BUG] acpica: ltp_acpi test case causes kernel crash at acpi_ns_walk

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:   Thu, 14 Dec 2017 01:34:35 -0800
From:   Vadim Lomovtsev <Vadim.Lomovtsev@...iumnetworks.com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Robert Moore <robert.moore@...el.com>, Lv <lv.zheng@...el.com>,
        Rafael Wysocki <rafael.j.wysocki@...el.com>,
        Len Brown <lenb@...nel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        "devel@...ica.org" <devel@...ica.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        vadim.lomovtsev@...ium.com
Subject: Re: [BUG] acpica: ltp_acpi test case causes kernel crash at
 acpi_ns_walk_namespace

On Wed, Dec 13, 2017 at 05:52:38PM +0100, Rafael J. Wysocki wrote:
> On Wed, Dec 13, 2017 at 3:55 PM, Vadim Lomovtsev
> <Vadim.Lomovtsev@...iumnetworks.com> wrote:
> > On Wed, Dec 13, 2017 at 12:45:50AM +0100, Rafael J. Wysocki wrote:
> >> On Tuesday, December 12, 2017 4:59:19 PM CET Vadim Lomovtsev wrote:
> >> > Hi guys,
> >> >
> >> > While running LTP tests I've faced kernel crash caused by ltp_acpi test case.
> >> > I have ACPI support enabled in kernel but kernel is boot with FDT having ACPI
> >> > disabled. The ltp_acpi test case application is built along with ltp_acpi_cmds
> >> > module to run ACPI tests.
> >> >
> >> > So my question is - should we update acpica implementation at kernel side by
> >> > adding 'acpi_disabled' variable checking to the 'acpi_get_devices' function (see
> >> > patch next to this email, maybe not a good approach) or this should be fixed at LTP
> >> > side so the ltp_acpi_cmds should be updated in order to check if acpi is enabled
> >> > before running tests ?
> >>
> >> There should be a check preventing acpi_get_devices() from being called in the
> >> acpi_disabled case.
> >
> > In my case I have to update ltp_acpi code then.
> 
> RIght.
> 
> >>
> >> acpi_disabled is Linux-specific and the ACPICA code isn't, so the code calling
> >> ACPICA functions should check acpi_disabled when necessary.
> >
> > Agree. However getting back to LTP tests it looks like such calls were implemented
> > intentionally without checking of aspi_disabled value.
> >
> > Don't we have any self-testing stuff in acpica to prevent such scenarious ?
> 
> ACPICA doesn't know anything about acpi_disabled as I said already.

And I got it from the first time. And assuming that I said that suggested patch
'maybe not a good approach' in the issue description. Just wanted to
highlight the issue and initiate discussion.

> 
> I would argue that testing unsupported use cases in LTP is not very useful.
>

The ltp_acpi test in particular shows that there is no any protection from such actions
so I wouldn't said that it is useless use case. From another hand, those calls were intialted
from kernel module (which is part of test case) so the solution here is to place ACPI
state check there - into kernel module.

But again, see your point. Thank you for your time.

> Thanks,
> Rafael

WBR,
Vadim