lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 28 Mar 2011 18:26:41 +0100
From:	Stefano Stabellini <stefano.stabellini@...citrix.com>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	linux-kernel@...r.kernel.org
Subject: another pagetable initialization crash on xen

Hi Yinghai,
unfortunately I found another pagetable initialization bug on xen
affecting linux 2.6.39-rc0.
The problem is that on xen we need to make sure that all the pagetable pages
are mapped read-only, in fact in xen_set_pte we have this check:

if (pfn >= pgt_buf_start && pfn < pgt_buf_end)
    /* make the pte read-only */

however pgt_buf_end is where the kernel pagetable *currently* ends, so
some kernel pagetable pages allocated after pgt_buf_end might be marked
read-write by mistake.  A simple way to fix the issue would be to use
pgt_buf_top instead:

if (pfn >= pgt_buf_start && pfn < pgt_buf_top)
    /* make the pte read-only */

however after building the kernel pagetable in init_memory_mapping we
only reserve memory between pgt_buf_start and pgt_buf_end:

if (!after_bootmem && pgt_buf_end > pgt_buf_start)
        memblock_x86_reserve_range(pgt_buf_start << PAGE_SHIFT,
                 pgt_buf_end << PAGE_SHIFT, "PGTABLE");

so feature allocations might use memory between the final value of
pgt_buf_end and pgt_buf_top that has been marked read-only in the xen
specific code, causing a crash.
The only way I could find to fix the crash is to reserve also the memory
region between pgt_buf_start and pgt_buf_top on xen, but that would
require an ugly if(xen_domain()) at the of init_memory_mapping or
the introduction of a new pvop function to reserve the pagetable memory.
I don't like the idea, but I couldn't find anything better.
Yinghai, do you have any better suggestions?

Thanks,

Stefano
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ