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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z5njA9SLWxlRYgow@debug.ba.rivosinc.com>
Date: Wed, 29 Jan 2025 00:12:51 -0800
From: Deepak Gupta <debug@...osinc.com>
To: Chunyan Zhang <zhangchunyan@...as.ac.cn>
Cc: Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Alexandre Ghiti <alex@...ti.fr>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Chunyan Zhang <zhang.lyra@...il.com>
Subject: Re: [PATCH V5 0/3] riscv: mm: Add soft-dirty and uffd-wp support

On Wed, Nov 13, 2024 at 05:58:30PM +0800, Chunyan Zhang wrote:
>This patchset adds soft dirty and userfaultfd write protect tracking
>support for RISC-V.
>
>As described in the patches, we are trying to utilize only one free PTE
>bit(9) to support three kernel features (devmap, soft-dirty, uffd-wp).
>Users cannot have them supported at the same time (have to select
>one when building the kernel).

Why do we expect a user won't be using all these three kernel features
(devmap, soft-dirty and uffd-wp). I do understand the part that their
interaction with each other is mutually exclusive but their usage (from
an user's perspective) is not mutually exclusive. So forcing this choice
on user at kernel build time is way too restrictive. Additionally this
forces distros to carry 3 different builds (they dont know which user is
expecting to use which kernel build).

As an example if I were running microVMs to host something like serverless
(lambda), I could be taking live snapshots and that would require me to
enable uffd-wp. At the same time I could be using criu to snapshot some
task.

Locking in at the kernel build time takes that choice away.

IMHO, this should be done in a way which doesn't take away the choice
from user. And if there is no choice left from sw workaround perspective,
then right approach would be to ask RISC-V to cough-up more RSW bits.

>
>This patchset has been tested with:
>1) The kselftest mm suite in which soft-dirty, madv_populate,
>test_unmerge_uffd_wp, and uffd-unit-tests run and pass, and no regressions
>are observed in any of the other tests.
>
>2) CRIU:
>- 'criu check --feature mem_dirty_track' returns supported;
>- incremental_dumps[1] and simple_loop [2] dump and restores work fine;
>- zdtm test suite can run under host mode.
>
>This patchset applies on top of v6.12-rc7.
>
>V5:
>- Fixed typos and corrected some words in Kconfig and commit message;
>- Removed pte_wrprotect() from pte_swp_mkuffd_wp(), this is a copy-paste error;
>- Added Alex's Reviewed-by tag in patch 2.
>
>V4:
>- Added bit(4) descriptions into "Format of swap PTE".
>
>V3:
>- Fixed the issue reported by kernel test irobot <lkp@...el.com>.
>
>V1 -> V2:
>- Add uffd-wp supported;
>- Make soft-dirty uffd-wp and devmap mutually exclusive which all use the same PTE bit;
>- Add test results of CRIU in the cover-letter.
>
>[1] https://www.criu.org/Incremental_dumps
>[2] https://asciinema.org/a/232445
>
>Chunyan Zhang (3):
>  riscv: mm: Prepare for reusing PTE RSW bit(9)
>  riscv: mm: Add soft-dirty page tracking support
>  riscv: mm: Add uffd write-protect support
>
> arch/riscv/Kconfig                    |  34 ++++++-
> arch/riscv/include/asm/pgtable-64.h   |   2 +-
> arch/riscv/include/asm/pgtable-bits.h |  31 ++++++
> arch/riscv/include/asm/pgtable.h      | 133 +++++++++++++++++++++++++-
> 4 files changed, 197 insertions(+), 3 deletions(-)
>
>-- 
>2.34.1
>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ