linux-kernel - change_page_attr() and global_flush

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:	Thu, 05 Apr 2007 10:32:49 +0100
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	<linux-kernel@...r.kernel.org>, <discuss@...-64.org>
Subject: change_page_attr() and global_flush_tlb()

Looking at both the i386 and x86-64 implementations I fail to understand why
there is an explicit requirement on calling global_flush_tlb() after
change_page_attr(), yet actual TLB flushing will not normally happen (on i386
it will happen if the CPU doesn't support clflush, but if it does, or on x86-64,
the flushing depends on the list of deferred pages being non-empty, which
can only happen when a large page gets re-combined). Is it assumed that
the callers additionally call tlb_flush_all() (I think none of them do)?

Further, change_page_attr()'s reference counting in a split large page's
page table appears to imply that attributes are only changed from or back to
the reference attributes, but not from one kind of non-default ones to the
same or another set of non-default ones (otherwise the reference count
will never again drop to zero), and also not from default to default (i.e. the
caller trying to revert attributes to normal not knowing what state they are
currently in) - this would BUG() if the large page was already reverted, or
screw the reference count otherwise. Is all of this intentional? I think it
will need to be changed as a prerequisite to supporting on-the-fly attribute
changes in the SMP alternatives code, which was requested as a follow-up
to the tightening of the CONFIG_DEBUG_RODATA effects.

Finally, at least for the kernel image range it would seem to me that it might
be beneficial to recombine mappings into large ones even when the
attributes are not at their default anymore, but consistent across an entire
2Mb/4Mb range (i.e. after write-protecting .text). At the same time I wonder,
though, whether it wouldn't be safer to remove execute permission from
anything but .text along with write-protecting read-only regions under
CONFIG_DEBUG_RODATA.

Thanks for any insight,
Jan
-
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/