November 2020 - Linux-kselftest-mirror

by Investment Corporate

Hello linux-kselftest(a)vger.kernel.org We are Base Investment Company offering Corporate and Personal Loan at 3% Interest Rate for a duration of 10Years. We also pay 1% commission to brokers, who introduce project owners for finance or other opportunities. Please get back to me if you are interested for more details. Yours faithfully, Hashim Murrah

3 years, 5 months

1
0
0 0

[PATCH v9 0/9] mm: introduce memfd_secret system call to create "secret" memory areas

by Mike Rapoport

From: Mike Rapoport <rppt(a)linux.ibm.com> Hi, This is an implementation of "secret" mappings backed by a file descriptor. The file descriptor backing secret memory mappings is created using a dedicated memfd_secret system call The desired protection mode for the memory is configured using flags parameter of the system call. The mmap() of the file descriptor created with memfd_secret() will create a "secret" memory mapping. The pages in that mapping will be marked as not present in the direct map and will have desired protection bits set in the user page table. For instance, current implementation allows uncached mappings. Although normally Linux userspace mappings are protected from other users, such secret mappings are useful for environments where a hostile tenant is trying to trick the kernel into giving them access to other tenants mappings. Additionally, in the future the secret mappings may be used as a mean to protect guest memory in a virtual machine host. For demonstration of secret memory usage we've created a userspace library https://git.kernel.org/pub/scm/linux/kernel/git/jejb/secret-memory-preloade… that does two things: the first is act as a preloader for openssl to redirect all the OPENSSL_malloc calls to secret memory meaning any secret keys get automatically protected this way and the other thing it does is expose the API to the user who needs it. We anticipate that a lot of the use cases would be like the openssl one: many toolkits that deal with secret keys already have special handling for the memory to try to give them greater protection, so this would simply be pluggable into the toolkits without any need for user application modification. Hiding secret memory mappings behind an anonymous file allows (ab)use of the page cache for tracking pages allocated for the "secret" mappings as well as using address_space_operations for e.g. page migration callbacks. The anonymous file may be also used implicitly, like hugetlb files, to implement mmap(MAP_SECRET) and use the secret memory areas with "native" mm ABIs in the future. To limit fragmentation of the direct map to splitting only PUD-size pages, I've added an amortizing cache of PMD-size pages to each file descriptor that is used as an allocation pool for the secret memory areas. As the memory allocated by secretmem becomes unmovable, we use CMA to back large page caches so that page allocator won't be surprised by failing attempt to migrate these pages. v9: * Fix build with and without CONFIG_MEMCG * Update memcg accounting to avoid copying memcg_data, per Roman comments * Fix issues in secretmem_fault(), thanks Matthew * Do not wire up syscall in arm64 compatibility layer v8: https://lore.kernel.org/lkml/20201110151444.20662-1-rppt@kernel.org * Use CMA for all secretmem allocations as David suggested * Update memcg accounting after transtion to CMA * Prevent hibernation when there are active secretmem users * Add zeroing of the memory before releasing it back to cma/page allocator * Rebase on v5.10-rc2-mmotm-2020-11-07-21-40 v7: https://lore.kernel.org/lkml/20201026083752.13267-1-rppt@kernel.org * Use set_direct_map() instead of __kernel_map_pages() to ensure error handling in case the direct map update fails * Add accounting of large pages used to reduce the direct map fragmentation * Teach get_user_pages() and frieds to refuse get/pin secretmem pages v6: https://lore.kernel.org/lkml/20200924132904.1391-1-rppt@kernel.org * Silence the warning about missing syscall, thanks to Qian Cai * Replace spaces with tabs in Kconfig additions, per Randy * Add a selftest. v5: https://lore.kernel.org/lkml/20200916073539.3552-1-rppt@kernel.org * rebase on v5.9-rc5 * drop boot time memory reservation patch v4: https://lore.kernel.org/lkml/20200818141554.13945-1-rppt@kernel.org * rebase on v5.9-rc1 * Do not redefine PMD_PAGE_ORDER in fs/dax.c, thanks Kirill * Make secret mappings exclusive by default and only require flags to memfd_secret() system call for uncached mappings, thanks again Kirill :) v3: https://lore.kernel.org/lkml/20200804095035.18778-1-rppt@kernel.org * Squash kernel-parameters.txt update into the commit that added the command line option. * Make uncached mode explicitly selectable by architectures. For now enable it only on x86. v2: https://lore.kernel.org/lkml/20200727162935.31714-1-rppt@kernel.org * Follow Michael's suggestion and name the new system call 'memfd_secret' * Add kernel-parameters documentation about the boot option * Fix i386-tinyconfig regression reported by the kbuild bot. CONFIG_SECRETMEM now depends on !EMBEDDED to disable it on small systems from one side and still make it available unconditionally on architectures that support SET_DIRECT_MAP. v1: https://lore.kernel.org/lkml/20200720092435.17469-1-rppt@kernel.org Mike Rapoport (9): mm: add definition of PMD_PAGE_ORDER mmap: make mlock_future_check() global set_memory: allow set_direct_map_*_noflush() for multiple pages mm: introduce memfd_secret system call to create "secret" memory areas secretmem: use PMD-size pages to amortize direct map fragmentation secretmem: add memcg accounting PM: hibernate: disable when there are active secretmem users arch, mm: wire up memfd_secret system call were relevant secretmem: test: add basic selftest for memfd_secret(2) arch/Kconfig | 7 + arch/arm64/include/asm/cacheflush.h | 4 +- arch/arm64/include/asm/unistd.h | 2 +- arch/arm64/include/asm/unistd32.h | 2 + arch/arm64/include/uapi/asm/unistd.h | 1 + arch/arm64/mm/pageattr.c | 10 +- arch/riscv/include/asm/set_memory.h | 4 +- arch/riscv/include/asm/unistd.h | 1 + arch/riscv/mm/pageattr.c | 8 +- arch/x86/Kconfig | 1 + arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/entry/syscalls/syscall_64.tbl | 1 + arch/x86/include/asm/set_memory.h | 4 +- arch/x86/mm/pat/set_memory.c | 8 +- fs/dax.c | 11 +- include/linux/pgtable.h | 3 + include/linux/secretmem.h | 30 ++ include/linux/set_memory.h | 4 +- include/linux/syscalls.h | 1 + include/uapi/asm-generic/unistd.h | 6 +- include/uapi/linux/magic.h | 1 + include/uapi/linux/secretmem.h | 8 + kernel/power/hibernate.c | 5 +- kernel/power/snapshot.c | 4 +- kernel/sys_ni.c | 2 + mm/Kconfig | 5 + mm/Makefile | 1 + mm/filemap.c | 3 +- mm/gup.c | 10 + mm/internal.h | 3 + mm/mmap.c | 5 +- mm/secretmem.c | 446 ++++++++++++++++++++++ mm/vmalloc.c | 5 +- scripts/checksyscalls.sh | 4 + tools/testing/selftests/vm/.gitignore | 1 + tools/testing/selftests/vm/Makefile | 3 +- tools/testing/selftests/vm/memfd_secret.c | 298 +++++++++++++++ tools/testing/selftests/vm/run_vmtests | 17 + 38 files changed, 891 insertions(+), 39 deletions(-) create mode 100644 include/linux/secretmem.h create mode 100644 include/uapi/linux/secretmem.h create mode 100644 mm/secretmem.c create mode 100644 tools/testing/selftests/vm/memfd_secret.c base-commit: 9f8ce377d420db12b19d6a4f636fecbd88a725a5 -- 2.28.0

3 years, 5 months

4
14
0 0

[PATCH v4 00/27]Fix several bad kernel-doc markups

by Mauro Carvalho Chehab

Kernel-doc has always be limited to a probably bad documented rule: The kernel-doc markups should appear *imediatelly before* the function or data structure that it documents. On other words, if a C file would contain something like this: /** * foo - function foo * @args: foo args */ static inline void bar(int args); /** * bar - function bar * @args: foo args */ static inline void foo(void *args); The output (in ReST format) will be: .. c:function:: void bar (int args) function foo **Parameters** ``int args`` foo args .. c:function:: void foo (void *args) function bar **Parameters** ``void *args`` foo args Which is clearly a wrong result. Before this changeset, not even a warning is produced on such cases. As placing such markups just before the documented data is a common practice, on most cases this is fine. However, as patches touch things, identifiers may be renamed, and people may forget to update the kernel-doc markups to follow such changes. This has been happening for quite a while, as there are lots of files with kernel-doc problems. This series address those issues and add a file at the end that will enforce that the identifier will match the kernel-doc markup, avoiding this problem from keep happening as time goes by. This series is based on current upstream tree. @maintainers: feel free to pick the patches and apply them directly on your trees, as all patches on this series are independent from the other ones. -- v4: - Patches got rebased and got some acks. Mauro Carvalho Chehab (27): net: phy: fix kernel-doc markups net: datagram: fix some kernel-doc markups net: core: fix some kernel-doc markups s390: fix kernel-doc markups drm: fix some kernel-doc markups HSI: fix a kernel-doc markup IB: fix kernel-doc markups parport: fix a kernel-doc markup rapidio: fix kernel-doc a markup video: fix some kernel-doc markups fs: fix kernel-doc markups jbd2: fix kernel-doc markups pstore/zone: fix a kernel-doc markup completion: fix kernel-doc markups firmware: stratix10-svc: fix kernel-doc markups connector: fix a kernel-doc markup lib/crc7: fix a kernel-doc markup hrtimer: fix kernel-doc markups genirq: fix kernel-doc markups list: fix a typo at the kernel-doc markup memblock: fix kernel-doc markups w1: fix a kernel-doc markup resource: fix kernel-doc markups shed: fix kernel-doc markup mm: fix kernel-doc markups selftests: kselftest_harness.h: partially fix kernel-doc markups scripts: kernel-doc: validate kernel-doc markup with the actual names arch/s390/include/asm/ccwdev.h | 2 +- arch/s390/include/asm/cio.h | 2 +- drivers/gpu/drm/drm_atomic_state_helper.c | 2 +- drivers/gpu/drm/drm_connector.c | 3 +- drivers/gpu/drm/drm_dp_helper.c | 2 +- drivers/gpu/drm/drm_framebuffer.c | 2 +- drivers/gpu/drm/drm_gem.c | 4 +- drivers/gpu/drm/drm_gem_vram_helper.c | 2 +- drivers/gpu/drm/drm_mode_object.c | 2 +- drivers/gpu/drm/drm_modes.c | 4 +- drivers/gpu/drm/drm_scdc_helper.c | 2 +- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +- drivers/gpu/drm/i915/i915_gem_evict.c | 2 +- drivers/gpu/drm/i915/i915_perf.c | 8 ++- drivers/gpu/drm/scheduler/sched_main.c | 2 +- drivers/gpu/drm/v3d/v3d_sched.c | 2 +- drivers/gpu/drm/vc4/vc4_bo.c | 2 +- drivers/hsi/hsi_core.c | 2 +- drivers/infiniband/core/cm.c | 5 +- drivers/infiniband/core/cq.c | 4 +- drivers/infiniband/core/iwpm_util.h | 2 +- drivers/infiniband/core/sa_query.c | 3 +- drivers/infiniband/core/verbs.c | 4 +- drivers/infiniband/sw/rdmavt/ah.c | 2 +- drivers/infiniband/sw/rdmavt/mcast.c | 12 ++-- drivers/infiniband/sw/rdmavt/qp.c | 8 +-- drivers/infiniband/ulp/iser/iscsi_iser.c | 2 +- .../infiniband/ulp/opa_vnic/opa_vnic_encap.h | 2 +- .../ulp/opa_vnic/opa_vnic_vema_iface.c | 2 +- drivers/infiniband/ulp/srpt/ib_srpt.h | 2 +- drivers/net/phy/mdio_bus.c | 2 +- drivers/net/phy/phy-c45.c | 2 +- drivers/net/phy/phy.c | 2 +- drivers/net/phy/phy_device.c | 2 +- drivers/net/phy/phylink.c | 2 +- drivers/parport/share.c | 2 +- drivers/rapidio/rio.c | 2 +- drivers/video/fbdev/core/fbcmap.c | 2 +- drivers/video/hdmi.c | 3 +- fs/dcache.c | 72 +++++++++---------- fs/inode.c | 4 +- fs/jbd2/journal.c | 34 ++++----- fs/jbd2/transaction.c | 31 ++++---- fs/pstore/zone.c | 2 +- fs/seq_file.c | 5 +- fs/super.c | 12 ++-- include/drm/drm_atomic_helper.h | 4 +- include/drm/drm_connector.h | 2 +- include/drm/drm_device.h | 2 +- include/drm/drm_dsc.h | 3 +- include/drm/drm_gem_vram_helper.h | 8 +-- include/linux/completion.h | 10 ++- include/linux/connector.h | 2 +- .../firmware/intel/stratix10-svc-client.h | 10 +-- include/linux/hrtimer.h | 6 +- include/linux/jbd2.h | 2 +- include/linux/list.h | 2 +- include/linux/memblock.h | 4 +- include/linux/netdevice.h | 11 ++- include/linux/parport.h | 31 ++++++++ include/linux/w1.h | 2 +- include/rdma/ib_verbs.h | 11 +++ kernel/irq/chip.c | 2 +- kernel/irq/generic-chip.c | 2 +- kernel/resource.c | 24 ++++--- kernel/sched/core.c | 16 ++--- kernel/sched/fair.c | 2 +- kernel/time/hrtimer.c | 2 +- lib/crc7.c | 2 +- mm/gup.c | 24 ++++--- mm/page_alloc.c | 16 ++--- mm/truncate.c | 10 ++- net/core/datagram.c | 2 +- net/core/dev.c | 4 +- net/core/skbuff.c | 2 +- net/ethernet/eth.c | 6 +- net/sunrpc/rpc_pipe.c | 3 +- scripts/kernel-doc | 62 +++++++++++----- tools/testing/selftests/kselftest_harness.h | 22 +++--- 79 files changed, 350 insertions(+), 235 deletions(-) -- 2.28.0

3 years, 5 months

2
2
0 0

[RFC PATCH 0/6] Split huge pages to any lower order pages.

by Zi Yan

From: Zi Yan <ziy(a)nvidia.com> Hi all, With Matthew's THP in pagecache patches[1], we will be able to handle any size pagecache THPs, but currently split_huge_page can only split a THP to order-0 pages. This can easily erase the benefit of having pagecache THPs, when operations like truncate might want to keep pages larger than order-0. In response, here is the patches to add support for splitting a THP to any lower order pages. In addition, this patchset prepares for my PUD THP patchset[2], since splitting a PUD THP to multiple PMD THPs can be handled by split_huge_page_to_list_to_order function added by this patchset, which reduces a lot of redundant code without just replicating split_huge_page for PUD THP. The patchset is on top of Matthew's pagecache/next tree[3]. To ease the tests of split_huge_page functions, I added a new debugfs interface at <debugfs>/split_huge_pages_in_range_pid, so developers can split THPs in a given range from a process with the given pid by writing "<pid>,<vaddr_start>,<vaddr_end>,<to_order>" to the interface. I also added a new test program to test 1) split PMD THPs, 2) split pagecache THPs to any lower order, and 3) truncating a pagecache THP to a page with a lower order. Suggestions and comments are welcome. Thanks. [1] https://lore.kernel.org/linux-mm/20201029193405.29125-1-willy@infradead.org/ [2] https://lore.kernel.org/linux-mm/20200928175428.4110504-1-zi.yan@sent.com/ [3] https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/heads/next Zi Yan (6): mm: huge_memory: add new debugfs interface to trigger split huge page on any page range. mm: memcg: make memcg huge page split support any order split. mm: page_owner: add support for splitting to any order in split page_owner. mm: thp: add support for split huge page to any lower order pages. mm: truncate: split thp to a non-zero order if possible. mm: huge_memory: enable debugfs to split huge pages to any order. include/linux/huge_mm.h | 8 + include/linux/memcontrol.h | 5 +- include/linux/page_owner.h | 7 +- mm/huge_memory.c | 177 ++++++++++-- mm/internal.h | 1 + mm/memcontrol.c | 4 +- mm/migrate.c | 2 +- mm/page_alloc.c | 2 +- mm/page_owner.c | 6 +- mm/swap.c | 1 - mm/truncate.c | 22 +- tools/testing/selftests/vm/Makefile | 1 + .../selftests/vm/split_huge_page_test.c | 255 ++++++++++++++++++ 13 files changed, 453 insertions(+), 38 deletions(-) create mode 100644 tools/testing/selftests/vm/split_huge_page_test.c -- 2.28.0

3 years, 5 months

6
35
0 0

[PATCH v8 0/9] mm: introduce memfd_secret system call to create "secret" memory areas

by Mike Rapoport

From: Mike Rapoport <rppt(a)linux.ibm.com> Hi, This is an implementation of "secret" mappings backed by a file descriptor. The file descriptor backing secret memory mappings is created using a dedicated memfd_secret system call The desired protection mode for the memory is configured using flags parameter of the system call. The mmap() of the file descriptor created with memfd_secret() will create a "secret" memory mapping. The pages in that mapping will be marked as not present in the direct map and will have desired protection bits set in the user page table. For instance, current implementation allows uncached mappings. Although normally Linux userspace mappings are protected from other users, such secret mappings are useful for environments where a hostile tenant is trying to trick the kernel into giving them access to other tenants mappings. Additionally, in the future the secret mappings may be used as a mean to protect guest memory in a virtual machine host. For demonstration of secret memory usage we've created a userspace library https://git.kernel.org/pub/scm/linux/kernel/git/jejb/secret-memory-preloade… that does two things: the first is act as a preloader for openssl to redirect all the OPENSSL_malloc calls to secret memory meaning any secret keys get automatically protected this way and the other thing it does is expose the API to the user who needs it. We anticipate that a lot of the use cases would be like the openssl one: many toolkits that deal with secret keys already have special handling for the memory to try to give them greater protection, so this would simply be pluggable into the toolkits without any need for user application modification. Hiding secret memory mappings behind an anonymous file allows (ab)use of the page cache for tracking pages allocated for the "secret" mappings as well as using address_space_operations for e.g. page migration callbacks. The anonymous file may be also used implicitly, like hugetlb files, to implement mmap(MAP_SECRET) and use the secret memory areas with "native" mm ABIs in the future. To limit fragmentation of the direct map to splitting only PUD-size pages, I've added an amortizing cache of PMD-size pages to each file descriptor that is used as an allocation pool for the secret memory areas. As the memory allocated by secretmem becomes unmovable, we use CMA to back large page caches so that page allocator won't be surprised by failing attempt to migrate these pages. v8: * Use CMA for all secretmem allocations as David suggested * Update memcg accounting after transtion to CMA * Prevent hibernation when there are active secretmem users * Add zeroing of the memory before releasing it back to cma/page allocator * Rebase on v5.10-rc2-mmotm-2020-11-07-21-40 v7: https://lore.kernel.org/lkml/20201026083752.13267-1-rppt@kernel.org * Use set_direct_map() instead of __kernel_map_pages() to ensure error handling in case the direct map update fails * Add accounting of large pages used to reduce the direct map fragmentation * Teach get_user_pages() and frieds to refuse get/pin secretmem pages v6: https://lore.kernel.org/lkml/20200924132904.1391-1-rppt@kernel.org * Silence the warning about missing syscall, thanks to Qian Cai * Replace spaces with tabs in Kconfig additions, per Randy * Add a selftest. v5: https://lore.kernel.org/lkml/20200916073539.3552-1-rppt@kernel.org * rebase on v5.9-rc5 * drop boot time memory reservation patch v4: https://lore.kernel.org/lkml/20200818141554.13945-1-rppt@kernel.org * rebase on v5.9-rc1 * Do not redefine PMD_PAGE_ORDER in fs/dax.c, thanks Kirill * Make secret mappings exclusive by default and only require flags to memfd_secret() system call for uncached mappings, thanks again Kirill :) v3: https://lore.kernel.org/lkml/20200804095035.18778-1-rppt@kernel.org * Squash kernel-parameters.txt update into the commit that added the command line option. * Make uncached mode explicitly selectable by architectures. For now enable it only on x86. v2: https://lore.kernel.org/lkml/20200727162935.31714-1-rppt@kernel.org * Follow Michael's suggestion and name the new system call 'memfd_secret' * Add kernel-parameters documentation about the boot option * Fix i386-tinyconfig regression reported by the kbuild bot. CONFIG_SECRETMEM now depends on !EMBEDDED to disable it on small systems from one side and still make it available unconditionally on architectures that support SET_DIRECT_MAP. v1: https://lore.kernel.org/lkml/20200720092435.17469-1-rppt@kernel.org Mike Rapoport (9): mm: add definition of PMD_PAGE_ORDER mmap: make mlock_future_check() global set_memory: allow set_direct_map_*_noflush() for multiple pages mm: introduce memfd_secret system call to create "secret" memory areas secretmem: use PMD-size pages to amortize direct map fragmentation secretmem: add memcg accounting PM: hibernate: disable when there are active secretmem users arch, mm: wire up memfd_secret system call were relevant secretmem: test: add basic selftest for memfd_secret(2) arch/Kconfig | 7 + arch/arm64/include/asm/cacheflush.h | 4 +- arch/arm64/include/asm/unistd.h | 2 +- arch/arm64/include/asm/unistd32.h | 2 + arch/arm64/include/uapi/asm/unistd.h | 1 + arch/arm64/mm/pageattr.c | 10 +- arch/riscv/include/asm/set_memory.h | 4 +- arch/riscv/include/asm/unistd.h | 1 + arch/riscv/mm/pageattr.c | 8 +- arch/x86/Kconfig | 1 + arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/entry/syscalls/syscall_64.tbl | 1 + arch/x86/include/asm/set_memory.h | 4 +- arch/x86/mm/pat/set_memory.c | 8 +- fs/dax.c | 11 +- include/linux/pgtable.h | 3 + include/linux/secretmem.h | 30 ++ include/linux/set_memory.h | 4 +- include/linux/syscalls.h | 1 + include/uapi/asm-generic/unistd.h | 6 +- include/uapi/linux/magic.h | 1 + include/uapi/linux/secretmem.h | 8 + kernel/power/hibernate.c | 5 +- kernel/power/snapshot.c | 4 +- kernel/sys_ni.c | 2 + mm/Kconfig | 5 + mm/Makefile | 1 + mm/filemap.c | 2 +- mm/gup.c | 10 + mm/internal.h | 3 + mm/mmap.c | 5 +- mm/secretmem.c | 451 ++++++++++++++++++++++ mm/vmalloc.c | 5 +- scripts/checksyscalls.sh | 4 + tools/testing/selftests/vm/.gitignore | 1 + tools/testing/selftests/vm/Makefile | 3 +- tools/testing/selftests/vm/memfd_secret.c | 298 ++++++++++++++ tools/testing/selftests/vm/run_vmtests | 17 + 38 files changed, 895 insertions(+), 39 deletions(-) create mode 100644 include/linux/secretmem.h create mode 100644 include/uapi/linux/secretmem.h create mode 100644 mm/secretmem.c create mode 100644 tools/testing/selftests/vm/memfd_secret.c base-commit: 9f8ce377d420db12b19d6a4f636fecbd88a725a5 -- 2.28.0

3 years, 5 months

6
28
0 0

[PATCH v4 1/6] lib/list_kunit: Follow new file name convention for KUnit tests

by Andy Shevchenko

Follow new file name convention for the KUnit tests. Since we have lib/*test*.c in a few variations, use 'kunit' suffix to distinguish usual test cases with KUnit-based ones. Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Reviewed-by: David Gow <davidgow(a)google.com> Acked-by: Brendan Higgins <brendanhiggins(a)google.com> --- v4: added tag (Brendan) MAINTAINERS | 2 +- lib/Makefile | 2 +- lib/{list-test.c => list_kunit.c} | 0 3 files changed, 2 insertions(+), 2 deletions(-) rename lib/{list-test.c => list_kunit.c} (100%) diff --git a/MAINTAINERS b/MAINTAINERS index f1f088a29bc2..5901b817d0bc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10222,7 +10222,7 @@ M: David Gow <davidgow(a)google.com> L: linux-kselftest(a)vger.kernel.org L: kunit-dev(a)googlegroups.com S: Maintained -F: lib/list-test.c +F: lib/list_kunit.c LITEX PLATFORM M: Karol Gugala <kgugala(a)antmicro.com> diff --git a/lib/Makefile b/lib/Makefile index ce45af50983a..9d78ef73d6ed 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -349,6 +349,6 @@ obj-$(CONFIG_PLDMFW) += pldmfw/ # KUnit tests obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o -obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o +obj-$(CONFIG_LIST_KUNIT_TEST) += list_kunit.o obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o obj-$(CONFIG_BITS_TEST) += test_bits.o diff --git a/lib/list-test.c b/lib/list_kunit.c similarity index 100% rename from lib/list-test.c rename to lib/list_kunit.c -- 2.28.0

3 years, 5 months

5
12
0 0

[PATCH AUTOSEL 4.19 3/6] selftests: kvm: Fix the segment descriptor layout to match the actual layout

by Sasha Levin

From: Aaron Lewis <aaronlewis(a)google.com> [ Upstream commit df11f7dd5834146defa448acba097e8d7703cc42 ] Fix the layout of 'struct desc64' to match the layout described in the SDM Vol 3, Chapter 3 "Protected-Mode Memory Management", section 3.4.5 "Segment Descriptors", Figure 3-8 "Segment Descriptor". The test added later in this series relies on this and crashes if this layout is not correct. Signed-off-by: Aaron Lewis <aaronlewis(a)google.com> Reviewed-by: Alexander Graf <graf(a)amazon.com> Message-Id: <20201012194716.3950330-2-aaronlewis(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/kvm/include/x86.h | 2 +- tools/testing/selftests/kvm/lib/x86.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/kvm/include/x86.h b/tools/testing/selftests/kvm/include/x86.h index 42c3596815b83..a7667a613bbc7 100644 --- a/tools/testing/selftests/kvm/include/x86.h +++ b/tools/testing/selftests/kvm/include/x86.h @@ -59,7 +59,7 @@ enum x86_register { struct desc64 { uint16_t limit0; uint16_t base0; - unsigned base1:8, s:1, type:4, dpl:2, p:1; + unsigned base1:8, type:4, s:1, dpl:2, p:1; unsigned limit1:4, avl:1, l:1, db:1, g:1, base2:8; uint32_t base3; uint32_t zero1; diff --git a/tools/testing/selftests/kvm/lib/x86.c b/tools/testing/selftests/kvm/lib/x86.c index 4d35eba73dc97..800fe36064f9a 100644 --- a/tools/testing/selftests/kvm/lib/x86.c +++ b/tools/testing/selftests/kvm/lib/x86.c @@ -449,11 +449,12 @@ static void kvm_seg_fill_gdt_64bit(struct kvm_vm *vm, struct kvm_segment *segp) desc->limit0 = segp->limit & 0xFFFF; desc->base0 = segp->base & 0xFFFF; desc->base1 = segp->base >> 16; - desc->s = segp->s; desc->type = segp->type; + desc->s = segp->s; desc->dpl = segp->dpl; desc->p = segp->present; desc->limit1 = segp->limit >> 16; + desc->avl = segp->avl; desc->l = segp->l; desc->db = segp->db; desc->g = segp->g; -- 2.27.0

3 years, 5 months

1
0
0 0

[PATCH AUTOSEL 5.4 03/11] selftests: kvm: Fix the segment descriptor layout to match the actual layout

by Sasha Levin

From: Aaron Lewis <aaronlewis(a)google.com> [ Upstream commit df11f7dd5834146defa448acba097e8d7703cc42 ] Fix the layout of 'struct desc64' to match the layout described in the SDM Vol 3, Chapter 3 "Protected-Mode Memory Management", section 3.4.5 "Segment Descriptors", Figure 3-8 "Segment Descriptor". The test added later in this series relies on this and crashes if this layout is not correct. Signed-off-by: Aaron Lewis <aaronlewis(a)google.com> Reviewed-by: Alexander Graf <graf(a)amazon.com> Message-Id: <20201012194716.3950330-2-aaronlewis(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/kvm/include/x86_64/processor.h | 2 +- tools/testing/selftests/kvm/lib/x86_64/processor.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/kvm/include/x86_64/processor.h b/tools/testing/selftests/kvm/include/x86_64/processor.h index ff234018219cf..aead07c24afcf 100644 --- a/tools/testing/selftests/kvm/include/x86_64/processor.h +++ b/tools/testing/selftests/kvm/include/x86_64/processor.h @@ -57,7 +57,7 @@ enum x86_register { struct desc64 { uint16_t limit0; uint16_t base0; - unsigned base1:8, s:1, type:4, dpl:2, p:1; + unsigned base1:8, type:4, s:1, dpl:2, p:1; unsigned limit1:4, avl:1, l:1, db:1, g:1, base2:8; uint32_t base3; uint32_t zero1; diff --git a/tools/testing/selftests/kvm/lib/x86_64/processor.c b/tools/testing/selftests/kvm/lib/x86_64/processor.c index 6698cb741e10a..7d8f7fc736467 100644 --- a/tools/testing/selftests/kvm/lib/x86_64/processor.c +++ b/tools/testing/selftests/kvm/lib/x86_64/processor.c @@ -446,11 +446,12 @@ static void kvm_seg_fill_gdt_64bit(struct kvm_vm *vm, struct kvm_segment *segp) desc->limit0 = segp->limit & 0xFFFF; desc->base0 = segp->base & 0xFFFF; desc->base1 = segp->base >> 16; - desc->s = segp->s; desc->type = segp->type; + desc->s = segp->s; desc->dpl = segp->dpl; desc->p = segp->present; desc->limit1 = segp->limit >> 16; + desc->avl = segp->avl; desc->l = segp->l; desc->db = segp->db; desc->g = segp->g; -- 2.27.0

3 years, 5 months

1
0
0 0

[PATCH AUTOSEL 5.9 08/21] selftests: kvm: Fix the segment descriptor layout to match the actual layout

by Sasha Levin

From: Aaron Lewis <aaronlewis(a)google.com> [ Upstream commit df11f7dd5834146defa448acba097e8d7703cc42 ] Fix the layout of 'struct desc64' to match the layout described in the SDM Vol 3, Chapter 3 "Protected-Mode Memory Management", section 3.4.5 "Segment Descriptors", Figure 3-8 "Segment Descriptor". The test added later in this series relies on this and crashes if this layout is not correct. Signed-off-by: Aaron Lewis <aaronlewis(a)google.com> Reviewed-by: Alexander Graf <graf(a)amazon.com> Message-Id: <20201012194716.3950330-2-aaronlewis(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/kvm/include/x86_64/processor.h | 2 +- tools/testing/selftests/kvm/lib/x86_64/processor.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/kvm/include/x86_64/processor.h b/tools/testing/selftests/kvm/include/x86_64/processor.h index 82b7fe16a8242..0a65e7bb5249e 100644 --- a/tools/testing/selftests/kvm/include/x86_64/processor.h +++ b/tools/testing/selftests/kvm/include/x86_64/processor.h @@ -59,7 +59,7 @@ struct gpr64_regs { struct desc64 { uint16_t limit0; uint16_t base0; - unsigned base1:8, s:1, type:4, dpl:2, p:1; + unsigned base1:8, type:4, s:1, dpl:2, p:1; unsigned limit1:4, avl:1, l:1, db:1, g:1, base2:8; uint32_t base3; uint32_t zero1; diff --git a/tools/testing/selftests/kvm/lib/x86_64/processor.c b/tools/testing/selftests/kvm/lib/x86_64/processor.c index f6eb34eaa0d22..1ccf6c9b3476d 100644 --- a/tools/testing/selftests/kvm/lib/x86_64/processor.c +++ b/tools/testing/selftests/kvm/lib/x86_64/processor.c @@ -392,11 +392,12 @@ static void kvm_seg_fill_gdt_64bit(struct kvm_vm *vm, struct kvm_segment *segp) desc->limit0 = segp->limit & 0xFFFF; desc->base0 = segp->base & 0xFFFF; desc->base1 = segp->base >> 16; - desc->s = segp->s; desc->type = segp->type; + desc->s = segp->s; desc->dpl = segp->dpl; desc->p = segp->present; desc->limit1 = segp->limit >> 16; + desc->avl = segp->avl; desc->l = segp->l; desc->db = segp->db; desc->g = segp->g; -- 2.27.0

3 years, 5 months

1
0
0 0

[PATCH v6 0/6] mm: introduce memfd_secret system call to create "secret" memory areas

by Mike Rapoport

From: Mike Rapoport <rppt(a)linux.ibm.com> Hi, This is an implementation of "secret" mappings backed by a file descriptor. I've dropped the boot time reservation patch for now as it is not strictly required for the basic usage and can be easily added later either with or without CMA. v6 changes: * Silence the warning about missing syscall, thanks to Qian Cai * Replace spaces with tabs in Kconfig additions, per Randy * Add a selftest. v5 changes: * rebase on v5.9-rc5 * drop boot time memory reservation patch v4 changes: * rebase on v5.9-rc1 * Do not redefine PMD_PAGE_ORDER in fs/dax.c, thanks Kirill * Make secret mappings exclusive by default and only require flags to memfd_secret() system call for uncached mappings, thanks again Kirill :) v3 changes: * Squash kernel-parameters.txt update into the commit that added the command line option. * Make uncached mode explicitly selectable by architectures. For now enable it only on x86. v2 changes: * Follow Michael's suggestion and name the new system call 'memfd_secret' * Add kernel-parameters documentation about the boot option * Fix i386-tinyconfig regression reported by the kbuild bot. CONFIG_SECRETMEM now depends on !EMBEDDED to disable it on small systems from one side and still make it available unconditionally on architectures that support SET_DIRECT_MAP. The file descriptor backing secret memory mappings is created using a dedicated memfd_secret system call The desired protection mode for the memory is configured using flags parameter of the system call. The mmap() of the file descriptor created with memfd_secret() will create a "secret" memory mapping. The pages in that mapping will be marked as not present in the direct map and will have desired protection bits set in the user page table. For instance, current implementation allows uncached mappings. Although normally Linux userspace mappings are protected from other users, such secret mappings are useful for environments where a hostile tenant is trying to trick the kernel into giving them access to other tenants mappings. Additionally, the secret mappings may be used as a mean to protect guest memory in a virtual machine host. For demonstration of secret memory usage we've created a userspace library [1] that does two things: the first is act as a preloader for openssl to redirect all the OPENSSL_malloc calls to secret memory meaning any secret keys get automatically protected this way and the other thing it does is expose the API to the user who needs it. We anticipate that a lot of the use cases would be like the openssl one: many toolkits that deal with secret keys already have special handling for the memory to try to give them greater protection, so this would simply be pluggable into the toolkits without any need for user application modification. I've hesitated whether to continue to use new flags to memfd_create() or to add a new system call and I've decided to use a new system call after I've started to look into man pages update. There would have been two completely independent descriptions and I think it would have been very confusing. Hiding secret memory mappings behind an anonymous file allows (ab)use of the page cache for tracking pages allocated for the "secret" mappings as well as using address_space_operations for e.g. page migration callbacks. The anonymous file may be also used implicitly, like hugetlb files, to implement mmap(MAP_SECRET) and use the secret memory areas with "native" mm ABIs in the future. As the fragmentation of the direct map was one of the major concerns raised during the previous postings, I've added an amortizing cache of PMD-size pages to each file descriptor that is used as an allocation pool for the secret memory areas. v5: https://lore.kernel.org/lkml/20200916073539.3552-1-rppt@kernel.org v4: https://lore.kernel.org/lkml/20200818141554.13945-1-rppt@kernel.org v3: https://lore.kernel.org/lkml/20200804095035.18778-1-rppt@kernel.org v2: https://lore.kernel.org/lkml/20200727162935.31714-1-rppt@kernel.org v1: https://lore.kernel.org/lkml/20200720092435.17469-1-rppt@kernel.org Mike Rapoport (6): mm: add definition of PMD_PAGE_ORDER mmap: make mlock_future_check() global mm: introduce memfd_secret system call to create "secret" memory areas arch, mm: wire up memfd_secret system call were relevant mm: secretmem: use PMD-size pages to amortize direct map fragmentation secretmem: test: add basic selftest for memfd_secret(2) arch/Kconfig | 7 + arch/arm64/include/asm/unistd.h | 2 +- arch/arm64/include/asm/unistd32.h | 2 + arch/arm64/include/uapi/asm/unistd.h | 1 + arch/riscv/include/asm/unistd.h | 1 + arch/x86/Kconfig | 1 + arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/entry/syscalls/syscall_64.tbl | 1 + fs/dax.c | 11 +- include/linux/pgtable.h | 3 + include/linux/syscalls.h | 1 + include/uapi/asm-generic/unistd.h | 7 +- include/uapi/linux/magic.h | 1 + include/uapi/linux/secretmem.h | 8 + kernel/sys_ni.c | 2 + mm/Kconfig | 4 + mm/Makefile | 1 + mm/internal.h | 3 + mm/mmap.c | 5 +- mm/secretmem.c | 333 ++++++++++++++++++++++ scripts/checksyscalls.sh | 4 + tools/testing/selftests/vm/.gitignore | 1 + tools/testing/selftests/vm/Makefile | 3 +- tools/testing/selftests/vm/memfd_secret.c | 296 +++++++++++++++++++ tools/testing/selftests/vm/run_vmtests | 17 ++ 25 files changed, 703 insertions(+), 13 deletions(-) create mode 100644 include/uapi/linux/secretmem.h create mode 100644 mm/secretmem.c create mode 100644 tools/testing/selftests/vm/memfd_secret.c -- 2.28.0

3 years, 5 months

14
56
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror November 2020