Messages in this thread | | | Date | Sat, 22 Jan 2011 00:11:34 -0500 | From | Konrad Rzeszutek Wilk <> | Subject | Re: [tip:x86/security] x86: Add NX protection for kernel data |
| |
On Fri, Jan 21, 2011 at 10:41:54PM +0100, matthieu castet wrote: > Konrad Rzeszutek Wilk a écrit : >>> - * .data and .bss should always be writable. >>> + * .data and .bss should always be writable, but xen won't like >>> + * if we make page table rw (that live in .data or .bss) >>> */ >>> +#ifdef CONFIG_X86_32 >>> if (within(address, (unsigned long)_sdata, (unsigned long)_edata) || >>> - within(address, (unsigned long)__bss_start, (unsigned long)__bss_stop)) >>> - pgprot_val(required) |= _PAGE_RW; >>> + within(address, (unsigned long)__bss_start, (unsigned long)__bss_stop)) { >>> + unsigned int level; >>> + if (lookup_address(address, &level) && (level != PG_LEVEL_4K)) >>> + pgprot_val(forbidden) |= _PAGE_RW; >>> + } >>> +#endif >>> #if defined(CONFIG_X86_64) && defined(CONFIG_DEBUG_RODATA) >>> >>> fyi, it does make it boot. >> >> Hold it.. ccache is a wonderful tool but I think I've just "rebuilt" the >> binaries with the .bss HPAGE_ALIGN aligment by mistake, so this path got never >> taken. >> >> > Ok, > > ATM I saw the following solution to solve the problem : > 1) remove the data/bss check in static_protections, it was introduced by NX patches (64edc8ed). But I am not sure it > is really needed anymore. > 2) add ". = ALIGN(HPAGE_SIZE)" somewhere after init section. But if we want not to be allocated in image we > should put it before bss. And if we want to be freed after init, we should put before .init.end. > This mean moving .smp_locks (and .data_nosave when x86 will be added) before init section. I have no idea of the impact. > 3) add some logic in arch/x86/xen/mmu.c, that will ignore RW page setting for the page table marked RO. > 4) make static_protections take and old_prot argument, and only apply RW .data/.bss requirement if page is already RW. > > If possible I will go for 1).
Sounds good. Just send me the patch and I will test it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |