From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E83151B28D for ; Sat, 16 Mar 2024 14:16:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.70.40.134 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710598596; cv=none; b=pGSvCFUzUjELmCbiHe8itOdYtJuvHGNGDfnk9ljsKs/UGI1XUiYDb2rakWNEdneh8tL989lVaHXUzPcow8REJnfsIHhb+FfwolNUrVnQyddTQWYMt2D18r+xXCb/XOoK4McVdtlX+sa2NOdEkJw/HOif7L6AlPKsKtIZIyXRMgU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710598596; c=relaxed/simple; bh=mJ30TjJevPsvaLmDSaXPLq8e51apoHgFwkUiNnGZb2Y=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Qb5IeLYVb7qmDHFuVWWaViZFdQO0ae9lNXMAseXIl6+5XSIAMfZf+3RaHdUqsVN1OhLWOqQaT1Pa5FXBaydOsJzZcI1F4r3X/pF4l44rldFGJGTVzIFPh4AiomEAY+KX+iyAnXOpGhdg1zPvcpeR12RzzWDhaSoGJVshB3tXI6s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me; spf=pass smtp.mailfrom=proton.me; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b=CM93QCfd; arc=none smtp.client-ip=185.70.40.134 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=proton.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b="CM93QCfd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1710598585; x=1710857785; bh=mJ30TjJevPsvaLmDSaXPLq8e51apoHgFwkUiNnGZb2Y=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=CM93QCfdmepzajlDwRdrBx35pjQDO5CM1XRroIcXqUBwtmz9WPbXz8w/K/x+D8lfn WtoOEiqfLKXaOs9MFX+bVheTQwKuGb0Il/Q0LY1YWRel7Yc2NO63qLGAb9lR6RXpZT b9z34hxT8eX/PyWyB2U6oM2WXXz/6kRD+3+YJB2+ec7qsQ6hCo0IOqkLaDdp3d6p5f RbZtqDvMGwAQLl3FLLY/ECx3Bf6K2f5zd5JvGItQv/eoAYENSy6P0pg2aH0921dlua iKvrCCLMR4P9xUubQ/DON9Gn+QWn2XWDV/lMj8SKLbw5Ribfd1XKmsTtLA1fQTW88L xNgmEBXzNgPHw== Date: Sat, 16 Mar 2024 14:16:11 +0000 To: Alice Ryhl , Miguel Ojeda , Matthew Wilcox , Al Viro , Andrew Morton , Kees Cook From: Benno Lossin Cc: Alex Gaynor , Wedson Almeida Filho , Boqun Feng , Gary Guo , =?utf-8?Q?Bj=C3=B6rn_Roy_Baron?= , Andreas Hindborg , Greg Kroah-Hartman , =?utf-8?Q?Arve_Hj=C3=B8nnev=C3=A5g?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Carlos Llamas , Suren Baghdasaryan , Arnd Bergmann , linux-mm@kvack.org, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, Christian Brauner Subject: Re: [PATCH v3 1/4] rust: uaccess: add userspace pointers Message-ID: In-Reply-To: <20240311-alice-mm-v3-1-cdf7b3a2049c@google.com> References: <20240311-alice-mm-v3-0-cdf7b3a2049c@google.com> <20240311-alice-mm-v3-1-cdf7b3a2049c@google.com> Feedback-ID: 71780778:user:proton Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/11/24 11:47, Alice Ryhl wrote: > From: Wedson Almeida Filho >=20 > A pointer to an area in userspace memory, which can be either read-only > or read-write. >=20 > All methods on this struct are safe: invalid pointers return `EFAULT`. > Concurrent access, *including data races to/from userspace memory*, is > permitted, because fundamentally another userspace thread/process could > always be modifying memory at the same time (in the same way that > userspace Rust's `std::io` permits data races with the contents of > files on disk). In the presence of a race, the exact byte values > read/written are unspecified but the operation is well-defined. > Kernelspace code should validate its copy of data after completing a > read, and not expect that multiple reads of the same address will return > the same value. >=20 > These APIs are designed to make it difficult to accidentally write > TOCTOU bugs. Every time you read from a memory location, the pointer is > advanced by the length so that you cannot use that reader to read the > same memory location twice. Preventing double-fetches avoids TOCTOU > bugs. This is accomplished by taking `self` by value to prevent > obtaining multiple readers on a given `UserSlicePtr`, and the readers > only permitting forward reads. If double-fetching a memory location is > necessary for some reason, then that is done by creating multiple > readers to the same memory location. >=20 > Constructing a `UserSlicePtr` performs no checks on the provided > address and length, it can safely be constructed inside a kernel thread > with no current userspace process. Reads and writes wrap the kernel APIs > `copy_from_user` and `copy_to_user`, which check the memory map of the > current process and enforce that the address range is within the user > range (no additional calls to `access_ok` are needed). >=20 > This code is based on something that was originally written by Wedson on > the old rust branch. It was modified by Alice by removing the > `IoBufferReader` and `IoBufferWriter` traits, and various other changes. >=20 > Signed-off-by: Wedson Almeida Filho > Co-developed-by: Alice Ryhl > Signed-off-by: Alice Ryhl Reviewed-by: Benno Lossin