x86/module: rework ROX cache to avoid writable copy #45
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![modules-kpd-app[bot]](https://avatars.githubusercontent.com/u/89608766?s=60&v=4){kind=small}
|
Upstream branch: 8a231a1 |
modules-kpd-app
bot
force-pushed
the
modules-next_base
branch
from
fb646d1 to
14ceb4b
Compare
|
Upstream branch: b7e6013 |
modules-kpd-app
bot
force-pushed
the
series/921069=>modules-next
branch
from
cb90bda to
2336945
Compare
petrpavlu
force-pushed
the
modules-next_base
branch
from
14ceb4b to
74d1ec0
Compare
|
Upstream branch: 0217859 |
modules-kpd-app
bot
force-pushed
the
series/921069=>modules-next
branch
from
2336945 to
d781cd1
Compare
modules-kpd-app
bot
force-pushed
the
modules-next_base
branch
from
74d1ec0 to
0f0b06f
Compare
|
Upstream branch: f3b9354 |
modules-kpd-app
bot
force-pushed
the
series/921069=>modules-next
branch
from
d781cd1 to
b33b80a
Compare
|
Upstream branch: f3b9354 |
modules-kpd-app
bot
force-pushed
the
series/921069=>modules-next
branch
from
b33b80a to
292b114
Compare
modules-kpd-app
bot
force-pushed
the
modules-next_base
branch
from
0f0b06f to
0893b23
Compare
|
Upstream branch: 48ecfdd |
modules-kpd-app
bot
force-pushed
the
series/921069=>modules-next
branch
from
292b114 to
34796b9
Compare
modules-kpd-app
bot
force-pushed
the
modules-next_base
branch
from
0893b23 to
95973fc
Compare
The CPA_ARRAY test always uses len[1] as numpages argument to change_page_attr_set() although the addresses array is different each iteration of the test loop. Replace len[1] with len[i] to have numpages matching the addresses array. Fixes: ecc729f ("x86/mm/cpa: Add ARRAY and PAGES_ARRAY selftests") Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
There is a 'struct cpa_data *data' parameter in cpa_flush() that is assigned to a local 'struct cpa_data *cpa' variable. Rename the parameter from 'data' to 'cpa' and drop declaration of the local 'cpa' variable. Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
Upstream branch: 053842e |
Change of attributes of the pages may lead to fragmentation of direct mapping over time and performance degradation when these pages contain executable code. With current code it's one way road: kernel tries to avoid splitting large pages, but it doesn't restore them back even if page attributes got compatible again. Any change to the mapping may potentially allow to restore large page. Add a hook to cpa_flush() path that will check if the pages in the range that were just touched can be mapped at PMD level. If the collapse at the PMD level succeeded, also attempt to collapse PUD level. The collapse logic runs only when a set_memory_ method explicitly sets CPA_COLLAPSE flag, for now this is only enabled in set_memory_rox(). CPUs don't like[1] to have to have TLB entries of different size for the same memory, but looks like it's okay as long as these entries have matching attributes[2]. Therefore it's critical to flush TLB before any following changes to the mapping. Note that we already allow for multiple TLB entries of different sizes for the same memory now in split_large_page() path. It's not a new situation. set_memory_4k() provides a way to use 4k pages on purpose. Kernel must not remap such pages as large. Re-use one of software PTE bits to indicate such pages. [1] See Erratum 383 of AMD Family 10h Processors [2] https://lore.kernel.org/linux-mm/1da1b025-cabc-6f04-bde5-e50830d1ecf0@amd.com/ [rppt@kernel.org: * s/restore/collapse/ * update formatting per peterz * use 'struct ptdesc' instead of 'struct page' for list of page tables to be freed * try to collapse PMD first and if it succeeds move on to PUD as peterz suggested * flush TLB twice: for changes done in the original CPA call and after collapsing of large pages * update commit message ] Link: https://lore.kernel.org/all/20200416213229.19174-1-kirill.shutemov@linux.intel.com Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Co-developed-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
The memory allocated for the ROX cache was removed from the direct map to reduce amount of direct map updates, however this cannot be tolerated by /proc/kcore that accesses module memory using vread_iter() and the latter does vmalloc_to_page() and copy_page_to_iter_nofault(). Instead of removing ROX cache memory from the direct map and mapping it as ROX in vmalloc space, simply call set_memory_rox() that will take care of proper permissions on both vmalloc and in the direct map. Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
…wards Using a writable copy for ROX memory is cumbersome and error prone. Add API that allow temporarily remapping of ranges in the ROX cache as writable and then restoring their read-only-execute permissions. This API will be later used in modules code and will allow removing nasty games with writable copy in alternatives patching on x86. The restoring of the ROX permissions relies on the ability of architecture to reconstruct large pages in its set_memory_rox() method. Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Instead of using writable copy for module text sections, temporarily remap the memory allocated from execmem's ROX cache as writable and restore its ROX permissions after the module is formed. This will allow removing nasty games with writable copy in alternatives patching on x86. Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Acked-by: Petr Pavlu <petr.pavlu@suse.com>
The module code does not create a writable copy of the executable memory anymore so there is no need to handle it in module relocation and alternatives patching. This reverts commit 9bfc482. Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
module_writable_address() is unused and can be removed. Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
after rework of execmem ROX caches Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
modules-kpd-app
bot
force-pushed
the
series/921069=>modules-next
branch
from
34796b9 to
c534b53
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull request for series with
subject: x86/module: rework ROX cache to avoid writable copy
version: 1
url: https://patchwork.kernel.org/project/linux-modules/list/?series=921069