RE: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Zheng, Lv]

Hi, 

> From: Seunghun Han [mailto:kkama...@gmail.com]
> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> 
> Hello, Lv and Rafael.
> 
> I checked that my patch was merged to ACPICA project.
> Thank you for your notice.
> 
> I added an analysis report which has the root cause of this problem below.
> 
> 2017-02-27 11:45 GMT+09:00 Zheng, Lv <lv.zh...@intel.com>:
> > Hi, Rafael
> >
> >> From: linux-acpi-ow...@vger.kernel.org 
> >> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of
> Rafael J.
> >> Wysocki
> >> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >>
> >> On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han <kkama...@gmail.com> wrote:
> >> > Hi, Rafael.
> >> >
> >> > I agree with you and I added my opinion below.
> >> >
> >> > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> >> >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
> >> >>> Hi, Rafeal.
> >> >>>
> >> >>> I added my opinion below.
> >> >>>
> >> >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> >> >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> >> >>> >> Hi, Rafael.
> >> >>> >>
> >> >>> >> I added my opinion below.
> >> >>> >>
> >> >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> >> >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> >> >>> >> >> Hi, Lv Zheng.
> >> >>> >> >>
> >> >>> >> >> I added my handcrafted ACPI table under your request, because
> >> >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> >> >>> >> >>
> >> >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
> >> >>> >> >> > Hello,
> >> >>> >> >> >
> >> >>> >> >> > I attached the test results below,
> >> >>> >> >> >
> >> >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki 
> >> >>> >> >> > <r...@rjwysocki.net>:
> >> >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >> >>> >> >> >>> Hi,
> >> >>> >> >> >>>
> >> >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >> >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On
> >> Behalf Of Seunghun
> >> >>> >> >> >>> > Han
> >> >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache 
> >> >>> >> >> >>> > leak
> >> >>> >> >> >>> >
> >> >>> >> >> >>> > I'm Seunghun Han, and I work for National Security 
> >> >>> >> >> >>> > Research Institute of
> >> >>> >> >> >>> > South Korea.
> >> >>> >> >> >>> >
> >> >>> >> >> >>> > I have been doing a research on ACPI and making a 
> >> >>> >> >> >>> > handcrafted ACPI table
> >> >>> >> >> >>> > for my research.
> >> >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in 
> >> >>> >> >> >>> > Linux kernel while boot
> >> >>> >> >> >>> > process, and Linux kernel goes well without critical 
> >> >>> >> >> >>> > problems.
> >> >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early 
> >> >>> >> >> >>> > abort cases.
> >> >>> >> >> >>> >
> >> >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
> >> >>> >> >> >>> > >

RE: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Zheng, Lv]

Hi, 

> From: Seunghun Han [mailto:kkama...@gmail.com]
> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> 
> Hello, Lv and Rafael.
> 
> I checked that my patch was merged to ACPICA project.
> Thank you for your notice.
> 
> I added an analysis report which has the root cause of this problem below.
> 
> 2017-02-27 11:45 GMT+09:00 Zheng, Lv :
> > Hi, Rafael
> >
> >> From: linux-acpi-ow...@vger.kernel.org 
> >> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of
> Rafael J.
> >> Wysocki
> >> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >>
> >> On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han  wrote:
> >> > Hi, Rafael.
> >> >
> >> > I agree with you and I added my opinion below.
> >> >
> >> > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki :
> >> >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
> >> >>> Hi, Rafeal.
> >> >>>
> >> >>> I added my opinion below.
> >> >>>
> >> >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
> >> >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> >> >>> >> Hi, Rafael.
> >> >>> >>
> >> >>> >> I added my opinion below.
> >> >>> >>
> >> >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
> >> >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> >> >>> >> >> Hi, Lv Zheng.
> >> >>> >> >>
> >> >>> >> >> I added my handcrafted ACPI table under your request, because
> >> >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> >> >>> >> >>
> >> >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
> >> >>> >> >> > Hello,
> >> >>> >> >> >
> >> >>> >> >> > I attached the test results below,
> >> >>> >> >> >
> >> >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki 
> >> >>> >> >> > :
> >> >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >> >>> >> >> >>> Hi,
> >> >>> >> >> >>>
> >> >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >> >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On
> >> Behalf Of Seunghun
> >> >>> >> >> >>> > Han
> >> >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache 
> >> >>> >> >> >>> > leak
> >> >>> >> >> >>> >
> >> >>> >> >> >>> > I'm Seunghun Han, and I work for National Security 
> >> >>> >> >> >>> > Research Institute of
> >> >>> >> >> >>> > South Korea.
> >> >>> >> >> >>> >
> >> >>> >> >> >>> > I have been doing a research on ACPI and making a 
> >> >>> >> >> >>> > handcrafted ACPI table
> >> >>> >> >> >>> > for my research.
> >> >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in 
> >> >>> >> >> >>> > Linux kernel while boot
> >> >>> >> >> >>> > process, and Linux kernel goes well without critical 
> >> >>> >> >> >>> > problems.
> >> >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early 
> >> >>> >> >> >>> > abort cases.
> >> >>> >> >> >>> >
> >> >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
> >> >>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >> >>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >>

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hello, Lv and Rafael.

I checked that my patch was merged to ACPICA project.
Thank you for your notice.

I added an analysis report which has the root cause of this problem below.

2017-02-27 11:45 GMT+09:00 Zheng, Lv <lv.zh...@intel.com>:
> Hi, Rafael
>
>> From: linux-acpi-ow...@vger.kernel.org 
>> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
>> Wysocki
>> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>>
>> On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han <kkama...@gmail.com> wrote:
>> > Hi, Rafael.
>> >
>> > I agree with you and I added my opinion below.
>> >
>> > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
>> >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
>> >>> Hi, Rafeal.
>> >>>
>> >>> I added my opinion below.
>> >>>
>> >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
>> >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
>> >>> >> Hi, Rafael.
>> >>> >>
>> >>> >> I added my opinion below.
>> >>> >>
>> >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
>> >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>> >>> >> >> Hi, Lv Zheng.
>> >>> >> >>
>> >>> >> >> I added my handcrafted ACPI table under your request, because
>> >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
>> >>> >> >>
>> >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
>> >>> >> >> > Hello,
>> >>> >> >> >
>> >>> >> >> > I attached the test results below,
>> >>> >> >> >
>> >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki 
>> >>> >> >> > <r...@rjwysocki.net>:
>> >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>> >>> >> >> >>> Hi,
>> >>> >> >> >>>
>> >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
>> >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On
>> Behalf Of Seunghun
>> >>> >> >> >>> > Han
>> >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>> >>> >> >> >>> >
>> >>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
>> >>> >> >> >>> > Institute of
>> >>> >> >> >>> > South Korea.
>> >>> >> >> >>> >
>> >>> >> >> >>> > I have been doing a research on ACPI and making a 
>> >>> >> >> >>> > handcrafted ACPI table
>> >>> >> >> >>> > for my research.
>> >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
>> >>> >> >> >>> > kernel while boot
>> >>> >> >> >>> > process, and Linux kernel goes well without critical 
>> >>> >> >> >>> > problems.
>> >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early 
>> >>> >> >> >>> > abort cases.
>> >>> >> >> >>> >
>> >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
>> >>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>> >>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>> >>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>> >>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>> >>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>> >>> >> >> &g

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hello, Lv and Rafael.

I checked that my patch was merged to ACPICA project.
Thank you for your notice.

I added an analysis report which has the root cause of this problem below.

2017-02-27 11:45 GMT+09:00 Zheng, Lv :
> Hi, Rafael
>
>> From: linux-acpi-ow...@vger.kernel.org 
>> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
>> Wysocki
>> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>>
>> On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han  wrote:
>> > Hi, Rafael.
>> >
>> > I agree with you and I added my opinion below.
>> >
>> > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki :
>> >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
>> >>> Hi, Rafeal.
>> >>>
>> >>> I added my opinion below.
>> >>>
>> >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
>> >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
>> >>> >> Hi, Rafael.
>> >>> >>
>> >>> >> I added my opinion below.
>> >>> >>
>> >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
>> >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>> >>> >> >> Hi, Lv Zheng.
>> >>> >> >>
>> >>> >> >> I added my handcrafted ACPI table under your request, because
>> >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
>> >>> >> >>
>> >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
>> >>> >> >> > Hello,
>> >>> >> >> >
>> >>> >> >> > I attached the test results below,
>> >>> >> >> >
>> >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki 
>> >>> >> >> > :
>> >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>> >>> >> >> >>> Hi,
>> >>> >> >> >>>
>> >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
>> >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On
>> Behalf Of Seunghun
>> >>> >> >> >>> > Han
>> >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>> >>> >> >> >>> >
>> >>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
>> >>> >> >> >>> > Institute of
>> >>> >> >> >>> > South Korea.
>> >>> >> >> >>> >
>> >>> >> >> >>> > I have been doing a research on ACPI and making a 
>> >>> >> >> >>> > handcrafted ACPI table
>> >>> >> >> >>> > for my research.
>> >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
>> >>> >> >> >>> > kernel while boot
>> >>> >> >> >>> > process, and Linux kernel goes well without critical 
>> >>> >> >> >>> > problems.
>> >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early 
>> >>> >> >> >>> > abort cases.
>> >>> >> >> >>> >
>> >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
>> >>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>> >>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>> >>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>> >>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>> >>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>> >>> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
>> >>> >> >> >>> > >install System Control
>> Interrupt

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Monday, February 27, 2017 02:45:50 AM Zheng, Lv wrote:
> Hi, Rafael
> 
> > From: linux-acpi-ow...@vger.kernel.org 
> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> > Wysocki
> > Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> > 
> > On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han <kkama...@gmail.com> wrote:
> > > Hi, Rafael.
> > >
> > > I agree with you and I added my opinion below.
> > >
> > > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> > >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
> > >>> Hi, Rafeal.
> > >>>
> > >>> I added my opinion below.
> > >>>
> > >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> > >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> > >>> >> Hi, Rafael.
> > >>> >>
> > >>> >> I added my opinion below.
> > >>> >>
> > >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> > >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> > >>> >> >> Hi, Lv Zheng.
> > >>> >> >>
> > >>> >> >> I added my handcrafted ACPI table under your request, because
> > >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> > >>> >> >>
> > >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
> > >>> >> >> > Hello,
> > >>> >> >> >
> > >>> >> >> > I attached the test results below,
> > >>> >> >> >
> > >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki 
> > >>> >> >> > <r...@rjwysocki.net>:
> > >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> > >>> >> >> >>> Hi,
> > >>> >> >> >>>
> > >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> > >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On
> > Behalf Of Seunghun
> > >>> >> >> >>> > Han
> > >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache 
> > >>> >> >> >>> > leak
> > >>> >> >> >>> >
> > >>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
> > >>> >> >> >>> > Institute of
> > >>> >> >> >>> > South Korea.
> > >>> >> >> >>> >
> > >>> >> >> >>> > I have been doing a research on ACPI and making a 
> > >>> >> >> >>> > handcrafted ACPI table
> > >>> >> >> >>> > for my research.
> > >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
> > >>> >> >> >>> > kernel while boot
> > >>> >> >> >>> > process, and Linux kernel goes well without critical 
> > >>> >> >> >>> > problems.
> > >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early 
> > >>> >> >> >>> > abort cases.
> > >>> >> >> >>> >
> > >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
> > >>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> > >>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> > >>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> > >>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator 
> > >>> >> >> >>> > >Device)
> > >>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> > >

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Monday, February 27, 2017 02:45:50 AM Zheng, Lv wrote:
> Hi, Rafael
> 
> > From: linux-acpi-ow...@vger.kernel.org 
> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> > Wysocki
> > Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> > 
> > On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han  wrote:
> > > Hi, Rafael.
> > >
> > > I agree with you and I added my opinion below.
> > >
> > > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki :
> > >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
> > >>> Hi, Rafeal.
> > >>>
> > >>> I added my opinion below.
> > >>>
> > >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
> > >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> > >>> >> Hi, Rafael.
> > >>> >>
> > >>> >> I added my opinion below.
> > >>> >>
> > >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
> > >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> > >>> >> >> Hi, Lv Zheng.
> > >>> >> >>
> > >>> >> >> I added my handcrafted ACPI table under your request, because
> > >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> > >>> >> >>
> > >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
> > >>> >> >> > Hello,
> > >>> >> >> >
> > >>> >> >> > I attached the test results below,
> > >>> >> >> >
> > >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki 
> > >>> >> >> > :
> > >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> > >>> >> >> >>> Hi,
> > >>> >> >> >>>
> > >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> > >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On
> > Behalf Of Seunghun
> > >>> >> >> >>> > Han
> > >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache 
> > >>> >> >> >>> > leak
> > >>> >> >> >>> >
> > >>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
> > >>> >> >> >>> > Institute of
> > >>> >> >> >>> > South Korea.
> > >>> >> >> >>> >
> > >>> >> >> >>> > I have been doing a research on ACPI and making a 
> > >>> >> >> >>> > handcrafted ACPI table
> > >>> >> >> >>> > for my research.
> > >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
> > >>> >> >> >>> > kernel while boot
> > >>> >> >> >>> > process, and Linux kernel goes well without critical 
> > >>> >> >> >>> > problems.
> > >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early 
> > >>> >> >> >>> > abort cases.
> > >>> >> >> >>> >
> > >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
> > >>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> > >>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> > >>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> > >>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator 
> > >>> >> >> >>> > >Device)
> > >>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> > >>> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
> > >>> >> >> >>> > >install System 

RE: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Zheng, Lv]

Hi, Rafael

> From: linux-acpi-ow...@vger.kernel.org 
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> Wysocki
> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> 
> On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han <kkama...@gmail.com> wrote:
> > Hi, Rafael.
> >
> > I agree with you and I added my opinion below.
> >
> > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
> >>> Hi, Rafeal.
> >>>
> >>> I added my opinion below.
> >>>
> >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> >>> >> Hi, Rafael.
> >>> >>
> >>> >> I added my opinion below.
> >>> >>
> >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <r...@rjwysocki.net>:
> >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> >>> >> >> Hi, Lv Zheng.
> >>> >> >>
> >>> >> >> I added my handcrafted ACPI table under your request, because
> >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> >>> >> >>
> >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han <kkama...@gmail.com>:
> >>> >> >> > Hello,
> >>> >> >> >
> >>> >> >> > I attached the test results below,
> >>> >> >> >
> >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki 
> >>> >> >> > <r...@rjwysocki.net>:
> >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >>> >> >> >>> Hi,
> >>> >> >> >>>
> >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On
> Behalf Of Seunghun
> >>> >> >> >>> > Han
> >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >>> >> >> >>> >
> >>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
> >>> >> >> >>> > Institute of
> >>> >> >> >>> > South Korea.
> >>> >> >> >>> >
> >>> >> >> >>> > I have been doing a research on ACPI and making a handcrafted 
> >>> >> >> >>> > ACPI table
> >>> >> >> >>> > for my research.
> >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
> >>> >> >> >>> > kernel while boot
> >>> >> >> >>> > process, and Linux kernel goes well without critical problems.
> >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort 
> >>> >> >> >>> > cases.
> >>> >> >> >>> >
> >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
> >>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> >>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
> >>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> >>> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
> >>> >> >> >>> > >install System Control
> Interrupt handler
> >>> >> >> >>> > (20160930/evevent-131)
> >>> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
> >>> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
> >>> >> >> >>> > >(20160930/evmisc-281)
> &

RE: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Zheng, Lv]

Hi, Rafael

> From: linux-acpi-ow...@vger.kernel.org 
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J.
> Wysocki
> Subject: Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> 
> On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han  wrote:
> > Hi, Rafael.
> >
> > I agree with you and I added my opinion below.
> >
> > 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki :
> >> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
> >>> Hi, Rafeal.
> >>>
> >>> I added my opinion below.
> >>>
> >>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
> >>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> >>> >> Hi, Rafael.
> >>> >>
> >>> >> I added my opinion below.
> >>> >>
> >>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
> >>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> >>> >> >> Hi, Lv Zheng.
> >>> >> >>
> >>> >> >> I added my handcrafted ACPI table under your request, because
> >>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> >>> >> >>
> >>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
> >>> >> >> > Hello,
> >>> >> >> >
> >>> >> >> > I attached the test results below,
> >>> >> >> >
> >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki 
> >>> >> >> > :
> >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >>> >> >> >>> Hi,
> >>> >> >> >>>
> >>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On
> Behalf Of Seunghun
> >>> >> >> >>> > Han
> >>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >>> >> >> >>> >
> >>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
> >>> >> >> >>> > Institute of
> >>> >> >> >>> > South Korea.
> >>> >> >> >>> >
> >>> >> >> >>> > I have been doing a research on ACPI and making a handcrafted 
> >>> >> >> >>> > ACPI table
> >>> >> >> >>> > for my research.
> >>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
> >>> >> >> >>> > kernel while boot
> >>> >> >> >>> > process, and Linux kernel goes well without critical problems.
> >>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort 
> >>> >> >> >>> > cases.
> >>> >> >> >>> >
> >>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
> >>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> >>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
> >>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> >>> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
> >>> >> >> >>> > >install System Control
> Interrupt handler
> >>> >> >> >>> > (20160930/evevent-131)
> >>> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
> >>> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
> >>> >> >> >>> > >(20160930/evmisc-281)
> >>> >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache 
> >>> >> >> >

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han  wrote:
> Hi, Rafael.
>
> I agree with you and I added my opinion below.
>
> 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki :
>> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
>>> Hi, Rafeal.
>>>
>>> I added my opinion below.
>>>
>>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
>>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
>>> >> Hi, Rafael.
>>> >>
>>> >> I added my opinion below.
>>> >>
>>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
>>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>>> >> >> Hi, Lv Zheng.
>>> >> >>
>>> >> >> I added my handcrafted ACPI table under your request, because
>>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
>>> >> >>
>>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
>>> >> >> > Hello,
>>> >> >> >
>>> >> >> > I attached the test results below,
>>> >> >> >
>>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
>>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>>> >> >> >>> Hi,
>>> >> >> >>>
>>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
>>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>>> >> >> >>> > Han
>>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>>> >> >> >>> >
>>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
>>> >> >> >>> > Institute of
>>> >> >> >>> > South Korea.
>>> >> >> >>> >
>>> >> >> >>> > I have been doing a research on ACPI and making a handcrafted 
>>> >> >> >>> > ACPI table
>>> >> >> >>> > for my research.
>>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
>>> >> >> >>> > kernel while boot
>>> >> >> >>> > process, and Linux kernel goes well without critical problems.
>>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort 
>>> >> >> >>> > cases.
>>> >> >> >>> >
>>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
>>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>>> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
>>> >> >> >>> > >install System Control Interrupt handler
>>> >> >> >>> > (20160930/evevent-131)
>>> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>>> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>>> >> >> >>> > >(20160930/evmisc-281)
>>> >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache 
>>> >> >> >>> > >still has objects
>>> >> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
>>> >> >> >>> > >4.10.0-rc3 #2
>>> >> >> >>> > >[0.186820] Hardware name: innotek GmbH 
>>> >> >> >>> > >VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
>>> >> >> >>> > >[0.188000] Call Trace:
>>> >> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
>>> >> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
>>> >> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>>> >> >> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
>>> >> >> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
>>> >> >> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
>>> >> >> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
>>> >> >> >>> > >[0.188000]  ? __class_create+0x4c/0x80
>>> >> >> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
>>> >> >> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
>>> >> >> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
>>> >> >> >>> > >[0.188000]  ? rest_init+0x80/0x80
>>> >> >> >>> > >[0.188000]  ? kernel_init+0xa/0x100
>>> >> >> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
>>> >> >> >>>
>>> >> >> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED 
>>> >> >> >>> error.
>>> >> >> >>> So could you send us the handcrafted ACPI table or both the 
>>> >> >> >>> "acpidump -c on" and "acpidump -c off" output?
>>> >> >>
>>> >> >> I modified FACP, FACS, APIC table in VirtualBox for Linux.
>>> >> >> Here are raw dumps of table.
>>> >> >
>>> >> > So, excuse me, but what's the security issue here?
>>> >> >
>>> >> > You hacked your ACPI tables into pieces which requires root privileges 
>>> >> > anyway.
>>> >> >
>>> >> > Thanks,
>>> >> > Rafael
>>> >> >
>>> >>
>>> >> As you mentioned earlier, I hacked my ACPI table for research, so it 
>>> >> seems that
>>> >> it is not a security issue.
>>> >>
>>> >> But, if new mainboard are released and they have a vendor-specific ACPI 
>>> >> table
>>> >> which has invalid data, the old version of kernel (<=4.9) will possibly 
>>> >> expose
>>> >> 

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han  wrote:
> Hi, Rafael.
>
> I agree with you and I added my opinion below.
>
> 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki :
>> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
>>> Hi, Rafeal.
>>>
>>> I added my opinion below.
>>>
>>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
>>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
>>> >> Hi, Rafael.
>>> >>
>>> >> I added my opinion below.
>>> >>
>>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
>>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>>> >> >> Hi, Lv Zheng.
>>> >> >>
>>> >> >> I added my handcrafted ACPI table under your request, because
>>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
>>> >> >>
>>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
>>> >> >> > Hello,
>>> >> >> >
>>> >> >> > I attached the test results below,
>>> >> >> >
>>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
>>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>>> >> >> >>> Hi,
>>> >> >> >>>
>>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
>>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>>> >> >> >>> > Han
>>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>>> >> >> >>> >
>>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
>>> >> >> >>> > Institute of
>>> >> >> >>> > South Korea.
>>> >> >> >>> >
>>> >> >> >>> > I have been doing a research on ACPI and making a handcrafted 
>>> >> >> >>> > ACPI table
>>> >> >> >>> > for my research.
>>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
>>> >> >> >>> > kernel while boot
>>> >> >> >>> > process, and Linux kernel goes well without critical problems.
>>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort 
>>> >> >> >>> > cases.
>>> >> >> >>> >
>>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
>>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>>> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
>>> >> >> >>> > >install System Control Interrupt handler
>>> >> >> >>> > (20160930/evevent-131)
>>> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>>> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>>> >> >> >>> > >(20160930/evmisc-281)
>>> >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache 
>>> >> >> >>> > >still has objects
>>> >> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
>>> >> >> >>> > >4.10.0-rc3 #2
>>> >> >> >>> > >[0.186820] Hardware name: innotek GmbH 
>>> >> >> >>> > >VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
>>> >> >> >>> > >[0.188000] Call Trace:
>>> >> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
>>> >> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
>>> >> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>>> >> >> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
>>> >> >> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
>>> >> >> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
>>> >> >> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
>>> >> >> >>> > >[0.188000]  ? __class_create+0x4c/0x80
>>> >> >> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
>>> >> >> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
>>> >> >> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
>>> >> >> >>> > >[0.188000]  ? rest_init+0x80/0x80
>>> >> >> >>> > >[0.188000]  ? kernel_init+0xa/0x100
>>> >> >> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
>>> >> >> >>>
>>> >> >> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED 
>>> >> >> >>> error.
>>> >> >> >>> So could you send us the handcrafted ACPI table or both the 
>>> >> >> >>> "acpidump -c on" and "acpidump -c off" output?
>>> >> >>
>>> >> >> I modified FACP, FACS, APIC table in VirtualBox for Linux.
>>> >> >> Here are raw dumps of table.
>>> >> >
>>> >> > So, excuse me, but what's the security issue here?
>>> >> >
>>> >> > You hacked your ACPI tables into pieces which requires root privileges 
>>> >> > anyway.
>>> >> >
>>> >> > Thanks,
>>> >> > Rafael
>>> >> >
>>> >>
>>> >> As you mentioned earlier, I hacked my ACPI table for research, so it 
>>> >> seems that
>>> >> it is not a security issue.
>>> >>
>>> >> But, if new mainboard are released and they have a vendor-specific ACPI 
>>> >> table
>>> >> which has invalid data, the old version of kernel (<=4.9) will possibly 
>>> >> expose
>>> >> kernel address and KASLR will be neutralized unintentionally.
>>> >
>>> > But that would mean a basically 

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hi, Rafael.

I agree with you and I added my opinion below.

2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki :
> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
>> Hi, Rafeal.
>>
>> I added my opinion below.
>>
>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
>> >> Hi, Rafael.
>> >>
>> >> I added my opinion below.
>> >>
>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>> >> >> Hi, Lv Zheng.
>> >> >>
>> >> >> I added my handcrafted ACPI table under your request, because
>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
>> >> >>
>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
>> >> >> > Hello,
>> >> >> >
>> >> >> > I attached the test results below,
>> >> >> >
>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>> >> >> >>> Hi,
>> >> >> >>>
>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>> >> >> >>> > Han
>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>> >> >> >>> >
>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
>> >> >> >>> > Institute of
>> >> >> >>> > South Korea.
>> >> >> >>> >
>> >> >> >>> > I have been doing a research on ACPI and making a handcrafted 
>> >> >> >>> > ACPI table
>> >> >> >>> > for my research.
>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
>> >> >> >>> > kernel while boot
>> >> >> >>> > process, and Linux kernel goes well without critical problems.
>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort 
>> >> >> >>> > cases.
>> >> >> >>> >
>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
>> >> >> >>> > >install System Control Interrupt handler
>> >> >> >>> > (20160930/evevent-131)
>> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>> >> >> >>> > >(20160930/evmisc-281)
>> >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache 
>> >> >> >>> > >still has objects
>> >> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
>> >> >> >>> > >4.10.0-rc3 #2
>> >> >> >>> > >[0.186820] Hardware name: innotek GmbH 
>> >> >> >>> > >VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
>> >> >> >>> > >[0.188000] Call Trace:
>> >> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
>> >> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
>> >> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>> >> >> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
>> >> >> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
>> >> >> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
>> >> >> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
>> >> >> >>> > >[0.188000]  ? __class_create+0x4c/0x80
>> >> >> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
>> >> >> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
>> >> >> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
>> >> >> >>> > >[0.188000]  ? rest_init+0x80/0x80
>> >> >> >>> > >[0.188000]  ? kernel_init+0xa/0x100
>> >> >> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
>> >> >> >>>
>> >> >> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
>> >> >> >>> So could you send us the handcrafted ACPI table or both the 
>> >> >> >>> "acpidump -c on" and "acpidump -c off" output?
>> >> >>
>> >> >> I modified FACP, FACS, APIC table in VirtualBox for Linux.
>> >> >> Here are raw dumps of table.
>> >> >
>> >> > So, excuse me, but what's the security issue here?
>> >> >
>> >> > You hacked your ACPI tables into pieces which requires root privileges 
>> >> > anyway.
>> >> >
>> >> > Thanks,
>> >> > Rafael
>> >> >
>> >>
>> >> As you mentioned earlier, I hacked my ACPI table for research, so it 
>> >> seems that
>> >> it is not a security issue.
>> >>
>> >> But, if new mainboard are released and they have a vendor-specific ACPI 
>> >> table
>> >> which has invalid data, the old version of kernel (<=4.9) will possibly 
>> >> expose
>> >> kernel address and KASLR will be neutralized unintentionally.
>> >
>> > But that would mean a basically non-functional system, so I'm not sure how
>> > anyone can actually take advantage of the "KASLR 

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hi, Rafael.

I agree with you and I added my opinion below.

2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki :
> On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
>> Hi, Rafeal.
>>
>> I added my opinion below.
>>
>> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
>> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
>> >> Hi, Rafael.
>> >>
>> >> I added my opinion below.
>> >>
>> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
>> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>> >> >> Hi, Lv Zheng.
>> >> >>
>> >> >> I added my handcrafted ACPI table under your request, because
>> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
>> >> >>
>> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
>> >> >> > Hello,
>> >> >> >
>> >> >> > I attached the test results below,
>> >> >> >
>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>> >> >> >>> Hi,
>> >> >> >>>
>> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
>> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>> >> >> >>> > Han
>> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>> >> >> >>> >
>> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
>> >> >> >>> > Institute of
>> >> >> >>> > South Korea.
>> >> >> >>> >
>> >> >> >>> > I have been doing a research on ACPI and making a handcrafted 
>> >> >> >>> > ACPI table
>> >> >> >>> > for my research.
>> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
>> >> >> >>> > kernel while boot
>> >> >> >>> > process, and Linux kernel goes well without critical problems.
>> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort 
>> >> >> >>> > cases.
>> >> >> >>> >
>> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
>> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
>> >> >> >>> > >install System Control Interrupt handler
>> >> >> >>> > (20160930/evevent-131)
>> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>> >> >> >>> > >(20160930/evmisc-281)
>> >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache 
>> >> >> >>> > >still has objects
>> >> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
>> >> >> >>> > >4.10.0-rc3 #2
>> >> >> >>> > >[0.186820] Hardware name: innotek GmbH 
>> >> >> >>> > >VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
>> >> >> >>> > >[0.188000] Call Trace:
>> >> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
>> >> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
>> >> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>> >> >> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
>> >> >> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
>> >> >> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
>> >> >> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
>> >> >> >>> > >[0.188000]  ? __class_create+0x4c/0x80
>> >> >> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
>> >> >> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
>> >> >> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
>> >> >> >>> > >[0.188000]  ? rest_init+0x80/0x80
>> >> >> >>> > >[0.188000]  ? kernel_init+0xa/0x100
>> >> >> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
>> >> >> >>>
>> >> >> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
>> >> >> >>> So could you send us the handcrafted ACPI table or both the 
>> >> >> >>> "acpidump -c on" and "acpidump -c off" output?
>> >> >>
>> >> >> I modified FACP, FACS, APIC table in VirtualBox for Linux.
>> >> >> Here are raw dumps of table.
>> >> >
>> >> > So, excuse me, but what's the security issue here?
>> >> >
>> >> > You hacked your ACPI tables into pieces which requires root privileges 
>> >> > anyway.
>> >> >
>> >> > Thanks,
>> >> > Rafael
>> >> >
>> >>
>> >> As you mentioned earlier, I hacked my ACPI table for research, so it 
>> >> seems that
>> >> it is not a security issue.
>> >>
>> >> But, if new mainboard are released and they have a vendor-specific ACPI 
>> >> table
>> >> which has invalid data, the old version of kernel (<=4.9) will possibly 
>> >> expose
>> >> kernel address and KASLR will be neutralized unintentionally.
>> >
>> > But that would mean a basically non-functional system, so I'm not sure how
>> > anyone can actually take advantage of the "KASLR neutralization".
>>
>> I think an attacker can take advantage of the "KASLR neutralization". As you

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
> Hi, Rafeal.
> 
> I added my opinion below.
> 
> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> >> Hi, Rafael.
> >>
> >> I added my opinion below.
> >>
> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> >> >> Hi, Lv Zheng.
> >> >>
> >> >> I added my handcrafted ACPI table under your request, because
> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> >> >>
> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
> >> >> > Hello,
> >> >> >
> >> >> > I attached the test results below,
> >> >> >
> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >> >> >>> Hi,
> >> >> >>>
> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
> >> >> >>> > Han
> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >> >> >>> >
> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
> >> >> >>> > Institute of
> >> >> >>> > South Korea.
> >> >> >>> >
> >> >> >>> > I have been doing a research on ACPI and making a handcrafted 
> >> >> >>> > ACPI table
> >> >> >>> > for my research.
> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
> >> >> >>> > kernel while boot
> >> >> >>> > process, and Linux kernel goes well without critical problems.
> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort 
> >> >> >>> > cases.
> >> >> >>> >
> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
> >> >> >>> > >install System Control Interrupt handler
> >> >> >>> > (20160930/evevent-131)
> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
> >> >> >>> > >(20160930/evmisc-281)
> >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still 
> >> >> >>> > >has objects
> >> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> >> >> >>> > >4.10.0-rc3 #2
> >> >> >>> > >[0.186820] Hardware name: innotek GmbH 
> >> >> >>> > >VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
> >> >> >>> > >[0.188000] Call Trace:
> >> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
> >> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
> >> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
> >> >> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
> >> >> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
> >> >> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
> >> >> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
> >> >> >>> > >[0.188000]  ? __class_create+0x4c/0x80
> >> >> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
> >> >> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
> >> >> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
> >> >> >>> > >[0.188000]  ? rest_init+0x80/0x80
> >> >> >>> > >[0.188000]  ? kernel_init+0xa/0x100
> >> >> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
> >> >> >>>
> >> >> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
> >> >> >>> So could you send us the handcrafted ACPI table or both the 
> >> >> >>> "acpidump -c on" and "acpidump -c off" output?
> >> >>
> >> >> I modified FACP, FACS, APIC table in VirtualBox for Linux.
> >> >> Here are raw dumps of table.
> >> >
> >> > So, excuse me, but what's the security issue here?
> >> >
> >> > You hacked your ACPI tables into pieces which requires root privileges 
> >> > anyway.
> >> >
> >> > Thanks,
> >> > Rafael
> >> >
> >>
> >> As you mentioned earlier, I hacked my ACPI table for research, so it seems 
> >> that
> >> it is not a security issue.
> >>
> >> But, if new mainboard are released and they have a vendor-specific ACPI 
> >> table
> >> which has invalid data, the old version of kernel (<=4.9) will possibly 
> >> expose
> >> kernel address and KASLR will be neutralized unintentionally.
> >
> > But that would mean a basically non-functional system, so I'm not sure how
> > anyone can actually take advantage of the "KASLR neutralization".
> 
> I think an attacker can take advantage of the "KASLR neutralization". As you
> know, KASLR is good technology to protect kernel from kernel exploits.
> 
> If the kernel has vulnerabilities, the attacker can make 

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Friday, February 24, 2017 09:56:21 PM Seunghun Han wrote:
> Hi, Rafeal.
> 
> I added my opinion below.
> 
> 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
> > On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> >> Hi, Rafael.
> >>
> >> I added my opinion below.
> >>
> >> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
> >> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> >> >> Hi, Lv Zheng.
> >> >>
> >> >> I added my handcrafted ACPI table under your request, because
> >> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> >> >>
> >> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
> >> >> > Hello,
> >> >> >
> >> >> > I attached the test results below,
> >> >> >
> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >> >> >>> Hi,
> >> >> >>>
> >> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
> >> >> >>> > Han
> >> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >> >> >>> >
> >> >> >>> > I'm Seunghun Han, and I work for National Security Research 
> >> >> >>> > Institute of
> >> >> >>> > South Korea.
> >> >> >>> >
> >> >> >>> > I have been doing a research on ACPI and making a handcrafted 
> >> >> >>> > ACPI table
> >> >> >>> > for my research.
> >> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux 
> >> >> >>> > kernel while boot
> >> >> >>> > process, and Linux kernel goes well without critical problems.
> >> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort 
> >> >> >>> > cases.
> >> >> >>> >
> >> >> >>> > Boot log of ACPI operand cache leak is as follows:
> >> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> >> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
> >> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> >> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to 
> >> >> >>> > >install System Control Interrupt handler
> >> >> >>> > (20160930/evevent-131)
> >> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
> >> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
> >> >> >>> > >(20160930/evmisc-281)
> >> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still 
> >> >> >>> > >has objects
> >> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> >> >> >>> > >4.10.0-rc3 #2
> >> >> >>> > >[0.186820] Hardware name: innotek GmbH 
> >> >> >>> > >VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
> >> >> >>> > >[0.188000] Call Trace:
> >> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
> >> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
> >> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
> >> >> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
> >> >> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
> >> >> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
> >> >> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
> >> >> >>> > >[0.188000]  ? __class_create+0x4c/0x80
> >> >> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
> >> >> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
> >> >> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
> >> >> >>> > >[0.188000]  ? rest_init+0x80/0x80
> >> >> >>> > >[0.188000]  ? kernel_init+0xa/0x100
> >> >> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
> >> >> >>>
> >> >> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
> >> >> >>> So could you send us the handcrafted ACPI table or both the 
> >> >> >>> "acpidump -c on" and "acpidump -c off" output?
> >> >>
> >> >> I modified FACP, FACS, APIC table in VirtualBox for Linux.
> >> >> Here are raw dumps of table.
> >> >
> >> > So, excuse me, but what's the security issue here?
> >> >
> >> > You hacked your ACPI tables into pieces which requires root privileges 
> >> > anyway.
> >> >
> >> > Thanks,
> >> > Rafael
> >> >
> >>
> >> As you mentioned earlier, I hacked my ACPI table for research, so it seems 
> >> that
> >> it is not a security issue.
> >>
> >> But, if new mainboard are released and they have a vendor-specific ACPI 
> >> table
> >> which has invalid data, the old version of kernel (<=4.9) will possibly 
> >> expose
> >> kernel address and KASLR will be neutralized unintentionally.
> >
> > But that would mean a basically non-functional system, so I'm not sure how
> > anyone can actually take advantage of the "KASLR neutralization".
> 
> I think an attacker can take advantage of the "KASLR neutralization". As you
> know, KASLR is good technology to protect kernel from kernel exploits.
> 
> If the kernel has vulnerabilities, the attacker can make exploit using them.
> But, the exploit usually needs gadgets (small code), 

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hi, Rafeal.

I added my opinion below.

2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
> On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
>> Hi, Rafael.
>>
>> I added my opinion below.
>>
>> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
>> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>> >> Hi, Lv Zheng.
>> >>
>> >> I added my handcrafted ACPI table under your request, because
>> >> "acpidump -c on" and "acpidump -c off" doesn't work.
>> >>
>> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
>> >> > Hello,
>> >> >
>> >> > I attached the test results below,
>> >> >
>> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
>> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>> >> >>> Hi,
>> >> >>>
>> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
>> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>> >> >>> > Han
>> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>> >> >>> >
>> >> >>> > I'm Seunghun Han, and I work for National Security Research 
>> >> >>> > Institute of
>> >> >>> > South Korea.
>> >> >>> >
>> >> >>> > I have been doing a research on ACPI and making a handcrafted ACPI 
>> >> >>> > table
>> >> >>> > for my research.
>> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel 
>> >> >>> > while boot
>> >> >>> > process, and Linux kernel goes well without critical problems.
>> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
>> >> >>> >
>> >> >>> > Boot log of ACPI operand cache leak is as follows:
>> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install 
>> >> >>> > >System Control Interrupt handler
>> >> >>> > (20160930/evevent-131)
>> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>> >> >>> > >(20160930/evmisc-281)
>> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still 
>> >> >>> > >has objects
>> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
>> >> >>> > >4.10.0-rc3 #2
>> >> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, 
>> >> >>> > >BIOS VirtualBox 12/01/2006
>> >> >>> > >[0.188000] Call Trace:
>> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
>> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
>> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>> >> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
>> >> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
>> >> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
>> >> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
>> >> >>> > >[0.188000]  ? __class_create+0x4c/0x80
>> >> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
>> >> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
>> >> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
>> >> >>> > >[0.188000]  ? rest_init+0x80/0x80
>> >> >>> > >[0.188000]  ? kernel_init+0xa/0x100
>> >> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
>> >> >>>
>> >> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
>> >> >>> So could you send us the handcrafted ACPI table or both the "acpidump 
>> >> >>> -c on" and "acpidump -c off" output?
>> >>
>> >> I modified FACP, FACS, APIC table in VirtualBox for Linux.
>> >> Here are raw dumps of table.
>> >
>> > So, excuse me, but what's the security issue here?
>> >
>> > You hacked your ACPI tables into pieces which requires root privileges 
>> > anyway.
>> >
>> > Thanks,
>> > Rafael
>> >
>>
>> As you mentioned earlier, I hacked my ACPI table for research, so it seems 
>> that
>> it is not a security issue.
>>
>> But, if new mainboard are released and they have a vendor-specific ACPI table
>> which has invalid data, the old version of kernel (<=4.9) will possibly 
>> expose
>> kernel address and KASLR will be neutralized unintentionally.
>
> But that would mean a basically non-functional system, so I'm not sure how
> anyone can actually take advantage of the "KASLR neutralization".

I think an attacker can take advantage of the "KASLR neutralization". As you
know, KASLR is good technology to protect kernel from kernel exploits.

If the kernel has vulnerabilities, the attacker can make exploit using them.
But, the exploit usually needs gadgets (small code), therefore the attacker
should know where the gadgets are in kernel. If the KASLR is working in kernel,
the attacker should find the actual kernel address, and he can get kernel
address information from kernel warning.

>
>> I 

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hi, Rafeal.

I added my opinion below.

2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki :
> On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
>> Hi, Rafael.
>>
>> I added my opinion below.
>>
>> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
>> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>> >> Hi, Lv Zheng.
>> >>
>> >> I added my handcrafted ACPI table under your request, because
>> >> "acpidump -c on" and "acpidump -c off" doesn't work.
>> >>
>> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
>> >> > Hello,
>> >> >
>> >> > I attached the test results below,
>> >> >
>> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
>> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>> >> >>> Hi,
>> >> >>>
>> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
>> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>> >> >>> > Han
>> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>> >> >>> >
>> >> >>> > I'm Seunghun Han, and I work for National Security Research 
>> >> >>> > Institute of
>> >> >>> > South Korea.
>> >> >>> >
>> >> >>> > I have been doing a research on ACPI and making a handcrafted ACPI 
>> >> >>> > table
>> >> >>> > for my research.
>> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel 
>> >> >>> > while boot
>> >> >>> > process, and Linux kernel goes well without critical problems.
>> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
>> >> >>> >
>> >> >>> > Boot log of ACPI operand cache leak is as follows:
>> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install 
>> >> >>> > >System Control Interrupt handler
>> >> >>> > (20160930/evevent-131)
>> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>> >> >>> > >(20160930/evmisc-281)
>> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still 
>> >> >>> > >has objects
>> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
>> >> >>> > >4.10.0-rc3 #2
>> >> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, 
>> >> >>> > >BIOS VirtualBox 12/01/2006
>> >> >>> > >[0.188000] Call Trace:
>> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
>> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
>> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>> >> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
>> >> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
>> >> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
>> >> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
>> >> >>> > >[0.188000]  ? __class_create+0x4c/0x80
>> >> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
>> >> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
>> >> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
>> >> >>> > >[0.188000]  ? rest_init+0x80/0x80
>> >> >>> > >[0.188000]  ? kernel_init+0xa/0x100
>> >> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
>> >> >>>
>> >> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
>> >> >>> So could you send us the handcrafted ACPI table or both the "acpidump 
>> >> >>> -c on" and "acpidump -c off" output?
>> >>
>> >> I modified FACP, FACS, APIC table in VirtualBox for Linux.
>> >> Here are raw dumps of table.
>> >
>> > So, excuse me, but what's the security issue here?
>> >
>> > You hacked your ACPI tables into pieces which requires root privileges 
>> > anyway.
>> >
>> > Thanks,
>> > Rafael
>> >
>>
>> As you mentioned earlier, I hacked my ACPI table for research, so it seems 
>> that
>> it is not a security issue.
>>
>> But, if new mainboard are released and they have a vendor-specific ACPI table
>> which has invalid data, the old version of kernel (<=4.9) will possibly 
>> expose
>> kernel address and KASLR will be neutralized unintentionally.
>
> But that would mean a basically non-functional system, so I'm not sure how
> anyone can actually take advantage of the "KASLR neutralization".

I think an attacker can take advantage of the "KASLR neutralization". As you
know, KASLR is good technology to protect kernel from kernel exploits.

If the kernel has vulnerabilities, the attacker can make exploit using them.
But, the exploit usually needs gadgets (small code), therefore the attacker
should know where the gadgets are in kernel. If the KASLR is working in kernel,
the attacker should find the actual kernel address, and he can get kernel
address information from kernel warning.

>
>> I know the vendors collaborate with Linux kernel developers, but the problem
>> 

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> Hi, Rafael.
> 
> I added my opinion below.
> 
> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> >> Hi, Lv Zheng.
> >>
> >> I added my handcrafted ACPI table under your request, because
> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> >>
> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
> >> > Hello,
> >> >
> >> > I attached the test results below,
> >> >
> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >> >>> Hi,
> >> >>>
> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
> >> >>> > Han
> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >> >>> >
> >> >>> > I'm Seunghun Han, and I work for National Security Research 
> >> >>> > Institute of
> >> >>> > South Korea.
> >> >>> >
> >> >>> > I have been doing a research on ACPI and making a handcrafted ACPI 
> >> >>> > table
> >> >>> > for my research.
> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel 
> >> >>> > while boot
> >> >>> > process, and Linux kernel goes well without critical problems.
> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
> >> >>> >
> >> >>> > Boot log of ACPI operand cache leak is as follows:
> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install 
> >> >>> > >System Control Interrupt handler
> >> >>> > (20160930/evevent-131)
> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
> >> >>> > >(20160930/evmisc-281)
> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still 
> >> >>> > >has objects
> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 
> >> >>> > >#2
> >> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, 
> >> >>> > >BIOS VirtualBox 12/01/2006
> >> >>> > >[0.188000] Call Trace:
> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
> >> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
> >> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
> >> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
> >> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
> >> >>> > >[0.188000]  ? __class_create+0x4c/0x80
> >> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
> >> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
> >> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
> >> >>> > >[0.188000]  ? rest_init+0x80/0x80
> >> >>> > >[0.188000]  ? kernel_init+0xa/0x100
> >> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
> >> >>>
> >> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
> >> >>> So could you send us the handcrafted ACPI table or both the "acpidump 
> >> >>> -c on" and "acpidump -c off" output?
> >>
> >> I modified FACP, FACS, APIC table in VirtualBox for Linux.
> >> Here are raw dumps of table.
> >
> > So, excuse me, but what's the security issue here?
> >
> > You hacked your ACPI tables into pieces which requires root privileges 
> > anyway.
> >
> > Thanks,
> > Rafael
> >
> 
> As you mentioned earlier, I hacked my ACPI table for research, so it seems 
> that
> it is not a security issue.
> 
> But, if new mainboard are released and they have a vendor-specific ACPI table
> which has invalid data, the old version of kernel (<=4.9) will possibly expose
> kernel address and KASLR will be neutralized unintentionally.

But that would mean a basically non-functional system, so I'm not sure how
anyone can actually take advantage of the "KASLR neutralization".

> I know the vendors collaborate with Linux kernel developers, but the problem
> can still occur.
> 
> Hardware vendors release so many kinds of mainboard in a year, and the major
> Linux distros (Ubuntu, Fedora, etc.) will have 4.8 kernel for a long time.
> 
> For this reason, I think this issue has a security aspect.

Well, not quite IMO.

If the system needs ACPI tables and the kernel cannot use them, it just won't
work no matter what.

Thanks,
Rafael

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Friday, February 24, 2017 09:15:52 PM Seunghun Han wrote:
> Hi, Rafael.
> 
> I added my opinion below.
> 
> 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
> > On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> >> Hi, Lv Zheng.
> >>
> >> I added my handcrafted ACPI table under your request, because
> >> "acpidump -c on" and "acpidump -c off" doesn't work.
> >>
> >> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
> >> > Hello,
> >> >
> >> > I attached the test results below,
> >> >
> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >> >>> Hi,
> >> >>>
> >> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
> >> >>> > Han
> >> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >> >>> >
> >> >>> > I'm Seunghun Han, and I work for National Security Research 
> >> >>> > Institute of
> >> >>> > South Korea.
> >> >>> >
> >> >>> > I have been doing a research on ACPI and making a handcrafted ACPI 
> >> >>> > table
> >> >>> > for my research.
> >> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel 
> >> >>> > while boot
> >> >>> > process, and Linux kernel goes well without critical problems.
> >> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
> >> >>> >
> >> >>> > Boot log of ACPI operand cache leak is as follows:
> >> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> >> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
> >> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> >> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install 
> >> >>> > >System Control Interrupt handler
> >> >>> > (20160930/evevent-131)
> >> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
> >> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
> >> >>> > >(20160930/evmisc-281)
> >> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still 
> >> >>> > >has objects
> >> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 
> >> >>> > >#2
> >> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, 
> >> >>> > >BIOS VirtualBox 12/01/2006
> >> >>> > >[0.188000] Call Trace:
> >> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
> >> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
> >> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
> >> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
> >> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
> >> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
> >> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
> >> >>> > >[0.188000]  ? __class_create+0x4c/0x80
> >> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
> >> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
> >> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
> >> >>> > >[0.188000]  ? rest_init+0x80/0x80
> >> >>> > >[0.188000]  ? kernel_init+0xa/0x100
> >> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
> >> >>>
> >> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
> >> >>> So could you send us the handcrafted ACPI table or both the "acpidump 
> >> >>> -c on" and "acpidump -c off" output?
> >>
> >> I modified FACP, FACS, APIC table in VirtualBox for Linux.
> >> Here are raw dumps of table.
> >
> > So, excuse me, but what's the security issue here?
> >
> > You hacked your ACPI tables into pieces which requires root privileges 
> > anyway.
> >
> > Thanks,
> > Rafael
> >
> 
> As you mentioned earlier, I hacked my ACPI table for research, so it seems 
> that
> it is not a security issue.
> 
> But, if new mainboard are released and they have a vendor-specific ACPI table
> which has invalid data, the old version of kernel (<=4.9) will possibly expose
> kernel address and KASLR will be neutralized unintentionally.

But that would mean a basically non-functional system, so I'm not sure how
anyone can actually take advantage of the "KASLR neutralization".

> I know the vendors collaborate with Linux kernel developers, but the problem
> can still occur.
> 
> Hardware vendors release so many kinds of mainboard in a year, and the major
> Linux distros (Ubuntu, Fedora, etc.) will have 4.8 kernel for a long time.
> 
> For this reason, I think this issue has a security aspect.

Well, not quite IMO.

If the system needs ACPI tables and the kernel cannot use them, it just won't
work no matter what.

Thanks,
Rafael

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hi, Rafael.

I added my opinion below.

2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
> On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>> Hi, Lv Zheng.
>>
>> I added my handcrafted ACPI table under your request, because
>> "acpidump -c on" and "acpidump -c off" doesn't work.
>>
>> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
>> > Hello,
>> >
>> > I attached the test results below,
>> >
>> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
>> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>> >>> Hi,
>> >>>
>> >>> > From: linux-acpi-ow...@vger.kernel.org 
>> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>> >>> > Han
>> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>> >>> >
>> >>> > I'm Seunghun Han, and I work for National Security Research Institute 
>> >>> > of
>> >>> > South Korea.
>> >>> >
>> >>> > I have been doing a research on ACPI and making a handcrafted ACPI 
>> >>> > table
>> >>> > for my research.
>> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel 
>> >>> > while boot
>> >>> > process, and Linux kernel goes well without critical problems.
>> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
>> >>> >
>> >>> > Boot log of ACPI operand cache leak is as follows:
>> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install 
>> >>> > >System Control Interrupt handler
>> >>> > (20160930/evevent-131)
>> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>> >>> > >(20160930/evmisc-281)
>> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has 
>> >>> > >objects
>> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
>> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, 
>> >>> > >BIOS VirtualBox 12/01/2006
>> >>> > >[0.188000] Call Trace:
>> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
>> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
>> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
>> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
>> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
>> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
>> >>> > >[0.188000]  ? __class_create+0x4c/0x80
>> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
>> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
>> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
>> >>> > >[0.188000]  ? rest_init+0x80/0x80
>> >>> > >[0.188000]  ? kernel_init+0xa/0x100
>> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
>> >>>
>> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
>> >>> So could you send us the handcrafted ACPI table or both the "acpidump -c 
>> >>> on" and "acpidump -c off" output?
>>
>> I modified FACP, FACS, APIC table in VirtualBox for Linux.
>> Here are raw dumps of table.
>
> So, excuse me, but what's the security issue here?
>
> You hacked your ACPI tables into pieces which requires root privileges anyway.
>
> Thanks,
> Rafael
>

As you mentioned earlier, I hacked my ACPI table for research, so it seems that
it is not a security issue.

But, if new mainboard are released and they have a vendor-specific ACPI table
which has invalid data, the old version of kernel (<=4.9) will possibly expose
kernel address and KASLR will be neutralized unintentionally.

I know the vendors collaborate with Linux kernel developers, but the problem
can still occur.

Hardware vendors release so many kinds of mainboard in a year, and the major
Linux distros (Ubuntu, Fedora, etc.) will have 4.8 kernel for a long time.

For this reason, I think this issue has a security aspect.

Thank you.

Best regards.

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hi, Rafael.

I added my opinion below.

2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki :
> On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
>> Hi, Lv Zheng.
>>
>> I added my handcrafted ACPI table under your request, because
>> "acpidump -c on" and "acpidump -c off" doesn't work.
>>
>> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
>> > Hello,
>> >
>> > I attached the test results below,
>> >
>> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
>> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>> >>> Hi,
>> >>>
>> >>> > From: linux-acpi-ow...@vger.kernel.org 
>> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>> >>> > Han
>> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>> >>> >
>> >>> > I'm Seunghun Han, and I work for National Security Research Institute 
>> >>> > of
>> >>> > South Korea.
>> >>> >
>> >>> > I have been doing a research on ACPI and making a handcrafted ACPI 
>> >>> > table
>> >>> > for my research.
>> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel 
>> >>> > while boot
>> >>> > process, and Linux kernel goes well without critical problems.
>> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
>> >>> >
>> >>> > Boot log of ACPI operand cache leak is as follows:
>> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
>> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install 
>> >>> > >System Control Interrupt handler
>> >>> > (20160930/evevent-131)
>> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>> >>> > >(20160930/evmisc-281)
>> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has 
>> >>> > >objects
>> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
>> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, 
>> >>> > >BIOS VirtualBox 12/01/2006
>> >>> > >[0.188000] Call Trace:
>> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
>> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
>> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
>> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
>> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
>> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
>> >>> > >[0.188000]  ? __class_create+0x4c/0x80
>> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
>> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
>> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
>> >>> > >[0.188000]  ? rest_init+0x80/0x80
>> >>> > >[0.188000]  ? kernel_init+0xa/0x100
>> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
>> >>>
>> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
>> >>> So could you send us the handcrafted ACPI table or both the "acpidump -c 
>> >>> on" and "acpidump -c off" output?
>>
>> I modified FACP, FACS, APIC table in VirtualBox for Linux.
>> Here are raw dumps of table.
>
> So, excuse me, but what's the security issue here?
>
> You hacked your ACPI tables into pieces which requires root privileges anyway.
>
> Thanks,
> Rafael
>

As you mentioned earlier, I hacked my ACPI table for research, so it seems that
it is not a security issue.

But, if new mainboard are released and they have a vendor-specific ACPI table
which has invalid data, the old version of kernel (<=4.9) will possibly expose
kernel address and KASLR will be neutralized unintentionally.

I know the vendors collaborate with Linux kernel developers, but the problem
can still occur.

Hardware vendors release so many kinds of mainboard in a year, and the major
Linux distros (Ubuntu, Fedora, etc.) will have 4.8 kernel for a long time.

For this reason, I think this issue has a security aspect.

Thank you.

Best regards.

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> Hi, Lv Zheng.
> 
> I added my handcrafted ACPI table under your request, because
> "acpidump -c on" and "acpidump -c off" doesn't work.
> 
> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
> > Hello,
> >
> > I attached the test results below,
> >
> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >>> Hi,
> >>>
> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
> >>> > Han
> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >>> >
> >>> > I'm Seunghun Han, and I work for National Security Research Institute of
> >>> > South Korea.
> >>> >
> >>> > I have been doing a research on ACPI and making a handcrafted ACPI table
> >>> > for my research.
> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel 
> >>> > while boot
> >>> > process, and Linux kernel goes well without critical problems.
> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
> >>> >
> >>> > Boot log of ACPI operand cache leak is as follows:
> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install 
> >>> > >System Control Interrupt handler
> >>> > (20160930/evevent-131)
> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
> >>> > >(20160930/evmisc-281)
> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has 
> >>> > >objects
> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS 
> >>> > >VirtualBox 12/01/2006
> >>> > >[0.188000] Call Trace:
> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
> >>> > >[0.188000]  ? __class_create+0x4c/0x80
> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
> >>> > >[0.188000]  ? rest_init+0x80/0x80
> >>> > >[0.188000]  ? kernel_init+0xa/0x100
> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
> >>>
> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
> >>> So could you send us the handcrafted ACPI table or both the "acpidump -c 
> >>> on" and "acpidump -c off" output?
> 
> I modified FACP, FACS, APIC table in VirtualBox for Linux.
> Here are raw dumps of table.

So, excuse me, but what's the security issue here?

You hacked your ACPI tables into pieces which requires root privileges anyway.

Thanks,
Rafael

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Rafael J. Wysocki]

On Friday, February 24, 2017 08:52:42 PM Seunghun Han wrote:
> Hi, Lv Zheng.
> 
> I added my handcrafted ACPI table under your request, because
> "acpidump -c on" and "acpidump -c off" doesn't work.
> 
> 2017-02-21 19:36 GMT+09:00 Seunghun Han :
> > Hello,
> >
> > I attached the test results below,
> >
> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
> >>> Hi,
> >>>
> >>> > From: linux-acpi-ow...@vger.kernel.org 
> >>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
> >>> > Han
> >>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
> >>> >
> >>> > I'm Seunghun Han, and I work for National Security Research Institute of
> >>> > South Korea.
> >>> >
> >>> > I have been doing a research on ACPI and making a handcrafted ACPI table
> >>> > for my research.
> >>> > Errors of handcrafted ACPI tables are handled well in Linux kernel 
> >>> > while boot
> >>> > process, and Linux kernel goes well without critical problems.
> >>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
> >>> >
> >>> > Boot log of ACPI operand cache leak is as follows:
> >>> > >[0.174332] ACPI: Added _OSI(Module Device)
> >>> > >[0.175504] ACPI: Added _OSI(Processor Device)
> >>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
> >>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
> >>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
> >>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install 
> >>> > >System Control Interrupt handler
> >>> > (20160930/evevent-131)
> >>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
> >>> > >[0.181125] ACPI Error: Could not remove SCI handler 
> >>> > >(20160930/evmisc-281)
> >>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has 
> >>> > >objects
> >>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
> >>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS 
> >>> > >VirtualBox 12/01/2006
> >>> > >[0.188000] Call Trace:
> >>> > >[0.188000]  ? dump_stack+0x5c/0x7d
> >>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
> >>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
> >>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
> >>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
> >>> > >[0.188000]  ? acpi_terminate+0x5/0xf
> >>> > >[0.188000]  ? acpi_init+0x288/0x32e
> >>> > >[0.188000]  ? __class_create+0x4c/0x80
> >>> > >[0.188000]  ? video_setup+0x7a/0x7a
> >>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
> >>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
> >>> > >[0.188000]  ? rest_init+0x80/0x80
> >>> > >[0.188000]  ? kernel_init+0xa/0x100
> >>> > >[0.188000]  ? ret_from_fork+0x25/0x30
> >>>
> >>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
> >>> So could you send us the handcrafted ACPI table or both the "acpidump -c 
> >>> on" and "acpidump -c off" output?
> 
> I modified FACP, FACS, APIC table in VirtualBox for Linux.
> Here are raw dumps of table.

So, excuse me, but what's the security issue here?

You hacked your ACPI tables into pieces which requires root privileges anyway.

Thanks,
Rafael

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hi, Lv Zheng.

I added my handcrafted ACPI table under your request, because
"acpidump -c on" and "acpidump -c off" doesn't work.

2017-02-21 19:36 GMT+09:00 Seunghun Han :
> Hello,
>
> I attached the test results below,
>
> 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
>> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>>> Hi,
>>>
>>> > From: linux-acpi-ow...@vger.kernel.org 
>>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>>> > Han
>>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>>> >
>>> > I'm Seunghun Han, and I work for National Security Research Institute of
>>> > South Korea.
>>> >
>>> > I have been doing a research on ACPI and making a handcrafted ACPI table
>>> > for my research.
>>> > Errors of handcrafted ACPI tables are handled well in Linux kernel while 
>>> > boot
>>> > process, and Linux kernel goes well without critical problems.
>>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
>>> >
>>> > Boot log of ACPI operand cache leak is as follows:
>>> > >[0.174332] ACPI: Added _OSI(Module Device)
>>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install System 
>>> > >Control Interrupt handler
>>> > (20160930/evevent-131)
>>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>>> > >(20160930/evmisc-281)
>>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has 
>>> > >objects
>>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
>>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS 
>>> > >VirtualBox 12/01/2006
>>> > >[0.188000] Call Trace:
>>> > >[0.188000]  ? dump_stack+0x5c/0x7d
>>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
>>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
>>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
>>> > >[0.188000]  ? acpi_terminate+0x5/0xf
>>> > >[0.188000]  ? acpi_init+0x288/0x32e
>>> > >[0.188000]  ? __class_create+0x4c/0x80
>>> > >[0.188000]  ? video_setup+0x7a/0x7a
>>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
>>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
>>> > >[0.188000]  ? rest_init+0x80/0x80
>>> > >[0.188000]  ? kernel_init+0xa/0x100
>>> > >[0.188000]  ? ret_from_fork+0x25/0x30
>>>
>>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
>>> So could you send us the handcrafted ACPI table or both the "acpidump -c 
>>> on" and "acpidump -c off" output?

I modified FACP, FACS, APIC table in VirtualBox for Linux.
Here are raw dumps of table.

[0.00] ACPI: FACP 0xDFFF00F0 F4 (v04 VBOX
VBOXFACP 0001 ASL  0061)
[0.00] FACP DUMP
[0.00] 0x: 46 41 43 50 F4 00 00 00 04 60 56 42 4F 58 20 20
[0.00] 0x0010: 56 42 4F 58 46 41 43 50 01 00 00 00 41 53 4C 20
[0.00] 0x0020: 61 00 00 00 00 02 FF DF 80 04 FF DF 41 41 41 41
[0.00] 0x0030: 2E 44 00 00 A1 A0 00 00 00 40 00 00 00 00 00 00
[0.00] 0x0040: 04 40 00 00 00 00 00 00 00 00 00 00 08 40 00 00
[0.00] 0x0050: 20 40 00 00 00 00 00 00 04 02 00 04 02 00 00 00
[0.00] 0x0060: 65 00 E9 03 00 00 00 00 00 00 00 00 00 03 00 00
[0.00] 0x0070: 41 05 00 00 01 08 00 01 50 40 00 00 00 00 00 00
[0.00] 0x0080: 10 00 00 00 00 02 FF DF 00 00 00 00 80 04 FF DF
[0.00] 0x0090: 00 00 00 00 01 20 00 02 00 40 00 00 00 00 00 00
[0.00] 0x00A0: 00 00 00 00 00 00 00 00 00 00 00 00 01 10 00 02
[0.00] 0x00B0: 04 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[0.00] 0x00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[0.00] 0x00D0: 01 20 00 03 08 40 00 00 00 00 00 00 01 10 00 01
[0.00] 0x00E0: 20 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[0.00] 0x00F0: 00 00 00 00

[0.00] ACPI: FACS 0xDFFF0200 40
[0.00] FACS DUMP
[0.00] 0x: 46 41 43 53 40 00 00 00 00 00 00 00 00 00 00 00
[0.00] 0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[0.00] 0x0020: 01 00 00 00 00 00 00 00 00 41 00 00 00 00 00 00
[0.00] 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[0.00] ACPI: FACS 0xDFFF0200 40
[0.00] FACS DUMP
[0.00] 0x: 46 41 43 53 40 00 00 00 00 00 00 00 00 00 00 00
[0.00] 0x0010: 00 00 00 00 00 00 00 00 00 41 41 41 41 41 41 41
[0.00] 0x0020: 01 00 00 00 00 00 00 00 00 41 00 00 00 00 00 00
[0.00] 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[0.00] ACPI: APIC 0xDFFF0240 6C 

Re: [PATCH v2] acpi: acpica: fix acpi operand cache leak

[Seunghun Han]

Hi, Lv Zheng.

I added my handcrafted ACPI table under your request, because
"acpidump -c on" and "acpidump -c off" doesn't work.

2017-02-21 19:36 GMT+09:00 Seunghun Han :
> Hello,
>
> I attached the test results below,
>
> 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki :
>> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote:
>>> Hi,
>>>
>>> > From: linux-acpi-ow...@vger.kernel.org 
>>> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Seunghun
>>> > Han
>>> > Subject: [PATCH v2] acpi: acpica: fix acpi operand cache leak
>>> >
>>> > I'm Seunghun Han, and I work for National Security Research Institute of
>>> > South Korea.
>>> >
>>> > I have been doing a research on ACPI and making a handcrafted ACPI table
>>> > for my research.
>>> > Errors of handcrafted ACPI tables are handled well in Linux kernel while 
>>> > boot
>>> > process, and Linux kernel goes well without critical problems.
>>> > But I found some ACPI operand cache leaks in ACPI early abort cases.
>>> >
>>> > Boot log of ACPI operand cache leak is as follows:
>>> > >[0.174332] ACPI: Added _OSI(Module Device)
>>> > >[0.175504] ACPI: Added _OSI(Processor Device)
>>> > >[0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
>>> > >[0.177032] ACPI: Added _OSI(Processor Aggregator Device)
>>> > >[0.178284] ACPI: SCI (IRQ16705) allocation failed
>>> > >[0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install System 
>>> > >Control Interrupt handler
>>> > (20160930/evevent-131)
>>> > >[0.180008] ACPI: Unable to start the ACPI Interpreter
>>> > >[0.181125] ACPI Error: Could not remove SCI handler 
>>> > >(20160930/evmisc-281)
>>> > >[0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has 
>>> > >objects
>>> > >[0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
>>> > >[0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS 
>>> > >VirtualBox 12/01/2006
>>> > >[0.188000] Call Trace:
>>> > >[0.188000]  ? dump_stack+0x5c/0x7d
>>> > >[0.188000]  ? kmem_cache_destroy+0x224/0x230
>>> > >[0.188000]  ? acpi_sleep_proc_init+0x22/0x22
>>> > >[0.188000]  ? acpi_os_delete_cache+0xa/0xd
>>> > >[0.188000]  ? acpi_ut_delete_caches+0x3f/0x7b
>>> > >[0.188000]  ? acpi_terminate+0x5/0xf
>>> > >[0.188000]  ? acpi_init+0x288/0x32e
>>> > >[0.188000]  ? __class_create+0x4c/0x80
>>> > >[0.188000]  ? video_setup+0x7a/0x7a
>>> > >[0.188000]  ? do_one_initcall+0x4e/0x1b0
>>> > >[0.188000]  ? kernel_init_freeable+0x194/0x21a
>>> > >[0.188000]  ? rest_init+0x80/0x80
>>> > >[0.188000]  ? kernel_init+0xa/0x100
>>> > >[0.188000]  ? ret_from_fork+0x25/0x30
>>>
>>> I'm more interested in the way of triggering AE_NOT_ACQUIRED error.
>>> So could you send us the handcrafted ACPI table or both the "acpidump -c 
>>> on" and "acpidump -c off" output?

I modified FACP, FACS, APIC table in VirtualBox for Linux.
Here are raw dumps of table.

[0.00] ACPI: FACP 0xDFFF00F0 F4 (v04 VBOX
VBOXFACP 0001 ASL  0061)
[0.00] FACP DUMP
[0.00] 0x: 46 41 43 50 F4 00 00 00 04 60 56 42 4F 58 20 20
[0.00] 0x0010: 56 42 4F 58 46 41 43 50 01 00 00 00 41 53 4C 20
[0.00] 0x0020: 61 00 00 00 00 02 FF DF 80 04 FF DF 41 41 41 41
[0.00] 0x0030: 2E 44 00 00 A1 A0 00 00 00 40 00 00 00 00 00 00
[0.00] 0x0040: 04 40 00 00 00 00 00 00 00 00 00 00 08 40 00 00
[0.00] 0x0050: 20 40 00 00 00 00 00 00 04 02 00 04 02 00 00 00
[0.00] 0x0060: 65 00 E9 03 00 00 00 00 00 00 00 00 00 03 00 00
[0.00] 0x0070: 41 05 00 00 01 08 00 01 50 40 00 00 00 00 00 00
[0.00] 0x0080: 10 00 00 00 00 02 FF DF 00 00 00 00 80 04 FF DF
[0.00] 0x0090: 00 00 00 00 01 20 00 02 00 40 00 00 00 00 00 00
[0.00] 0x00A0: 00 00 00 00 00 00 00 00 00 00 00 00 01 10 00 02
[0.00] 0x00B0: 04 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[0.00] 0x00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[0.00] 0x00D0: 01 20 00 03 08 40 00 00 00 00 00 00 01 10 00 01
[0.00] 0x00E0: 20 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[0.00] 0x00F0: 00 00 00 00

[0.00] ACPI: FACS 0xDFFF0200 40
[0.00] FACS DUMP
[0.00] 0x: 46 41 43 53 40 00 00 00 00 00 00 00 00 00 00 00
[0.00] 0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[0.00] 0x0020: 01 00 00 00 00 00 00 00 00 41 00 00 00 00 00 00
[0.00] 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[0.00] ACPI: FACS 0xDFFF0200 40
[0.00] FACS DUMP
[0.00] 0x: 46 41 43 53 40 00 00 00 00 00 00 00 00 00 00 00
[0.00] 0x0010: 00 00 00 00 00 00 00 00 00 41 41 41 41 41 41 41
[0.00] 0x0020: 01 00 00 00 00 00 00 00 00 41 00 00 00 00 00 00
[0.00] 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[0.00] ACPI: APIC 0xDFFF0240 6C (v02 VBOX
VBOXAPIC 0001 ASL  0061)