Hi, Rafael. I agree with you and I added my opinion below. 2017-02-25 1:50 GMT+09:00 Rafael J. Wysocki <rjw@xxxxxxxxxxxxx>: > 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@xxxxxxxxxxxxx>: >> > 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@xxxxxxxxxxxxx>: >> >> > 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@xxxxxxxxx>: >> >> >> > Hello, >> >> >> > >> >> >> > I attached the test results below, >> >> >> > >> >> >> > 2017-02-21 9:53 GMT+09:00 Rowafael J. Wysocki <rjw@xxxxxxxxxxxxx>: >> >> >> >> On Tuesday, February 21, 2017 12:33:08 AM Zheng, Lv wrote: >> >> >> >>> Hi, >> >> >> >>> >> >> >> >>> > From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi-owner@xxxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
