GRsecurity patch breaks Linux kernel image to boot from EFI
Posted: Thu Aug 22, 2013 2:55 am
Hi there,
I am a software engineer from Wind River (subsidiary of Intel), we ported GRsecurity patch (GRSecurity 2.9.1 -- 201207080925) into Wind River Linux as our security solution's critical part, the target board is intel-atom based or Freescale imx6 based platform (2 core/4 core). Recently, we found this patch will break our kernel's capability to boot from EFI shell.
Below is our analysis:
After patched with gr-sec, the system will hang when booting from EFI shell.
After transplant the the efi booting code, we found the system will hang after the failure in relocate_kernel which is called from efi_main.
Gr-sec patch would update the pref_address for some reason, and that make the efi_call_phys4 function return error.
Also we have noticed there exists a commit seems to be related to solving grsec's confliction with EFI booting in http://grsecurity.net/changelog-stable2.txt
commit eac2752de8a4e15d65bb08f9186e5171bc46c466
Author: Brad Spengler <spender@grsecurity.net>
Date: Thu Jul 4 20:58:16 2013 -0400
Update to pax-linux-3.2.47-test110.patch:
- fixed the heap-stack gap enforcement logic under STACK_GROWSUP, reported by spender
- backported the EFI boot fix (https://bugs.gentoo.org/show_bug.cgi?id=471626)
Can anyone help with delivering exact fix in above commit so that we can porting it into our kernel and try EFI booting again? Or, should we try any other approach to fix EFI booting failure?
Thanks in advance!
I am a software engineer from Wind River (subsidiary of Intel), we ported GRsecurity patch (GRSecurity 2.9.1 -- 201207080925) into Wind River Linux as our security solution's critical part, the target board is intel-atom based or Freescale imx6 based platform (2 core/4 core). Recently, we found this patch will break our kernel's capability to boot from EFI shell.
Below is our analysis:
After patched with gr-sec, the system will hang when booting from EFI shell.
After transplant the the efi booting code, we found the system will hang after the failure in relocate_kernel which is called from efi_main.
Gr-sec patch would update the pref_address for some reason, and that make the efi_call_phys4 function return error.
- Code: Select all
start = hdr->pref_address;
nr_pages = round_up(hdr->init_size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
status = efi_call_phys4(sys_table->boottime->allocate_pages,
EFI_ALLOCATE_ADDRESS, EFI_LOADER_DATA,
nr_pages, &start);
if (status != EFI_SUCCESS) {
status = low_alloc(hdr->init_size, hdr->kernel_alignment,
&start);
if (status != EFI_SUCCESS)
efi_printk("Failed to alloc mem for kernel\n");
}
Also we have noticed there exists a commit seems to be related to solving grsec's confliction with EFI booting in http://grsecurity.net/changelog-stable2.txt
commit eac2752de8a4e15d65bb08f9186e5171bc46c466
Author: Brad Spengler <spender@grsecurity.net>
Date: Thu Jul 4 20:58:16 2013 -0400
Update to pax-linux-3.2.47-test110.patch:
- fixed the heap-stack gap enforcement logic under STACK_GROWSUP, reported by spender
- backported the EFI boot fix (https://bugs.gentoo.org/show_bug.cgi?id=471626)
Can anyone help with delivering exact fix in above commit so that we can porting it into our kernel and try EFI booting again? Or, should we try any other approach to fix EFI booting failure?
Thanks in advance!