On 12/5/24 17:05, Zi Yan wrote: > On 5 Dec 2024, at 3:10, David Hildenbrand wrote: >>> >>> Kernel log confirms it's enabled: >>> -mem auto-init: stack:off, heap alloc:off, heap free:off >>> +mem auto-init: stack:off, heap alloc:on, heap free:off >> >> If I'm not wrong that's expected ... because we'll be double-zeroing that memory, clearing the cache :) >> >> I guess the question is, how *effective* is CONFIG_INIT_ON_ALLOC_DEFAULT_ON on systems to prevent exposing un-zeroed data to userspace, when it doesn't end up doing the flush we really need. > > Hi Geert, > > Is it possible to run a 32bit kernel with HIGHMEM and > CONFIG_INIT_ON_ALLOC_DEFAULT_ON on the machine (of course with my patch > reverted)? Just to check my reasoning below. > > Thanks. > > > Yes, it should work, since I forgot the actual issue is HIGHMEM+cache flush, not just cache flush is needed after clearing user page. > > For arch which needs to flush cache after clearing user page, with HIGHMEM, > init_on_alloc first clears the page using kmap_addr0 without flushing > the cache, then clear_user_page() clears the page using kmap_addr1 > with cache flush. After returning to userspace, the cache lines of > kmap_addr0 will be evicted and written back to RAM eventually, corrupting > user data with 0s, because no one flushes them before returning to userspace. > > For a proper fix, I will add ARCH_HAS_OPS_AFTER_CLEAR_USER_PAGE and > make mips, sh, sparc, arm, xtensa, nios2, m68k, parisc, csky, arc, and powerpc > select it, then make alloc_zeroed() returns false if > ARCH_HAS_OPS_AFTER_CLEAR_USER_PAGE is enabled. > > If my reasoning above is verified to be true, I will send a separate patch > to disable CONFIG_INIT_ON_ALLOC_DEFAULT_ON if HIGHMEM && > ARCH_HAS_OPS_AFTER_CLEAR_USER_PAGE. If your reasoning is true, wouldn't any other user of kmap_local_page() of a highpage on such system also leave the cache unflushed in case the page is ever reused as a userspace page? > Best Regards, > Yan, Zi
