 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Zahar Kiselev 2:5030/382.1 13 Oct 2004 21:46:46 To : Nick Gazaloff Subject : Re: неисполняемый стэк в 2.4 ? -------------------------------------------------------------------------------- Oct 13 11:59 04, Nick Gazaloff wrote to Zahar Kiselev: >> NG> Смотрим на ключевое слово "сегмент" и вспоминаем о flat 32-bit >> NG> memory. >> А это никак не проблема _аппаратной_ платформы. Платформа поддерживает >> все что нужно, это ОС не пользуется этой поддержкой. NG> Значит, openwall дураки писали? Вместо того, чтобы задействовать NG> аппаратную защиту (которую дурак LT не смог включить), они ее стали NG> эмулировать? А вот файлик с сайта http://pax.grsecurity.net/docs ----- segmexec.txt begins ----- 1. Design The goal of SEGMEXEC is to implement the non-executable page feature using the segmentation logic of IA-32 based CPUs. On IA-32 Linux runs in protected mode with paging enabled. This means that for every memory access (be that instruction fetch or normal data access) the CPU will perform a two step address translation. In the first step the logical address decoded from the instruction is translated into a linear (or in another terminology, virtual) address. This translation is done by the segmentation logic whose details are explained in a separate document. While Linux effectively does not use segmentation by creating 0 based and 4 GB limited segments for both code and data accesses (therefore logical addresses are the same as linear addresses), it is possible to set up segments that allow to implement non-executable pages. The basic idea is that we divide the 3 GB userland linear address space into two equal halves and use one to store mappings meant for data access (that is, we define a data segment descriptor to cover the 0-1.5 GB linear address range) and the other for storing mappings for execution (that is, we define a code segment descriptor to cover the 1.5-3 GB linear address range). Since an executable mapping can be used for data accesses as well, we will have to ensure that such mappings are visible in both segments and mirror each other. This setup will then separate data accesses from instruction fetches in the sense that they will hit different linear addresses and therefore allow for control/intervention based on the access type. In particular, if a data-only (and therefore non-executable) mapping is present only in the 0-1.5 GB linear address range, then instruction fetches to the same logical addresses will end up in the 1.5-3 GB linear address range and will raise a page fault hence allow detecting such execution attempts. 2. Implementation The core of SEGMEXEC is vma mirroring which is discussed in a separate document. The mirrors for executable file mappings are set up in do_mmap() (an inline function defined in include/linux/mm.h) except for a special case with RANDEXEC (see separate document). do_mmap() is the one common function called by both userland and kernel originated mapping requests. The special code and data segment descriptors are placed into a new GDT called gdt_table2 in arch/i386/kernel/head.S. The separate GDT is needed for two reasons: first it simplifies the implementation in that the CS/SS selectors used for userland do not have to change, and second, this setup prevents a simple attack that a single GDT setup would be subject to (the retf and other instructions could be abused to break out of the restricted code segment used for SEGMEXEC tasks). Since the GDT stores the userland code/data descriptors which are different for SEGMEXEC tasks, we have to modify the low-level context switching code called __switch_to() in arch/i386/kernel/process.c and the last steps of load_elf_binary() in fs/binfmt_elf.c (where the task is first prepared to execute in userland). The GDT also has APM specific descriptors which are set up at runtime and must be propagated to the second GDT as well (in arch/i386/kernel/apm.c). Finally the GDT stores also the per CPU TSS and LDT descriptors whose content must be synchronized between the two GDTs (in set_tss_desc() and set_ldt_desc() in arch/i386/kernel/traps.c). Since the kernel allows userland to define its own code segment descriptors in the LDT, we have to disallow it since it could be used to break out of the SEGMEXEC specific restricted code segment (the extra checks are in write_ldt() in arch/i386/kernel/ldt.c). ----- segmexec.txt ends ----- NG> -- NG> Best regards, NG> Nick NG> (GPG Key ID: 4396B2D0, fingerprint: 648E C3FE ACF6 A730 FF52 D717 NG> 776D NG> 1CB0 4396 B2D0) NG> -+- ifmail v.2.15dev5.3 NG> + Origin: RTComm.RU (2:5020/400) Zahar(@spbdept.rbc.ru) Остров Большой Березовый: http://birch-island.spb.ru --- Msged/LNX 6.1.1 * Origin: N:60.17'54" E:28.39'40" (2:5030/382.1) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/3288416d5512.html, оценка из 5, голосов 10
|
|
|