| Message ID | 1487292003-25769-1-git-send-email-kkamagui@gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
Hi, > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@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? > > When early abort is occurred due to invalid ACPI information, Linux kernel > terminates ACPI by calling acpi_terminate() function. > The function calls acpi_ns_terminate() function to delete namespace data > and ACPI operand cache (acpi_gbl_module_code_list). > > But the deletion code in acpi_ns_terminate() function is wrapped in > ACPI_EXEC_APP definition, therefore the code is only executed when the > definition exists. > If the define doesn't exist, ACPI operand cache (acpi_gbl_module_code_list) is > leaked, and stack dump is shown in kernel log. > acpi_ns_terminate() actually shouldn't be invoked by Linux. It's not fully functioning in Linux kernel environment. > This causes a security threat because the old kernel (<= 4.9) shows memory > locations of kernel functions in stack dump, therefore kernel ASLR can be > neutralized. > > To fix ACPI operand leak for enhancing security, I made a patch which removes > the ACPI_EXEC_APP define in acpi_ns_terminate() function for executing the > deletion code unconditionally. However acpi_gbl_module_code_list deletion shouldn't be dependent on ACPI_EXEC_APP. So your change is acceptable. > > I hope that this patch improves the security of Linux kernel. > > Thank you. > > Signed-off-by: Seunghun Han <kkamagui@gmail.com> > --- > Changes since v1: move position of variables to remove compile warning. > > drivers/acpi/acpica/nsutils.c | 23 +++++++++-------------- > 1 file changed, 9 insertions(+), 14 deletions(-) > > diff --git a/drivers/acpi/acpica/nsutils.c b/drivers/acpi/acpica/nsutils.c > index 691814d..943702d 100644 > --- a/drivers/acpi/acpica/nsutils.c > +++ b/drivers/acpi/acpica/nsutils.c > @@ -594,25 +594,20 @@ struct acpi_namespace_node *acpi_ns_validate_handle(acpi_handle handle) > void acpi_ns_terminate(void) > { > acpi_status status; > + union acpi_operand_object *prev; > + union acpi_operand_object *next; > > ACPI_FUNCTION_TRACE(ns_terminate); > > -#ifdef ACPI_EXEC_APP > - { > - union acpi_operand_object *prev; > - union acpi_operand_object *next; > + /* Delete any module-level code blocks */ > > - /* Delete any module-level code blocks */ > - > - next = acpi_gbl_module_code_list; > - while (next) { > - prev = next; > - next = next->method.mutex; > - prev->method.mutex = NULL; /* Clear the Mutex (cheated) field */ > - acpi_ut_remove_reference(prev); > - } > + next = acpi_gbl_module_code_list; > + while (next) { > + prev = next; > + next = next->method.mutex; > + prev->method.mutex = NULL; /* Clear the Mutex (cheated) field */ > + acpi_ut_remove_reference(prev); > } > -#endif Thus this looks OK to me. > > /* > * Free the entire namespace -- all nodes and all objects > -- > 2.1.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: > Hi, > > > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@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? > > > > > When early abort is occurred due to invalid ACPI information, Linux kernel > > terminates ACPI by calling acpi_terminate() function. > > The function calls acpi_ns_terminate() function to delete namespace data > > and ACPI operand cache (acpi_gbl_module_code_list). > > > > But the deletion code in acpi_ns_terminate() function is wrapped in > > ACPI_EXEC_APP definition, therefore the code is only executed when the > > definition exists. > > If the define doesn't exist, ACPI operand cache (acpi_gbl_module_code_list) is > > leaked, and stack dump is shown in kernel log. > > > > acpi_ns_terminate() actually shouldn't be invoked by Linux. > It's not fully functioning in Linux kernel environment. > > > This causes a security threat because the old kernel (<= 4.9) shows memory > > locations of kernel functions in stack dump, therefore kernel ASLR can be > > neutralized. > > > > To fix ACPI operand leak for enhancing security, I made a patch which removes > > the ACPI_EXEC_APP define in acpi_ns_terminate() function for executing the > > deletion code unconditionally. > > However acpi_gbl_module_code_list deletion shouldn't be dependent on ACPI_EXEC_APP. > So your change is acceptable. > > > > > I hope that this patch improves the security of Linux kernel. > > > > Thank you. > > > > Signed-off-by: Seunghun Han <kkamagui@gmail.com> > > --- > > Changes since v1: move position of variables to remove compile warning. > > > > drivers/acpi/acpica/nsutils.c | 23 +++++++++-------------- > > 1 file changed, 9 insertions(+), 14 deletions(-) > > > > diff --git a/drivers/acpi/acpica/nsutils.c b/drivers/acpi/acpica/nsutils.c > > index 691814d..943702d 100644 > > --- a/drivers/acpi/acpica/nsutils.c > > +++ b/drivers/acpi/acpica/nsutils.c > > @@ -594,25 +594,20 @@ struct acpi_namespace_node *acpi_ns_validate_handle(acpi_handle handle) > > void acpi_ns_terminate(void) > > { > > acpi_status status; > > + union acpi_operand_object *prev; > > + union acpi_operand_object *next; > > > > ACPI_FUNCTION_TRACE(ns_terminate); > > > > -#ifdef ACPI_EXEC_APP > > - { > > - union acpi_operand_object *prev; > > - union acpi_operand_object *next; > > + /* Delete any module-level code blocks */ > > > > - /* Delete any module-level code blocks */ > > - > > - next = acpi_gbl_module_code_list; > > - while (next) { > > - prev = next; > > - next = next->method.mutex; > > - prev->method.mutex = NULL; /* Clear the Mutex (cheated) field */ > > - acpi_ut_remove_reference(prev); > > - } > > + next = acpi_gbl_module_code_list; > > + while (next) { > > + prev = next; > > + next = next->method.mutex; > > + prev->method.mutex = NULL; /* Clear the Mutex (cheated) field */ > > + acpi_ut_remove_reference(prev); > > } > > -#endif > > Thus this looks OK to me. > > > > > /* > > * Free the entire namespace -- all nodes and all objects > > -- > > 2.1.4 I still would prefer it to go in via the upstream. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello, I attached the test results below, 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <rjw@rjwysocki.net>: > On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: >> Hi, >> >> > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@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? Because of the ACPI interpreter error, ACPI function were terminated, so there is no directory "/proc/acpi". And when I typed the acpidump command, errors were shown. The error are as follows. root@debian:/proc# acpidump -c on Cannot open directory - /sys/firmware/acpi/tables Could not get ACPI tables, AE_NOT_FOUND root@debian:/proc# acpidump -c off Cannot open directory - /sys/firmware/acpi/tables Could not get ACPI tables, AE_NOT_FOUND Could you tell me another way to get information for you? Thank you. Best regards. >> > >> > When early abort is occurred due to invalid ACPI information, Linux kernel >> > terminates ACPI by calling acpi_terminate() function. >> > The function calls acpi_ns_terminate() function to delete namespace data >> > and ACPI operand cache (acpi_gbl_module_code_list). >> > >> > But the deletion code in acpi_ns_terminate() function is wrapped in >> > ACPI_EXEC_APP definition, therefore the code is only executed when the >> > definition exists. >> > If the define doesn't exist, ACPI operand cache (acpi_gbl_module_code_list) is >> > leaked, and stack dump is shown in kernel log. >> > >> >> acpi_ns_terminate() actually shouldn't be invoked by Linux. >> It's not fully functioning in Linux kernel environment. >> >> > This causes a security threat because the old kernel (<= 4.9) shows memory >> > locations of kernel functions in stack dump, therefore kernel ASLR can be >> > neutralized. >> > >> > To fix ACPI operand leak for enhancing security, I made a patch which removes >> > the ACPI_EXEC_APP define in acpi_ns_terminate() function for executing the >> > deletion code unconditionally. >> >> However acpi_gbl_module_code_list deletion shouldn't be dependent on ACPI_EXEC_APP. >> So your change is acceptable. >> >> > >> > I hope that this patch improves the security of Linux kernel. >> > >> > Thank you. >> > >> > Signed-off-by: Seunghun Han <kkamagui@gmail.com> >> > --- >> > Changes since v1: move position of variables to remove compile warning. >> > >> > drivers/acpi/acpica/nsutils.c | 23 +++++++++-------------- >> > 1 file changed, 9 insertions(+), 14 deletions(-) >> > >> > diff --git a/drivers/acpi/acpica/nsutils.c b/drivers/acpi/acpica/nsutils.c >> > index 691814d..943702d 100644 >> > --- a/drivers/acpi/acpica/nsutils.c >> > +++ b/drivers/acpi/acpica/nsutils.c >> > @@ -594,25 +594,20 @@ struct acpi_namespace_node *acpi_ns_validate_handle(acpi_handle handle) >> > void acpi_ns_terminate(void) >> > { >> > acpi_status status; >> > + union acpi_operand_object *prev; >> > + union acpi_operand_object *next; >> > >> > ACPI_FUNCTION_TRACE(ns_terminate); >> > >> > -#ifdef ACPI_EXEC_APP >> > - { >> > - union acpi_operand_object *prev; >> > - union acpi_operand_object *next; >> > + /* Delete any module-level code blocks */ >> > >> > - /* Delete any module-level code blocks */ >> > - >> > - next = acpi_gbl_module_code_list; >> > - while (next) { >> > - prev = next; >> > - next = next->method.mutex; >> > - prev->method.mutex = NULL; /* Clear the Mutex (cheated) field */ >> > - acpi_ut_remove_reference(prev); >> > - } >> > + next = acpi_gbl_module_code_list; >> > + while (next) { >> > + prev = next; >> > + next = next->method.mutex; >> > + prev->method.mutex = NULL; /* Clear the Mutex (cheated) field */ >> > + acpi_ut_remove_reference(prev); >> > } >> > -#endif >> >> Thus this looks OK to me. >> >> > >> > /* >> > * Free the entire namespace -- all nodes and all objects >> > -- >> > 2.1.4 > > I still would prefer it to go in via the upstream. > > Thanks, > Rafael > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <kkamagui@gmail.com>: > > Hello, > > > > I attached the test results below, > > > > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <rjw@rjwysocki.net>: > >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: > >>> Hi, > >>> > >>> > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <kkamagui@gmail.com>: > Hello, > > I attached the test results below, > > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <rjw@rjwysocki.net>: >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: >>> Hi, >>> >>> > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@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.000000] ACPI: FACP 0x00000000DFFF00F0 0000F4 (v04 VBOX VBOXFACP 00000001 ASL 00000061) [ 0.000000] FACP DUMP [ 0.000000] 0x0000: 46 41 43 50 F4 00 00 00 04 60 56 42 4F 58 20 20 [ 0.000000] 0x0010: 56 42 4F 58 46 41 43 50 01 00 00 00 41 53 4C 20 [ 0.000000] 0x0020: 61 00 00 00 00 02 FF DF 80 04 FF DF 41 41 41 41 [ 0.000000] 0x0030: 2E 44 00 00 A1 A0 00 00 00 40 00 00 00 00 00 00 [ 0.000000] 0x0040: 04 40 00 00 00 00 00 00 00 00 00 00 08 40 00 00 [ 0.000000] 0x0050: 20 40 00 00 00 00 00 00 04 02 00 04 02 00 00 00 [ 0.000000] 0x0060: 65 00 E9 03 00 00 00 00 00 00 00 00 00 03 00 00 [ 0.000000] 0x0070: 41 05 00 00 01 08 00 01 50 40 00 00 00 00 00 00 [ 0.000000] 0x0080: 10 00 00 00 00 02 FF DF 00 00 00 00 80 04 FF DF [ 0.000000] 0x0090: 00 00 00 00 01 20 00 02 00 40 00 00 00 00 00 00 [ 0.000000] 0x00A0: 00 00 00 00 00 00 00 00 00 00 00 00 01 10 00 02 [ 0.000000] 0x00B0: 04 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 0.000000] 0x00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 0.000000] 0x00D0: 01 20 00 03 08 40 00 00 00 00 00 00 01 10 00 01 [ 0.000000] 0x00E0: 20 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 0.000000] 0x00F0: 00 00 00 00 [ 0.000000] ACPI: FACS 0x00000000DFFF0200 000040 [ 0.000000] FACS DUMP [ 0.000000] 0x0000: 46 41 43 53 40 00 00 00 00 00 00 00 00 00 00 00 [ 0.000000] 0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 0.000000] 0x0020: 01 00 00 00 00 00 00 00 00 41 00 00 00 00 00 00 [ 0.000000] 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 0.000000] ACPI: FACS 0x00000000DFFF0200 000040 [ 0.000000] FACS DUMP [ 0.000000] 0x0000: 46 41 43 53 40 00 00 00 00 00 00 00 00 00 00 00 [ 0.000000] 0x0010: 00 00 00 00 00 00 00 00 00 41 41 41 41 41 41 41 [ 0.000000] 0x0020: 01 00 00 00 00 00 00 00 00 41 00 00 00 00 00 00 [ 0.000000] 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 0.000000] ACPI: APIC 0x00000000DFFF0240 00006C (v02 VBOX VBOXAPIC 00000001 ASL 00000061) [ 0.000000] APIC DUMP [ 0.000000] 0x0000: 41 50 49 43 6C 00 00 00 02 21 56 42 4F 58 20 20 [ 0.000000] 0x0010: 56 42 4F 58 41 50 49 43 01 00 00 00 41 53 4C 20 [ 0.000000] 0x0020: 61 00 00 00 00 00 E0 FE 01 00 00 00 02 0A 00 00 [ 0.000000] 0x0030: 02 00 00 00 00 00 02 0A 00 09 09 00 00 00 0D 00 [ 0.000000] 0x0040: 00 08 00 00 01 00 41 41 41 41 41 41 41 41 41 00 [ 0.000000] 0x0050: 00 08 02 02 01 00 00 00 00 08 03 03 01 00 00 00 [ 0.000000] 0x0060: 01 0C 04 00 00 00 C0 FE 00 00 00 00 If you need additional data, please let me know. Thank you. Best regards. > > Because of the ACPI interpreter error, ACPI function were terminated, > so there is no directory "/proc/acpi". > And when I typed the acpidump command, errors were shown. > > The error are as follows. > root@debian:/proc# acpidump -c on > Cannot open directory - /sys/firmware/acpi/tables > Could not get ACPI tables, AE_NOT_FOUND > > root@debian:/proc# acpidump -c off > Cannot open directory - /sys/firmware/acpi/tables > Could not get ACPI tables, AE_NOT_FOUND > > Could you tell me another way to get information for you? > Thank you. > > Best regards. > >>> > >>> > When early abort is occurred due to invalid ACPI information, Linux kernel >>> > terminates ACPI by calling acpi_terminate() function. >>> > The function calls acpi_ns_terminate() function to delete namespace data >>> > and ACPI operand cache (acpi_gbl_module_code_list). >>> > >>> > But the deletion code in acpi_ns_terminate() function is wrapped in >>> > ACPI_EXEC_APP definition, therefore the code is only executed when the >>> > definition exists. >>> > If the define doesn't exist, ACPI operand cache (acpi_gbl_module_code_list) is >>> > leaked, and stack dump is shown in kernel log. >>> > >>> >>> acpi_ns_terminate() actually shouldn't be invoked by Linux. >>> It's not fully functioning in Linux kernel environment. >>> >>> > This causes a security threat because the old kernel (<= 4.9) shows memory >>> > locations of kernel functions in stack dump, therefore kernel ASLR can be >>> > neutralized. >>> > >>> > To fix ACPI operand leak for enhancing security, I made a patch which removes >>> > the ACPI_EXEC_APP define in acpi_ns_terminate() function for executing the >>> > deletion code unconditionally. >>> >>> However acpi_gbl_module_code_list deletion shouldn't be dependent on ACPI_EXEC_APP. >>> So your change is acceptable. >>> >>> > >>> > I hope that this patch improves the security of Linux kernel. >>> > >>> > Thank you. >>> > >>> > Signed-off-by: Seunghun Han <kkamagui@gmail.com> >>> > --- >>> > Changes since v1: move position of variables to remove compile warning. >>> > >>> > drivers/acpi/acpica/nsutils.c | 23 +++++++++-------------- >>> > 1 file changed, 9 insertions(+), 14 deletions(-) >>> > >>> > diff --git a/drivers/acpi/acpica/nsutils.c b/drivers/acpi/acpica/nsutils.c >>> > index 691814d..943702d 100644 >>> > --- a/drivers/acpi/acpica/nsutils.c >>> > +++ b/drivers/acpi/acpica/nsutils.c >>> > @@ -594,25 +594,20 @@ struct acpi_namespace_node *acpi_ns_validate_handle(acpi_handle handle) >>> > void acpi_ns_terminate(void) >>> > { >>> > acpi_status status; >>> > + union acpi_operand_object *prev; >>> > + union acpi_operand_object *next; >>> > >>> > ACPI_FUNCTION_TRACE(ns_terminate); >>> > >>> > -#ifdef ACPI_EXEC_APP >>> > - { >>> > - union acpi_operand_object *prev; >>> > - union acpi_operand_object *next; >>> > + /* Delete any module-level code blocks */ >>> > >>> > - /* Delete any module-level code blocks */ >>> > - >>> > - next = acpi_gbl_module_code_list; >>> > - while (next) { >>> > - prev = next; >>> > - next = next->method.mutex; >>> > - prev->method.mutex = NULL; /* Clear the Mutex (cheated) field */ >>> > - acpi_ut_remove_reference(prev); >>> > - } >>> > + next = acpi_gbl_module_code_list; >>> > + while (next) { >>> > + prev = next; >>> > + next = next->method.mutex; >>> > + prev->method.mutex = NULL; /* Clear the Mutex (cheated) field */ >>> > + acpi_ut_remove_reference(prev); >>> > } >>> > -#endif >>> >>> Thus this looks OK to me. >>> >>> > >>> > /* >>> > * Free the entire namespace -- all nodes and all objects >>> > -- >>> > 2.1.4 >> >> I still would prefer it to go in via the upstream. >> >> Thanks, >> Rafael >> -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <rjw@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 <kkamagui@gmail.com>: > >> > Hello, > >> > > >> > I attached the test results below, > >> > > >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <rjw@rjwysocki.net>: > >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: > >> >>> Hi, > >> >>> > >> >>> > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Rafael. I added my opinion below. 2017-02-24 20:50 GMT+09:00 Rafael J. Wysocki <rjw@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 <kkamagui@gmail.com>: >> > Hello, >> > >> > I attached the test results below, >> > >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <rjw@rjwysocki.net>: >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: >> >>> Hi, >> >>> >> >>> > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@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. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Rafeal. I added my opinion below. 2017-02-24 21:13 GMT+09:00 Rafael J. Wysocki <rjw@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 <rjw@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 <kkamagui@gmail.com>: >> >> > Hello, >> >> > >> >> > I attached the test results below, >> >> > >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <rjw@rjwysocki.net>: >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: >> >> >>> Hi, >> >> >>> >> >> >>> > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@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 >> 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 > Yes, you are right. But, Linux kernel has well-defined exception handlers, so some systems may work fine like my test machine. Moreover the users may not recognize what the problem is, and I think that they will use the system in insecure status for a long time. Thank you. Best regards. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <rjw@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 <rjw@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 <kkamagui@gmail.com>: > >> >> > Hello, > >> >> > > >> >> > I attached the test results below, > >> >> > > >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <rjw@rjwysocki.net>: > >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: > >> >> >>> Hi, > >> >> >>> > >> >> >>> > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@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. If the system basically doesn't work, that information isn't particularly useful. > >> 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 > > > Yes, you are right. But, Linux kernel has well-defined exception handlers, so > some systems may work fine like my test machine. Moreover the users may not > recognize what the problem is, and I think that they will use the system in > insecure status for a long time. A virtual box or a guest can run without ACPI tables. A bare metal system where ACPI tables are necessary will be more-or-less unusable if the kernel cannot use them (it won't be able to detect interrupt controllers and the PCI host bridge just for starters). Running a guest with totally broken ACPI tables requires root privileges on the host. Running a bare metal system with totally broken ACPI tables (which seems to be your basic concern) may be a good research project, but nobody will do that in practice. And everybody who tries that will notice what's going on. Yes, you found a bug, but I still am not convinced about how this is security-related. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Rafael. I agree with you and I added my opinion below. 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki <rjw@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 <rjw@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 <rjw@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 <kkamagui@gmail.com>: >> >> >> > Hello, >> >> >> > >> >> >> > I attached the test results below, >> >> >> > >> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <rjw@rjwysocki.net>: >> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: >> >> >> >>> Hi, >> >> >> >>> >> >> >> >>> > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@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. > > If the system basically doesn't work, that information isn't particularly useful. > >> >> 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 >> > >> Yes, you are right. But, Linux kernel has well-defined exception handlers, so >> some systems may work fine like my test machine. Moreover the users may not >> recognize what the problem is, and I think that they will use the system in >> insecure status for a long time. > > A virtual box or a guest can run without ACPI tables. A bare metal system > where ACPI tables are necessary will be more-or-less unusable if the kernel > cannot use them (it won't be able to detect interrupt controllers and the PCI > host bridge just for starters). > > Running a guest with totally broken ACPI tables requires root privileges on the > host. Running a bare metal system with totally broken ACPI tables (which seems > to be your basic concern) may be a good research project, but nobody will do > that in practice. And everybody who tries that will notice what's going on. > > Yes, you found a bug, but I still am not convinced about how this is security-related. I totally agree with you that this case is not in practice now. I just started researching on ACPI, and I don't have enough ideas to occur a security problem using a bug. I just think that it has a little possibility which is security-related. Thank you so much for your guides. It helps me a lot to change my research direction. So, could my patch be merged in next kernel (4.11 rc-1)? or do I need to do something for it? Please let me know. Best regards. > > Thanks, > Rafael > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Feb 24, 2017 at 11:37 PM, Seunghun Han <kkamagui@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 <rjw@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 <rjw@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 <rjw@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 <kkamagui@gmail.com>: >>> >> >> > Hello, >>> >> >> > >>> >> >> > I attached the test results below, >>> >> >> > >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <rjw@rjwysocki.net>: >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: >>> >> >> >>> Hi, >>> >> >> >>> >>> >> >> >>> > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@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. >> >> If the system basically doesn't work, that information isn't particularly useful. >> >>> >> 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 >>> > >>> Yes, you are right. But, Linux kernel has well-defined exception handlers, so >>> some systems may work fine like my test machine. Moreover the users may not >>> recognize what the problem is, and I think that they will use the system in >>> insecure status for a long time. >> >> A virtual box or a guest can run without ACPI tables. A bare metal system >> where ACPI tables are necessary will be more-or-less unusable if the kernel >> cannot use them (it won't be able to detect interrupt controllers and the PCI >> host bridge just for starters). >> >> Running a guest with totally broken ACPI tables requires root privileges on the >> host. Running a bare metal system with totally broken ACPI tables (which seems >> to be your basic concern) may be a good research project, but nobody will do >> that in practice. And everybody who tries that will notice what's going on. >> >> Yes, you found a bug, but I still am not convinced about how this is security-related. > > I totally agree with you that this case is not in practice now. > I just started researching on ACPI, and I don't have enough ideas to occur > a security problem using a bug. I just think that it has a little possibility > which is security-related. > > Thank you so much for your guides. > It helps me a lot to change my research direction. > > So, could my patch be merged in next kernel (4.11 rc-1)? or do I need to do > something for it? > Please let me know. Generally, ACPICA patches (and this is one of them) have to go in via the upstream ACPICA project maintained by Bob Moore and Lv. Please see MAINTAINERS for pointers to the mailing list etc. Lv, can you please advise on the next steps? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Rafael > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@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 <kkamagui@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 <rjw@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 <rjw@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 <rjw@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 <kkamagui@gmail.com>: > >>> >> >> > Hello, > >>> >> >> > > >>> >> >> > I attached the test results below, > >>> >> >> > > >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <rjw@rjwysocki.net>: > >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: > >>> >> >> >>> Hi, > >>> >> >> >>> > >>> >> >> >>> > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@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. > >> > >> If the system basically doesn't work, that information isn't particularly useful. > >> > >>> >> 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 > >>> > > >>> Yes, you are right. But, Linux kernel has well-defined exception handlers, so > >>> some systems may work fine like my test machine. Moreover the users may not > >>> recognize what the problem is, and I think that they will use the system in > >>> insecure status for a long time. > >> > >> A virtual box or a guest can run without ACPI tables. A bare metal system > >> where ACPI tables are necessary will be more-or-less unusable if the kernel > >> cannot use them (it won't be able to detect interrupt controllers and the PCI > >> host bridge just for starters). > >> > >> Running a guest with totally broken ACPI tables requires root privileges on the > >> host. Running a bare metal system with totally broken ACPI tables (which seems > >> to be your basic concern) may be a good research project, but nobody will do > >> that in practice. And everybody who tries that will notice what's going on. > >> > >> Yes, you found a bug, but I still am not convinced about how this is security-related. > > > > I totally agree with you that this case is not in practice now. > > I just started researching on ACPI, and I don't have enough ideas to occur > > a security problem using a bug. I just think that it has a little possibility > > which is security-related. > > > > Thank you so much for your guides. > > It helps me a lot to change my research direction. > > > > So, could my patch be merged in next kernel (4.11 rc-1)? or do I need to do > > something for it? > > Please let me know. > > Generally, ACPICA patches (and this is one of them) have to go in via > the upstream ACPICA project maintained by Bob Moore and Lv. Please > see MAINTAINERS for pointers to the mailing list etc. > > Lv, can you please advise on the next steps? I already gave my advices. The fix was OK to me and I back ported it to ACPICA: https://github.com/acpica/acpica/pull/206 However it fixes a code path that in theory shouldn't be invoked in Linux kernel. But anyway it was merged and you will see it in the next ACPICA release. I asked Han for the handcrafted ACPI table. And obtained that: ACPI: FACP 0x00000000DFFF00F0 0000F4 (v04 VBOX VBOXFACP 00000001 ASL 00000061) 0x0000: 46 41 43 50 F4 00 00 00 04 60 56 42 4F 58 20 20 0x0010: 56 42 4F 58 46 41 43 50 01 00 00 00 41 53 4C 20 0x0020: 61 00 00 00 00 02 FF DF 80 04 FF DF 41 41 41 41 0x0030: 2E 44 00 00 A1 A0 00 00 00 40 00 00 00 00 00 00 0x0040: 04 40 00 00 00 00 00 00 00 00 00 00 08 40 00 00 0x0050: 20 40 00 00 00 00 00 00 04 02 00 04 02 00 00 00 0x0060: 65 00 E9 03 00 00 00 00 00 00 00 00 00 03 00 00 0x0070: 41 05 00 00 01 08 00 01 50 40 00 00 00 00 00 00 0x0080: 10 00 00 00 00 02 FF DF 00 00 00 00 80 04 FF DF 0x0090: 00 00 00 00 01 20 00 02 00 40 00 00 00 00 00 00 0x00A0: 00 00 00 00 00 00 00 00 00 00 00 00 01 10 00 02 0x00B0: 04 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00D0: 01 20 00 03 08 40 00 00 00 00 00 00 01 10 00 01 0x00E0: 20 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00F0: 00 00 00 00 ACPI: FACS 0x00000000DFFF0200 000040 0x0000: 46 41 43 53 40 00 00 00 00 00 00 00 00 00 00 00 0x0010: 00 00 00 00 00 00 00 00 00 41 41 41 41 41 41 41 0x0020: 01 00 00 00 00 00 00 00 00 41 00 00 00 00 00 00 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ACPI: APIC 0x00000000DFFF0240 00006C (v02 VBOX VBOXAPIC 00000001 ASL 00000061) 0x0000: 41 50 49 43 6C 00 00 00 02 21 56 42 4F 58 20 20 0x0010: 56 42 4F 58 41 50 49 43 01 00 00 00 41 53 4C 20 0x0020: 61 00 00 00 00 00 E0 FE 01 00 00 00 02 0A 00 00 0x0030: 02 00 00 00 00 00 02 0A 00 09 09 00 00 00 0D 00 0x0040: 00 08 00 00 01 00 41 41 41 41 41 41 41 41 41 00 0x0050: 00 08 02 02 01 00 00 00 00 08 03 03 01 00 00 00 0x0060: 01 0C 04 00 00 00 C0 FE 00 00 00 00 Where there is still no AML tables and the failure in the patch description seems to be related to the AML tables. So I'm still not aware of what the "handcrafted tables" meant to us and what the problem was. Thanks and best regards Lv > > Thanks, > Rafael > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday, February 27, 2017 02:45:50 AM Zheng, Lv wrote: > Hi, Rafael > > > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@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 <kkamagui@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 <rjw@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 <rjw@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 <rjw@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 <kkamagui@gmail.com>: > > >>> >> >> > Hello, > > >>> >> >> > > > >>> >> >> > I attached the test results below, > > >>> >> >> > > > >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <rjw@rjwysocki.net>: > > >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: > > >>> >> >> >>> Hi, > > >>> >> >> >>> > > >>> >> >> >>> > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@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. > > >> > > >> If the system basically doesn't work, that information isn't particularly useful. > > >> > > >>> >> 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 > > >>> > > > >>> Yes, you are right. But, Linux kernel has well-defined exception handlers, so > > >>> some systems may work fine like my test machine. Moreover the users may not > > >>> recognize what the problem is, and I think that they will use the system in > > >>> insecure status for a long time. > > >> > > >> A virtual box or a guest can run without ACPI tables. A bare metal system > > >> where ACPI tables are necessary will be more-or-less unusable if the kernel > > >> cannot use them (it won't be able to detect interrupt controllers and the PCI > > >> host bridge just for starters). > > >> > > >> Running a guest with totally broken ACPI tables requires root privileges on the > > >> host. Running a bare metal system with totally broken ACPI tables (which seems > > >> to be your basic concern) may be a good research project, but nobody will do > > >> that in practice. And everybody who tries that will notice what's going on. > > >> > > >> Yes, you found a bug, but I still am not convinced about how this is security-related. > > > > > > I totally agree with you that this case is not in practice now. > > > I just started researching on ACPI, and I don't have enough ideas to occur > > > a security problem using a bug. I just think that it has a little possibility > > > which is security-related. > > > > > > Thank you so much for your guides. > > > It helps me a lot to change my research direction. > > > > > > So, could my patch be merged in next kernel (4.11 rc-1)? or do I need to do > > > something for it? > > > Please let me know. > > > > Generally, ACPICA patches (and this is one of them) have to go in via > > the upstream ACPICA project maintained by Bob Moore and Lv. Please > > see MAINTAINERS for pointers to the mailing list etc. > > > > Lv, can you please advise on the next steps? > > I already gave my advices. > The fix was OK to me and I back ported it to ACPICA: > https://github.com/acpica/acpica/pull/206 > However it fixes a code path that in theory shouldn't be invoked in Linux kernel. > But anyway it was merged and you will see it in the next ACPICA release. Thank you! Best, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.zheng@intel.com>: > Hi, Rafael > >> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@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 <kkamagui@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 <rjw@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 <rjw@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 <rjw@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 <kkamagui@gmail.com>: >> >>> >> >> > Hello, >> >>> >> >> > >> >>> >> >> > I attached the test results below, >> >>> >> >> > >> >>> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <rjw@rjwysocki.net>: >> >>> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: >> >>> >> >> >>> Hi, >> >>> >> >> >>> >> >>> >> >> >>> > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@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. >> >> >> >> If the system basically doesn't work, that information isn't particularly useful. >> >> >> >>> >> 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 >> >>> > >> >>> Yes, you are right. But, Linux kernel has well-defined exception handlers, so >> >>> some systems may work fine like my test machine. Moreover the users may not >> >>> recognize what the problem is, and I think that they will use the system in >> >>> insecure status for a long time. >> >> >> >> A virtual box or a guest can run without ACPI tables. A bare metal system >> >> where ACPI tables are necessary will be more-or-less unusable if the kernel >> >> cannot use them (it won't be able to detect interrupt controllers and the PCI >> >> host bridge just for starters). >> >> >> >> Running a guest with totally broken ACPI tables requires root privileges on the >> >> host. Running a bare metal system with totally broken ACPI tables (which seems >> >> to be your basic concern) may be a good research project, but nobody will do >> >> that in practice. And everybody who tries that will notice what's going on. >> >> >> >> Yes, you found a bug, but I still am not convinced about how this is security-related. >> > >> > I totally agree with you that this case is not in practice now. >> > I just started researching on ACPI, and I don't have enough ideas to occur >> > a security problem using a bug. I just think that it has a little possibility >> > which is security-related. >> > >> > Thank you so much for your guides. >> > It helps me a lot to change my research direction. >> > >> > So, could my patch be merged in next kernel (4.11 rc-1)? or do I need to do >> > something for it? >> > Please let me know. >> >> Generally, ACPICA patches (and this is one of them) have to go in via >> the upstream ACPICA project maintained by Bob Moore and Lv. Please >> see MAINTAINERS for pointers to the mailing list etc. >> >> Lv, can you please advise on the next steps? > > I already gave my advices. > The fix was OK to me and I back ported it to ACPICA: > https://github.com/acpica/acpica/pull/206 > However it fixes a code path that in theory shouldn't be invoked in Linux kernel. > But anyway it was merged and you will see it in the next ACPICA release. > > I asked Han for the handcrafted ACPI table. > And obtained that: > ACPI: FACP 0x00000000DFFF00F0 0000F4 (v04 VBOX VBOXFACP 00000001 ASL 00000061) > 0x0000: 46 41 43 50 F4 00 00 00 04 60 56 42 4F 58 20 20 > 0x0010: 56 42 4F 58 46 41 43 50 01 00 00 00 41 53 4C 20 > 0x0020: 61 00 00 00 00 02 FF DF 80 04 FF DF 41 41 41 41 > 0x0030: 2E 44 00 00 A1 A0 00 00 00 40 00 00 00 00 00 00 > 0x0040: 04 40 00 00 00 00 00 00 00 00 00 00 08 40 00 00 > 0x0050: 20 40 00 00 00 00 00 00 04 02 00 04 02 00 00 00 > 0x0060: 65 00 E9 03 00 00 00 00 00 00 00 00 00 03 00 00 > 0x0070: 41 05 00 00 01 08 00 01 50 40 00 00 00 00 00 00 > 0x0080: 10 00 00 00 00 02 FF DF 00 00 00 00 80 04 FF DF > 0x0090: 00 00 00 00 01 20 00 02 00 40 00 00 00 00 00 00 > 0x00A0: 00 00 00 00 00 00 00 00 00 00 00 00 01 10 00 02 > 0x00B0: 04 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00D0: 01 20 00 03 08 40 00 00 00 00 00 00 01 10 00 01 > 0x00E0: 20 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00F0: 00 00 00 00 > > ACPI: FACS 0x00000000DFFF0200 000040 > 0x0000: 46 41 43 53 40 00 00 00 00 00 00 00 00 00 00 00 > 0x0010: 00 00 00 00 00 00 00 00 00 41 41 41 41 41 41 41 > 0x0020: 01 00 00 00 00 00 00 00 00 41 00 00 00 00 00 00 > 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > ACPI: APIC 0x00000000DFFF0240 00006C (v02 VBOX VBOXAPIC 00000001 ASL 00000061) > 0x0000: 41 50 49 43 6C 00 00 00 02 21 56 42 4F 58 20 20 > 0x0010: 56 42 4F 58 41 50 49 43 01 00 00 00 41 53 4C 20 > 0x0020: 61 00 00 00 00 00 E0 FE 01 00 00 00 02 0A 00 00 > 0x0030: 02 00 00 00 00 00 02 0A 00 09 09 00 00 00 0D 00 > 0x0040: 00 08 00 00 01 00 41 41 41 41 41 41 41 41 41 00 > 0x0050: 00 08 02 02 01 00 00 00 00 08 03 03 01 00 00 00 > 0x0060: 01 0C 04 00 00 00 C0 FE 00 00 00 00 > > Where there is still no AML tables and the failure in the patch description seems to be related to the AML tables. > So I'm still not aware of what the "handcrafted tables" meant to us and what the problem was. Actually, I did not change DSDT and SSDT. I changed only FACP, FACS and APIC for my handcrafted ACPI table. I have analyzed the root cause of the problem, and I have found that my handcrafted ACPI table has too big SCI IRQ (like 16705). So, acpi_os_install_interrupt_handler() which is called by acpi_enable_subsystem() was failed and returned AE_NOT_ACQUIRED (0x14) with "ACPI: SCI (IRQ16705) allocation failed" log. Because of error code, acpi_bus_init(), the caller of acpi_enable_subsystem(), showed "Unable to start the ACPI Interpreter" and called acpi_terminate() for exception handling. After calling acpi_terminate(), as you know, cache leak occurred. This means that error of acpi_load_tables(), acpi_initialize_objects(), acpi_bus_init_irq() and acpi_install_notify_handler() which are called by acpi_bus_init() can cause cache leak. If you want to see this error handling sequence, I suggest you that you change the code of acpi_os_install_interrupt_handler() to return AE_NOT_ACQUIRED immediately. Then, you can see the error handling sequence without my handcrafted ACPI table. I you want additional information about this, please let me know. Best regards. > > Thanks and best regards > Lv > >> >> Thanks, >> Rafael >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SGksIA0KDQo+IEZyb206IFNldW5naHVuIEhhbiBbbWFpbHRvOmtrYW1hZ3VpQGdtYWlsLmNvbV0N Cj4gU3ViamVjdDogUmU6IFtQQVRDSCB2Ml0gYWNwaTogYWNwaWNhOiBmaXggYWNwaSBvcGVyYW5k IGNhY2hlIGxlYWsNCj4gDQo+IEhlbGxvLCBMdiBhbmQgUmFmYWVsLg0KPiANCj4gSSBjaGVja2Vk IHRoYXQgbXkgcGF0Y2ggd2FzIG1lcmdlZCB0byBBQ1BJQ0EgcHJvamVjdC4NCj4gVGhhbmsgeW91 IGZvciB5b3VyIG5vdGljZS4NCj4gDQo+IEkgYWRkZWQgYW4gYW5hbHlzaXMgcmVwb3J0IHdoaWNo IGhhcyB0aGUgcm9vdCBjYXVzZSBvZiB0aGlzIHByb2JsZW0gYmVsb3cuDQo+IA0KPiAyMDE3LTAy LTI3IDExOjQ1IEdNVCswOTowMCBaaGVuZywgTHYgPGx2LnpoZW5nQGludGVsLmNvbT46DQo+ID4g SGksIFJhZmFlbA0KPiA+DQo+ID4+IEZyb206IGxpbnV4LWFjcGktb3duZXJAdmdlci5rZXJuZWwu b3JnIFttYWlsdG86bGludXgtYWNwaS1vd25lckB2Z2VyLmtlcm5lbC5vcmddIE9uIEJlaGFsZiBP Zg0KPiBSYWZhZWwgSi4NCj4gPj4gV3lzb2NraQ0KPiA+PiBTdWJqZWN0OiBSZTogW1BBVENIIHYy XSBhY3BpOiBhY3BpY2E6IGZpeCBhY3BpIG9wZXJhbmQgY2FjaGUgbGVhaw0KPiA+Pg0KPiA+PiBP biBGcmksIEZlYiAyNCwgMjAxNyBhdCAxMTozNyBQTSwgU2V1bmdodW4gSGFuIDxra2FtYWd1aUBn bWFpbC5jb20+IHdyb3RlOg0KPiA+PiA+IEhpLCBSYWZhZWwuDQo+ID4+ID4NCj4gPj4gPiBJIGFn cmVlIHdpdGggeW91IGFuZCBJIGFkZGVkIG15IG9waW5pb24gYmVsb3cuDQo+ID4+ID4NCj4gPj4g PiAyMDE3LTAyLTI1IDE6NTAgR01UKzA5OjAwIFJhZmFlbCBKLiBXeXNvY2tpIDxyandAcmp3eXNv Y2tpLm5ldD46DQo+ID4+ID4+IE9uIEZyaWRheSwgRmVicnVhcnkgMjQsIDIwMTcgMDk6NTY6MjEg UE0gU2V1bmdodW4gSGFuIHdyb3RlOg0KPiA+PiA+Pj4gSGksIFJhZmVhbC4NCj4gPj4gPj4+DQo+ ID4+ID4+PiBJIGFkZGVkIG15IG9waW5pb24gYmVsb3cuDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gMjAx Ny0wMi0yNCAyMToxMyBHTVQrMDk6MDAgUmFmYWVsIEouIFd5c29ja2kgPHJqd0Byand5c29ja2ku bmV0PjoNCj4gPj4gPj4+ID4gT24gRnJpZGF5LCBGZWJydWFyeSAyNCwgMjAxNyAwOToxNTo1MiBQ TSBTZXVuZ2h1biBIYW4gd3JvdGU6DQo+ID4+ID4+PiA+PiBIaSwgUmFmYWVsLg0KPiA+PiA+Pj4g Pj4NCj4gPj4gPj4+ID4+IEkgYWRkZWQgbXkgb3BpbmlvbiBiZWxvdy4NCj4gPj4gPj4+ID4+DQo+ ID4+ID4+PiA+PiAyMDE3LTAyLTI0IDIwOjUwIEdNVCswOTowMCBSYWZhZWwgSi4gV3lzb2NraSA8 cmp3QHJqd3lzb2NraS5uZXQ+Og0KPiA+PiA+Pj4gPj4gPiBPbiBGcmlkYXksIEZlYnJ1YXJ5IDI0 LCAyMDE3IDA4OjUyOjQyIFBNIFNldW5naHVuIEhhbiB3cm90ZToNCj4gPj4gPj4+ID4+ID4+IEhp LCBMdiBaaGVuZy4NCj4gPj4gPj4+ID4+ID4+DQo+ID4+ID4+PiA+PiA+PiBJIGFkZGVkIG15IGhh bmRjcmFmdGVkIEFDUEkgdGFibGUgdW5kZXIgeW91ciByZXF1ZXN0LCBiZWNhdXNlDQo+ID4+ID4+ PiA+PiA+PiAiYWNwaWR1bXAgLWMgb24iIGFuZCAiYWNwaWR1bXAgLWMgb2ZmIiBkb2Vzbid0IHdv cmsuDQo+ID4+ID4+PiA+PiA+Pg0KPiA+PiA+Pj4gPj4gPj4gMjAxNy0wMi0yMSAxOTozNiBHTVQr MDk6MDAgU2V1bmdodW4gSGFuIDxra2FtYWd1aUBnbWFpbC5jb20+Og0KPiA+PiA+Pj4gPj4gPj4g PiBIZWxsbywNCj4gPj4gPj4+ID4+ID4+ID4NCj4gPj4gPj4+ID4+ID4+ID4gSSBhdHRhY2hlZCB0 aGUgdGVzdCByZXN1bHRzIGJlbG93LA0KPiA+PiA+Pj4gPj4gPj4gPg0KPiA+PiA+Pj4gPj4gPj4g PiAyMDE3LTAyLTIxIDk6NTMgR01UKzA5OjAwIFJvd2FmYWVsIEouIFd5c29ja2kgPHJqd0Byand5 c29ja2kubmV0PjoNCj4gPj4gPj4+ID4+ID4+ID4+IE9uIFR1ZXNkYXksIEZlYnJ1YXJ5IDIxLCAy MDE3IDEyOjMzOjA4IEFNIFpoZW5nLCBMdiB3cm90ZToNCj4gPj4gPj4+ID4+ID4+ID4+PiBIaSwN Cj4gPj4gPj4+ID4+ID4+ID4+Pg0KPiA+PiA+Pj4gPj4gPj4gPj4+ID4gRnJvbTogbGludXgtYWNw aS1vd25lckB2Z2VyLmtlcm5lbC5vcmcgW21haWx0bzpsaW51eC1hY3BpLW93bmVyQHZnZXIua2Vy bmVsLm9yZ10gT24NCj4gPj4gQmVoYWxmIE9mIFNldW5naHVuDQo+ID4+ID4+PiA+PiA+PiA+Pj4g PiBIYW4NCj4gPj4gPj4+ID4+ID4+ID4+PiA+IFN1YmplY3Q6IFtQQVRDSCB2Ml0gYWNwaTogYWNw aWNhOiBmaXggYWNwaSBvcGVyYW5kIGNhY2hlIGxlYWsNCj4gPj4gPj4+ID4+ID4+ID4+PiA+DQo+ ID4+ID4+PiA+PiA+PiA+Pj4gPiBJJ20gU2V1bmdodW4gSGFuLCBhbmQgSSB3b3JrIGZvciBOYXRp b25hbCBTZWN1cml0eSBSZXNlYXJjaCBJbnN0aXR1dGUgb2YNCj4gPj4gPj4+ID4+ID4+ID4+PiA+ IFNvdXRoIEtvcmVhLg0KPiA+PiA+Pj4gPj4gPj4gPj4+ID4NCj4gPj4gPj4+ID4+ID4+ID4+PiA+ IEkgaGF2ZSBiZWVuIGRvaW5nIGEgcmVzZWFyY2ggb24gQUNQSSBhbmQgbWFraW5nIGEgaGFuZGNy YWZ0ZWQgQUNQSSB0YWJsZQ0KPiA+PiA+Pj4gPj4gPj4gPj4+ID4gZm9yIG15IHJlc2VhcmNoLg0K PiA+PiA+Pj4gPj4gPj4gPj4+ID4gRXJyb3JzIG9mIGhhbmRjcmFmdGVkIEFDUEkgdGFibGVzIGFy ZSBoYW5kbGVkIHdlbGwgaW4gTGludXgga2VybmVsIHdoaWxlIGJvb3QNCj4gPj4gPj4+ID4+ID4+ ID4+PiA+IHByb2Nlc3MsIGFuZCBMaW51eCBrZXJuZWwgZ29lcyB3ZWxsIHdpdGhvdXQgY3JpdGlj YWwgcHJvYmxlbXMuDQo+ID4+ID4+PiA+PiA+PiA+Pj4gPiBCdXQgSSBmb3VuZCBzb21lIEFDUEkg b3BlcmFuZCBjYWNoZSBsZWFrcyBpbiBBQ1BJIGVhcmx5IGFib3J0IGNhc2VzLg0KPiA+PiA+Pj4g Pj4gPj4gPj4+ID4NCj4gPj4gPj4+ID4+ID4+ID4+PiA+IEJvb3QgbG9nIG9mIEFDUEkgb3BlcmFu ZCBjYWNoZSBsZWFrIGlzIGFzIGZvbGxvd3M6DQo+ID4+ID4+PiA+PiA+PiA+Pj4gPiA+WyAgICAw LjE3NDMzMl0gQUNQSTogQWRkZWQgX09TSShNb2R1bGUgRGV2aWNlKQ0KPiA+PiA+Pj4gPj4gPj4g Pj4+ID4gPlsgICAgMC4xNzU1MDRdIEFDUEk6IEFkZGVkIF9PU0koUHJvY2Vzc29yIERldmljZSkN Cj4gPj4gPj4+ID4+ID4+ID4+PiA+ID5bICAgIDAuMTc2MDEwXSBBQ1BJOiBBZGRlZCBfT1NJKDMu MCBfU0NQIEV4dGVuc2lvbnMpDQo+ID4+ID4+PiA+PiA+PiA+Pj4gPiA+WyAgICAwLjE3NzAzMl0g QUNQSTogQWRkZWQgX09TSShQcm9jZXNzb3IgQWdncmVnYXRvciBEZXZpY2UpDQo+ID4+ID4+PiA+ PiA+PiA+Pj4gPiA+WyAgICAwLjE3ODI4NF0gQUNQSTogU0NJIChJUlExNjcwNSkgYWxsb2NhdGlv biBmYWlsZWQNCj4gPj4gPj4+ID4+ID4+ID4+PiA+ID5bICAgIDAuMTc5MzUyXSBBQ1BJIEV4Y2Vw dGlvbjogQUVfTk9UX0FDUVVJUkVELCBVbmFibGUgdG8gaW5zdGFsbCBTeXN0ZW0gQ29udHJvbA0K PiA+PiBJbnRlcnJ1cHQgaGFuZGxlcg0KPiA+PiA+Pj4gPj4gPj4gPj4+ID4gKDIwMTYwOTMwL2V2 ZXZlbnQtMTMxKQ0KPiA+PiA+Pj4gPj4gPj4gPj4+ID4gPlsgICAgMC4xODAwMDhdIEFDUEk6IFVu YWJsZSB0byBzdGFydCB0aGUgQUNQSSBJbnRlcnByZXRlcg0KPiA+PiA+Pj4gPj4gPj4gPj4+ID4g PlsgICAgMC4xODExMjVdIEFDUEkgRXJyb3I6IENvdWxkIG5vdCByZW1vdmUgU0NJIGhhbmRsZXIg KDIwMTYwOTMwL2V2bWlzYy0yODEpDQo+ID4+ID4+PiA+PiA+PiA+Pj4gPiA+WyAgICAwLjE4NDA2 OF0ga21lbV9jYWNoZV9kZXN0cm95IEFjcGktT3BlcmFuZDogU2xhYiBjYWNoZSBzdGlsbCBoYXMg b2JqZWN0cw0KPiA+PiA+Pj4gPj4gPj4gPj4+ID4gPlsgICAgMC4xODUzNThdIENQVTogMCBQSUQ6 IDEgQ29tbTogc3dhcHBlci8wIE5vdCB0YWludGVkIDQuMTAuMC1yYzMgIzINCj4gPj4gPj4+ID4+ ID4+ID4+PiA+ID5bICAgIDAuMTg2ODIwXSBIYXJkd2FyZSBuYW1lOiBpbm5vdGVrIEdtYkggVmly dHVhbEJveC9WaXJ0dWFsQm94LCBCSU9TIFZpcnR1YWxCb3gNCj4gPj4gMTIvMDEvMjAwNg0KPiA+ PiA+Pj4gPj4gPj4gPj4+ID4gPlsgICAgMC4xODgwMDBdIENhbGwgVHJhY2U6DQo+ID4+ID4+PiA+ PiA+PiA+Pj4gPiA+WyAgICAwLjE4ODAwMF0gID8gZHVtcF9zdGFjaysweDVjLzB4N2QNCj4gPj4g Pj4+ID4+ID4+ID4+PiA+ID5bICAgIDAuMTg4MDAwXSAgPyBrbWVtX2NhY2hlX2Rlc3Ryb3krMHgy MjQvMHgyMzANCj4gPj4gPj4+ID4+ID4+ID4+PiA+ID5bICAgIDAuMTg4MDAwXSAgPyBhY3BpX3Ns ZWVwX3Byb2NfaW5pdCsweDIyLzB4MjINCj4gPj4gPj4+ID4+ID4+ID4+PiA+ID5bICAgIDAuMTg4 MDAwXSAgPyBhY3BpX29zX2RlbGV0ZV9jYWNoZSsweGEvMHhkDQo+ID4+ID4+PiA+PiA+PiA+Pj4g PiA+WyAgICAwLjE4ODAwMF0gID8gYWNwaV91dF9kZWxldGVfY2FjaGVzKzB4M2YvMHg3Yg0KPiA+ PiA+Pj4gPj4gPj4gPj4+ID4gPlsgICAgMC4xODgwMDBdICA/IGFjcGlfdGVybWluYXRlKzB4NS8w eGYNCj4gPj4gPj4+ID4+ID4+ID4+PiA+ID5bICAgIDAuMTg4MDAwXSAgPyBhY3BpX2luaXQrMHgy ODgvMHgzMmUNCj4gPj4gPj4+ID4+ID4+ID4+PiA+ID5bICAgIDAuMTg4MDAwXSAgPyBfX2NsYXNz X2NyZWF0ZSsweDRjLzB4ODANCj4gPj4gPj4+ID4+ID4+ID4+PiA+ID5bICAgIDAuMTg4MDAwXSAg PyB2aWRlb19zZXR1cCsweDdhLzB4N2ENCj4gPj4gPj4+ID4+ID4+ID4+PiA+ID5bICAgIDAuMTg4 MDAwXSAgPyBkb19vbmVfaW5pdGNhbGwrMHg0ZS8weDFiMA0KPiA+PiA+Pj4gPj4gPj4gPj4+ID4g PlsgICAgMC4xODgwMDBdICA/IGtlcm5lbF9pbml0X2ZyZWVhYmxlKzB4MTk0LzB4MjFhDQo+ID4+ ID4+PiA+PiA+PiA+Pj4gPiA+WyAgICAwLjE4ODAwMF0gID8gcmVzdF9pbml0KzB4ODAvMHg4MA0K PiA+PiA+Pj4gPj4gPj4gPj4+ID4gPlsgICAgMC4xODgwMDBdICA/IGtlcm5lbF9pbml0KzB4YS8w eDEwMA0KPiA+PiA+Pj4gPj4gPj4gPj4+ID4gPlsgICAgMC4xODgwMDBdICA/IHJldF9mcm9tX2Zv cmsrMHgyNS8weDMwDQo+ID4+ID4+PiA+PiA+PiA+Pj4NCj4gPj4gPj4+ID4+ID4+ID4+PiBJJ20g bW9yZSBpbnRlcmVzdGVkIGluIHRoZSB3YXkgb2YgdHJpZ2dlcmluZyBBRV9OT1RfQUNRVUlSRUQg ZXJyb3IuDQo+ID4+ID4+PiA+PiA+PiA+Pj4gU28gY291bGQgeW91IHNlbmQgdXMgdGhlIGhhbmRj cmFmdGVkIEFDUEkgdGFibGUgb3IgYm90aCB0aGUgImFjcGlkdW1wIC1jIG9uIiBhbmQNCj4gPj4g ImFjcGlkdW1wIC1jIG9mZiIgb3V0cHV0Pw0KPiA+PiA+Pj4gPj4gPj4NCj4gPj4gPj4+ID4+ID4+ IEkgbW9kaWZpZWQgRkFDUCwgRkFDUywgQVBJQyB0YWJsZSBpbiBWaXJ0dWFsQm94IGZvciBMaW51 eC4NCj4gPj4gPj4+ID4+ID4+IEhlcmUgYXJlIHJhdyBkdW1wcyBvZiB0YWJsZS4NCj4gPj4gPj4+ ID4+ID4NCj4gPj4gPj4+ID4+ID4gU28sIGV4Y3VzZSBtZSwgYnV0IHdoYXQncyB0aGUgc2VjdXJp dHkgaXNzdWUgaGVyZT8NCj4gPj4gPj4+ID4+ID4NCj4gPj4gPj4+ID4+ID4gWW91IGhhY2tlZCB5 b3VyIEFDUEkgdGFibGVzIGludG8gcGllY2VzIHdoaWNoIHJlcXVpcmVzIHJvb3QgcHJpdmlsZWdl cyBhbnl3YXkuDQo+ID4+ID4+PiA+PiA+DQo+ID4+ID4+PiA+PiA+IFRoYW5rcywNCj4gPj4gPj4+ ID4+ID4gUmFmYWVsDQo+ID4+ID4+PiA+PiA+DQo+ID4+ID4+PiA+Pg0KPiA+PiA+Pj4gPj4gQXMg eW91IG1lbnRpb25lZCBlYXJsaWVyLCBJIGhhY2tlZCBteSBBQ1BJIHRhYmxlIGZvciByZXNlYXJj aCwgc28gaXQgc2VlbXMgdGhhdA0KPiA+PiA+Pj4gPj4gaXQgaXMgbm90IGEgc2VjdXJpdHkgaXNz dWUuDQo+ID4+ID4+PiA+Pg0KPiA+PiA+Pj4gPj4gQnV0LCBpZiBuZXcgbWFpbmJvYXJkIGFyZSBy ZWxlYXNlZCBhbmQgdGhleSBoYXZlIGEgdmVuZG9yLXNwZWNpZmljIEFDUEkgdGFibGUNCj4gPj4g Pj4+ID4+IHdoaWNoIGhhcyBpbnZhbGlkIGRhdGEsIHRoZSBvbGQgdmVyc2lvbiBvZiBrZXJuZWwg KDw9NC45KSB3aWxsIHBvc3NpYmx5IGV4cG9zZQ0KPiA+PiA+Pj4gPj4ga2VybmVsIGFkZHJlc3Mg YW5kIEtBU0xSIHdpbGwgYmUgbmV1dHJhbGl6ZWQgdW5pbnRlbnRpb25hbGx5Lg0KPiA+PiA+Pj4g Pg0KPiA+PiA+Pj4gPiBCdXQgdGhhdCB3b3VsZCBtZWFuIGEgYmFzaWNhbGx5IG5vbi1mdW5jdGlv bmFsIHN5c3RlbSwgc28gSSdtIG5vdCBzdXJlIGhvdw0KPiA+PiA+Pj4gPiBhbnlvbmUgY2FuIGFj dHVhbGx5IHRha2UgYWR2YW50YWdlIG9mIHRoZSAiS0FTTFIgbmV1dHJhbGl6YXRpb24iLg0KPiA+ PiA+Pj4NCj4gPj4gPj4+IEkgdGhpbmsgYW4gYXR0YWNrZXIgY2FuIHRha2UgYWR2YW50YWdlIG9m IHRoZSAiS0FTTFIgbmV1dHJhbGl6YXRpb24iLiBBcyB5b3UNCj4gPj4gPj4+IGtub3csIEtBU0xS IGlzIGdvb2QgdGVjaG5vbG9neSB0byBwcm90ZWN0IGtlcm5lbCBmcm9tIGtlcm5lbCBleHBsb2l0 cy4NCj4gPj4gPj4+DQo+ID4+ID4+PiBJZiB0aGUga2VybmVsIGhhcyB2dWxuZXJhYmlsaXRpZXMs IHRoZSBhdHRhY2tlciBjYW4gbWFrZSBleHBsb2l0IHVzaW5nIHRoZW0uDQo+ID4+ID4+PiBCdXQs IHRoZSBleHBsb2l0IHVzdWFsbHkgbmVlZHMgZ2FkZ2V0cyAoc21hbGwgY29kZSksIHRoZXJlZm9y ZSB0aGUgYXR0YWNrZXINCj4gPj4gPj4+IHNob3VsZCBrbm93IHdoZXJlIHRoZSBnYWRnZXRzIGFy ZSBpbiBrZXJuZWwuIElmIHRoZSBLQVNMUiBpcyB3b3JraW5nIGluIGtlcm5lbCwNCj4gPj4gPj4+ IHRoZSBhdHRhY2tlciBzaG91bGQgZmluZCB0aGUgYWN0dWFsIGtlcm5lbCBhZGRyZXNzLCBhbmQg aGUgY2FuIGdldCBrZXJuZWwNCj4gPj4gPj4+IGFkZHJlc3MgaW5mb3JtYXRpb24gZnJvbSBrZXJu ZWwgd2FybmluZy4NCj4gPj4gPj4NCj4gPj4gPj4gSWYgdGhlIHN5c3RlbSBiYXNpY2FsbHkgZG9l c24ndCB3b3JrLCB0aGF0IGluZm9ybWF0aW9uIGlzbid0ICBwYXJ0aWN1bGFybHkgdXNlZnVsLg0K PiA+PiA+Pg0KPiA+PiA+Pj4gPj4gSSBrbm93IHRoZSB2ZW5kb3JzIGNvbGxhYm9yYXRlIHdpdGgg TGludXgga2VybmVsIGRldmVsb3BlcnMsIGJ1dCB0aGUgcHJvYmxlbQ0KPiA+PiA+Pj4gPj4gY2Fu IHN0aWxsIG9jY3VyLg0KPiA+PiA+Pj4gPj4NCj4gPj4gPj4+ID4+IEhhcmR3YXJlIHZlbmRvcnMg cmVsZWFzZSBzbyBtYW55IGtpbmRzIG9mIG1haW5ib2FyZCBpbiBhIHllYXIsIGFuZCB0aGUgbWFq b3INCj4gPj4gPj4+ID4+IExpbnV4IGRpc3Ryb3MgKFVidW50dSwgRmVkb3JhLCBldGMuKSB3aWxs IGhhdmUgNC44IGtlcm5lbCBmb3IgYSBsb25nIHRpbWUuDQo+ID4+ID4+PiA+Pg0KPiA+PiA+Pj4g Pj4gRm9yIHRoaXMgcmVhc29uLCBJIHRoaW5rIHRoaXMgaXNzdWUgaGFzIGEgc2VjdXJpdHkgYXNw ZWN0Lg0KPiA+PiA+Pj4gPg0KPiA+PiA+Pj4gPiBXZWxsLCBub3QgcXVpdGUgSU1PLg0KPiA+PiA+ Pj4gPg0KPiA+PiA+Pj4gPiBJZiB0aGUgc3lzdGVtIG5lZWRzIEFDUEkgdGFibGVzIGFuZCB0aGUg a2VybmVsIGNhbm5vdCB1c2UgdGhlbSwgaXQganVzdCB3b24ndA0KPiA+PiA+Pj4gPiB3b3JrIG5v IG1hdHRlciB3aGF0Lg0KPiA+PiA+Pj4gPg0KPiA+PiA+Pj4gPiBUaGFua3MsDQo+ID4+ID4+PiA+ IFJhZmFlbA0KPiA+PiA+Pj4gPg0KPiA+PiA+Pj4gWWVzLCB5b3UgYXJlIHJpZ2h0LiBCdXQsIExp bnV4IGtlcm5lbCBoYXMgd2VsbC1kZWZpbmVkIGV4Y2VwdGlvbiBoYW5kbGVycywgc28NCj4gPj4g Pj4+IHNvbWUgc3lzdGVtcyBtYXkgd29yayBmaW5lIGxpa2UgbXkgdGVzdCBtYWNoaW5lLiBNb3Jl b3ZlciB0aGUgdXNlcnMgbWF5IG5vdA0KPiA+PiA+Pj4gcmVjb2duaXplIHdoYXQgdGhlIHByb2Js ZW0gaXMsIGFuZCBJIHRoaW5rIHRoYXQgdGhleSB3aWxsIHVzZSB0aGUgc3lzdGVtIGluDQo+ID4+ ID4+PiBpbnNlY3VyZSBzdGF0dXMgZm9yIGEgbG9uZyB0aW1lLg0KPiA+PiA+Pg0KPiA+PiA+PiBB IHZpcnR1YWwgYm94IG9yIGEgZ3Vlc3QgY2FuIHJ1biB3aXRob3V0IEFDUEkgdGFibGVzLiAgQSBi YXJlIG1ldGFsIHN5c3RlbQ0KPiA+PiA+PiB3aGVyZSBBQ1BJIHRhYmxlcyBhcmUgbmVjZXNzYXJ5 IHdpbGwgYmUgbW9yZS1vci1sZXNzIHVudXNhYmxlIGlmIHRoZSBrZXJuZWwNCj4gPj4gPj4gY2Fu bm90IHVzZSB0aGVtIChpdCB3b24ndCBiZSBhYmxlIHRvIGRldGVjdCBpbnRlcnJ1cHQgY29udHJv bGxlcnMgYW5kIHRoZSBQQ0kNCj4gPj4gPj4gaG9zdCBicmlkZ2UganVzdCBmb3Igc3RhcnRlcnMp Lg0KPiA+PiA+Pg0KPiA+PiA+PiBSdW5uaW5nIGEgZ3Vlc3Qgd2l0aCB0b3RhbGx5IGJyb2tlbiBB Q1BJIHRhYmxlcyByZXF1aXJlcyByb290IHByaXZpbGVnZXMgb24gdGhlDQo+ID4+ID4+IGhvc3Qu ICBSdW5uaW5nIGEgYmFyZSBtZXRhbCBzeXN0ZW0gd2l0aCB0b3RhbGx5IGJyb2tlbiBBQ1BJIHRh YmxlcyAod2hpY2ggc2VlbXMNCj4gPj4gPj4gdG8gYmUgeW91ciBiYXNpYyBjb25jZXJuKSBtYXkg YmUgYSBnb29kIHJlc2VhcmNoIHByb2plY3QsIGJ1dCBub2JvZHkgd2lsbCBkbw0KPiA+PiA+PiB0 aGF0IGluIHByYWN0aWNlLiAgQW5kIGV2ZXJ5Ym9keSB3aG8gdHJpZXMgdGhhdCB3aWxsIG5vdGlj ZSB3aGF0J3MgZ29pbmcgb24uDQo+ID4+ID4+DQo+ID4+ID4+IFllcywgeW91IGZvdW5kIGEgYnVn LCBidXQgSSBzdGlsbCBhbSBub3QgY29udmluY2VkIGFib3V0IGhvdyB0aGlzIGlzIHNlY3VyaXR5 LXJlbGF0ZWQuDQo+ID4+ID4NCj4gPj4gPiBJIHRvdGFsbHkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0 aGlzIGNhc2UgaXMgbm90IGluIHByYWN0aWNlIG5vdy4NCj4gPj4gPiBJIGp1c3Qgc3RhcnRlZCBy ZXNlYXJjaGluZyBvbiBBQ1BJLCBhbmQgSSBkb24ndCBoYXZlIGVub3VnaCBpZGVhcyB0byBvY2N1 cg0KPiA+PiA+IGEgc2VjdXJpdHkgcHJvYmxlbSB1c2luZyBhIGJ1Zy4gSSBqdXN0IHRoaW5rIHRo YXQgaXQgaGFzIGEgbGl0dGxlIHBvc3NpYmlsaXR5DQo+ID4+ID4gd2hpY2ggaXMgc2VjdXJpdHkt cmVsYXRlZC4NCj4gPj4gPg0KPiA+PiA+IFRoYW5rIHlvdSBzbyBtdWNoIGZvciB5b3VyIGd1aWRl cy4NCj4gPj4gPiBJdCBoZWxwcyBtZSBhIGxvdCB0byBjaGFuZ2UgbXkgcmVzZWFyY2ggZGlyZWN0 aW9uLg0KPiA+PiA+DQo+ID4+ID4gU28sIGNvdWxkIG15IHBhdGNoIGJlIG1lcmdlZCBpbiBuZXh0 IGtlcm5lbCAoNC4xMSByYy0xKT8gb3IgZG8gSSBuZWVkIHRvIGRvDQo+ID4+ID4gc29tZXRoaW5n IGZvciBpdD8NCj4gPj4gPiBQbGVhc2UgbGV0IG1lIGtub3cuDQo+ID4+DQo+ID4+IEdlbmVyYWxs eSwgQUNQSUNBIHBhdGNoZXMgKGFuZCB0aGlzIGlzIG9uZSBvZiB0aGVtKSBoYXZlIHRvIGdvIGlu IHZpYQ0KPiA+PiB0aGUgdXBzdHJlYW0gQUNQSUNBIHByb2plY3QgbWFpbnRhaW5lZCBieSBCb2Ig TW9vcmUgYW5kIEx2LiAgUGxlYXNlDQo+ID4+IHNlZSBNQUlOVEFJTkVSUyBmb3IgcG9pbnRlcnMg dG8gdGhlIG1haWxpbmcgbGlzdCBldGMuDQo+ID4+DQo+ID4+IEx2LCBjYW4geW91IHBsZWFzZSBh ZHZpc2Ugb24gdGhlIG5leHQgc3RlcHM/DQo+ID4NCj4gPiBJIGFscmVhZHkgZ2F2ZSBteSBhZHZp Y2VzLg0KPiA+IFRoZSBmaXggd2FzIE9LIHRvIG1lIGFuZCBJIGJhY2sgcG9ydGVkIGl0IHRvIEFD UElDQToNCj4gPiBodHRwczovL2dpdGh1Yi5jb20vYWNwaWNhL2FjcGljYS9wdWxsLzIwNg0KPiA+ IEhvd2V2ZXIgaXQgZml4ZXMgYSBjb2RlIHBhdGggdGhhdCBpbiB0aGVvcnkgc2hvdWxkbid0IGJl IGludm9rZWQgaW4gTGludXgga2VybmVsLg0KPiA+IEJ1dCBhbnl3YXkgaXQgd2FzIG1lcmdlZCBh bmQgeW91IHdpbGwgc2VlIGl0IGluIHRoZSBuZXh0IEFDUElDQSByZWxlYXNlLg0KPiA+DQo+ID4g SSBhc2tlZCBIYW4gZm9yIHRoZSBoYW5kY3JhZnRlZCBBQ1BJIHRhYmxlLg0KPiA+IEFuZCBvYnRh aW5lZCB0aGF0Og0KPiA+IEFDUEk6IEZBQ1AgMHgwMDAwMDAwMERGRkYwMEYwIDAwMDBGNCAodjA0 IFZCT1ggVkJPWEZBQ1AgMDAwMDAwMDEgQVNMICAwMDAwMDA2MSkNCj4gPiAweDAwMDA6IDQ2IDQx IDQzIDUwIEY0IDAwIDAwIDAwIDA0IDYwIDU2IDQyIDRGIDU4IDIwIDIwDQo+ID4gMHgwMDEwOiA1 NiA0MiA0RiA1OCA0NiA0MSA0MyA1MCAwMSAwMCAwMCAwMCA0MSA1MyA0QyAyMA0KPiA+IDB4MDAy MDogNjEgMDAgMDAgMDAgMDAgMDIgRkYgREYgODAgMDQgRkYgREYgNDEgNDEgNDEgNDENCj4gPiAw eDAwMzA6IDJFIDQ0IDAwIDAwIEExIEEwIDAwIDAwIDAwIDQwIDAwIDAwIDAwIDAwIDAwIDAwDQo+ ID4gMHgwMDQwOiAwNCA0MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwOCA0MCAwMCAw MA0KPiA+IDB4MDA1MDogMjAgNDAgMDAgMDAgMDAgMDAgMDAgMDAgMDQgMDIgMDAgMDQgMDIgMDAg MDAgMDANCj4gPiAweDAwNjA6IDY1IDAwIEU5IDAzIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAzIDAwIDAwDQo+ID4gMHgwMDcwOiA0MSAwNSAwMCAwMCAwMSAwOCAwMCAwMSA1MCA0MCAwMCAw MCAwMCAwMCAwMCAwMA0KPiA+IDB4MDA4MDogMTAgMDAgMDAgMDAgMDAgMDIgRkYgREYgMDAgMDAg MDAgMDAgODAgMDQgRkYgREYNCj4gPiAweDAwOTA6IDAwIDAwIDAwIDAwIDAxIDIwIDAwIDAyIDAw IDQwIDAwIDAwIDAwIDAwIDAwIDAwDQo+ID4gMHgwMEEwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMSAxMCAwMCAwMg0KPiA+IDB4MDBCMDogMDQgNDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDANCj4gPiAweDAwQzA6IDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwDQo+ID4gMHgwMEQwOiAwMSAyMCAwMCAw MyAwOCA0MCAwMCAwMCAwMCAwMCAwMCAwMCAwMSAxMCAwMCAwMQ0KPiA+IDB4MDBFMDogMjAgNDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDANCj4gPiAweDAwRjA6IDAw IDAwIDAwIDAwDQo+ID4NCj4gPiBBQ1BJOiBGQUNTIDB4MDAwMDAwMDBERkZGMDIwMCAwMDAwNDAN Cj4gPiAweDAwMDA6IDQ2IDQxIDQzIDUzIDQwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwDQo+ID4gMHgwMDEwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCA0MSA0MSA0MSA0MSA0 MSA0MSA0MQ0KPiA+IDB4MDAyMDogMDEgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgNDEgMDAgMDAg MDAgMDAgMDAgMDANCj4gPiAweDAwMzA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwDQo+ID4NCj4gPiBBQ1BJOiBBUElDIDB4MDAwMDAwMDBERkZGMDI0MCAw MDAwNkMgKHYwMiBWQk9YIFZCT1hBUElDIDAwMDAwMDAxIEFTTCAgMDAwMDAwNjEpDQo+ID4gMHgw MDAwOiA0MSA1MCA0OSA0MyA2QyAwMCAwMCAwMCAwMiAyMSA1NiA0MiA0RiA1OCAyMCAyMA0KPiA+ IDB4MDAxMDogNTYgNDIgNEYgNTggNDEgNTAgNDkgNDMgMDEgMDAgMDAgMDAgNDEgNTMgNEMgMjAN Cj4gPiAweDAwMjA6IDYxIDAwIDAwIDAwIDAwIDAwIEUwIEZFIDAxIDAwIDAwIDAwIDAyIDBBIDAw IDAwDQo+ID4gMHgwMDMwOiAwMiAwMCAwMCAwMCAwMCAwMCAwMiAwQSAwMCAwOSAwOSAwMCAwMCAw MCAwRCAwMA0KPiA+IDB4MDA0MDogMDAgMDggMDAgMDAgMDEgMDAgNDEgNDEgNDEgNDEgNDEgNDEg NDEgNDEgNDEgMDANCj4gPiAweDAwNTA6IDAwIDA4IDAyIDAyIDAxIDAwIDAwIDAwIDAwIDA4IDAz IDAzIDAxIDAwIDAwIDAwDQo+ID4gMHgwMDYwOiAwMSAwQyAwNCAwMCAwMCAwMCBDMCBGRSAwMCAw MCAwMCAwMA0KPiA+DQo+ID4gV2hlcmUgdGhlcmUgaXMgc3RpbGwgbm8gQU1MIHRhYmxlcyBhbmQg dGhlIGZhaWx1cmUgaW4gdGhlIHBhdGNoIGRlc2NyaXB0aW9uIHNlZW1zIHRvIGJlIHJlbGF0ZWQg dG8NCj4gdGhlIEFNTCB0YWJsZXMuDQo+ID4gU28gSSdtIHN0aWxsIG5vdCBhd2FyZSBvZiB3aGF0 IHRoZSAiaGFuZGNyYWZ0ZWQgdGFibGVzIiBtZWFudCB0byB1cyBhbmQgd2hhdCB0aGUgcHJvYmxl bSB3YXMuDQo+IA0KPiBBY3R1YWxseSwgSSBkaWQgbm90IGNoYW5nZSBEU0RUIGFuZCBTU0RULiBJ IGNoYW5nZWQgb25seSBGQUNQLCBGQUNTIGFuZCBBUElDIGZvcg0KPiBteSBoYW5kY3JhZnRlZCBB Q1BJIHRhYmxlLg0KPiANCj4gSSBoYXZlIGFuYWx5emVkIHRoZSByb290IGNhdXNlIG9mIHRoZSBw cm9ibGVtLCBhbmQgSSBoYXZlIGZvdW5kIHRoYXQgbXkNCj4gaGFuZGNyYWZ0ZWQgQUNQSSB0YWJs ZSBoYXMgdG9vIGJpZyBTQ0kgSVJRIChsaWtlIDE2NzA1KS4NCj4gU28sIGFjcGlfb3NfaW5zdGFs bF9pbnRlcnJ1cHRfaGFuZGxlcigpIHdoaWNoIGlzIGNhbGxlZCBieQ0KPiBhY3BpX2VuYWJsZV9z dWJzeXN0ZW0oKQ0KPiB3YXMgZmFpbGVkIGFuZCByZXR1cm5lZCBBRV9OT1RfQUNRVUlSRUQgKDB4 MTQpIHdpdGggIkFDUEk6IFNDSSAoSVJRMTY3MDUpDQo+IGFsbG9jYXRpb24gZmFpbGVkIiBsb2cu DQoNClRoYW5rcyBmb3IgdGhlIGV4cGxhbmF0aW9uLg0KVGhlcmUgZG9lc24ndCBzZWVtIHRvIGJl IGFueSByZXF1aXJlZCBhZGRpdGlvbmFsIGZpeCBmb3Igc3VjaCBhIHdyb25nIHNjaSBpcnEgIy4N CldoaWNoIGNhbiByZWxlYXNlIG1lIGZyb20gdGhlIHRyaWdnZXJlZCBlcnJvciBub3cuIDopDQoN Cj4gDQo+IEJlY2F1c2Ugb2YgZXJyb3IgY29kZSwgYWNwaV9idXNfaW5pdCgpLCB0aGUgY2FsbGVy IG9mIGFjcGlfZW5hYmxlX3N1YnN5c3RlbSgpLA0KPiBzaG93ZWQgIlVuYWJsZSB0byBzdGFydCB0 aGUgQUNQSSBJbnRlcnByZXRlciIgYW5kIGNhbGxlZCBhY3BpX3Rlcm1pbmF0ZSgpIGZvcg0KPiBl eGNlcHRpb24gaGFuZGxpbmcuIEFmdGVyIGNhbGxpbmcgYWNwaV90ZXJtaW5hdGUoKSwgYXMgeW91 IGtub3csIGNhY2hlIGxlYWsNCj4gb2NjdXJyZWQuDQo+IFRoaXMgbWVhbnMgdGhhdCBlcnJvciBv ZiBhY3BpX2xvYWRfdGFibGVzKCksIGFjcGlfaW5pdGlhbGl6ZV9vYmplY3RzKCksDQo+IGFjcGlf YnVzX2luaXRfaXJxKCkgYW5kIGFjcGlfaW5zdGFsbF9ub3RpZnlfaGFuZGxlcigpIHdoaWNoIGFy ZSBjYWxsZWQgYnkNCj4gYWNwaV9idXNfaW5pdCgpIGNhbiBjYXVzZSBjYWNoZSBsZWFrLg0KPiAN Cj4gSWYgeW91IHdhbnQgdG8gc2VlIHRoaXMgZXJyb3IgaGFuZGxpbmcgc2VxdWVuY2UsIEkgc3Vn Z2VzdCB5b3UgdGhhdCB5b3UgY2hhbmdlDQo+IHRoZSBjb2RlIG9mIGFjcGlfb3NfaW5zdGFsbF9p bnRlcnJ1cHRfaGFuZGxlcigpIHRvIHJldHVybiBBRV9OT1RfQUNRVUlSRUQNCj4gaW1tZWRpYXRl bHkuIFRoZW4sIHlvdSBjYW4gc2VlIHRoZSBlcnJvciBoYW5kbGluZyBzZXF1ZW5jZSB3aXRob3V0 IG15DQo+IGhhbmRjcmFmdGVkDQo+IEFDUEkgdGFibGUuDQoNCllvdSBjYW4gYWx3YXlzIGhhcmRl biB0aGUgY29kZSB3aXRoIGFjY2VwdGFibGUgaW1wcm92ZW1lbnRzLg0KRmVlbCBmcmVlIHRvIGNv bnRpbnVlIHlvdXIgY29udHJpYnV0aW9uLg0KDQo+IA0KPiBJIHlvdSB3YW50IGFkZGl0aW9uYWwg aW5mb3JtYXRpb24gYWJvdXQgdGhpcywgcGxlYXNlIGxldCBtZSBrbm93Lg0KDQpTdXJlLg0KDQpU aGFua3MNCkx2DQoNCj4gDQo+IEJlc3QgcmVnYXJkcy4NCj4gDQo+ID4NCj4gPiBUaGFua3MgYW5k IGJlc3QgcmVnYXJkcw0KPiA+IEx2DQo+ID4NCj4gPj4NCj4gPj4gVGhhbmtzLA0KPiA+PiBSYWZh ZWwNCj4gPj4gLS0NCj4gPj4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhl IGxpbmUgInVuc3Vic2NyaWJlIGxpbnV4LWFjcGkiIGluDQo+ID4+IHRoZSBib2R5IG9mIGEgbWVz c2FnZSB0byBtYWpvcmRvbW9Admdlci5rZXJuZWwub3JnDQo+ID4+IE1vcmUgbWFqb3Jkb21vIGlu Zm8gYXQgIGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbA0K -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/acpi/acpica/nsutils.c b/drivers/acpi/acpica/nsutils.c index 691814d..943702d 100644 --- a/drivers/acpi/acpica/nsutils.c +++ b/drivers/acpi/acpica/nsutils.c @@ -594,25 +594,20 @@ struct acpi_namespace_node *acpi_ns_validate_handle(acpi_handle handle) void acpi_ns_terminate(void) { acpi_status status; + union acpi_operand_object *prev; + union acpi_operand_object *next; ACPI_FUNCTION_TRACE(ns_terminate); -#ifdef ACPI_EXEC_APP - { - union acpi_operand_object *prev; - union acpi_operand_object *next; + /* Delete any module-level code blocks */ - /* Delete any module-level code blocks */ - - next = acpi_gbl_module_code_list; - while (next) { - prev = next; - next = next->method.mutex; - prev->method.mutex = NULL; /* Clear the Mutex (cheated) field */ - acpi_ut_remove_reference(prev); - } + next = acpi_gbl_module_code_list; + while (next) { + prev = next; + next = next->method.mutex; + prev->method.mutex = NULL; /* Clear the Mutex (cheated) field */ + acpi_ut_remove_reference(prev); } -#endif /* * Free the entire namespace -- all nodes and all objects