From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 9A18F107BF for ; Mon, 5 Dec 2022 19:04:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0EF08C433D6; Mon, 5 Dec 2022 19:04:19 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="cKDSYYzt" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1670267058; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oDteMypEpYpY0CiDbGvFEDl48gIcKWjcXZEnNb6r76Y=; b=cKDSYYztUncnpgz7a4ytBhfxGrSYZJQLpGzEUm7tNme//NgWpesMDn2Ig8uWOMo9VwKDzr A6sxXCwW4OT4aDtUGf7XbOJLdTVIcIY0sw1R2oyamOP9bvmPR+7aGY/z+WpYCdEpUW3Bba TnnqdkN95DzYDy4IyphCEAmnvJJ+W30= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id ac339290 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 5 Dec 2022 19:04:18 +0000 (UTC) Date: Mon, 5 Dec 2022 20:04:15 +0100 From: "Jason A. Donenfeld" To: Florian Weimer Cc: linux-kernel@vger.kernel.org, patches@lists.linux.dev, tglx@linutronix.de, linux-crypto@vger.kernel.org, linux-api@vger.kernel.org, x86@kernel.org, Greg Kroah-Hartman , Adhemerval Zanella Netto , Carlos O'Donell , Arnd Bergmann , Christian Brauner Subject: Re: [PATCH v11 3/4] random: introduce generic vDSO getrandom() implementation Message-ID: References: <20221205020046.1876356-1-Jason@zx2c4.com> <20221205020046.1876356-4-Jason@zx2c4.com> <878rjlr85s.fsf@oldenburg.str.redhat.com> Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <878rjlr85s.fsf@oldenburg.str.redhat.com> Hi Florian, On Mon, Dec 05, 2022 at 07:56:47PM +0100, Florian Weimer wrote: > * Jason A. Donenfeld: > > > +retry_generation: > > + /* > > + * @rng_info->generation must always be read here, as it serializes @state->key with the > > + * kernel's RNG reseeding schedule. > > + */ > > + current_generation = READ_ONCE(rng_info->generation); > > > + if (unlikely(READ_ONCE(state->generation) != READ_ONCE(rng_info- > > I'm pretty sure you need some sort of barrier here. We have a similar > TM-lite construct in glibc ld.so for locating link maps by address, and > there the compiler performed reordering. > > _dl_find_object miscompilation on powerpc64le > > > I'm not familiar with READ_ONCE, but Documentation/atomic_t.txt suggests > it's a “regular LOAD”, and include/asm-generic/rwonce.h concurs. Do you mean compiler barriers or SMP barriers? > Likewise, the signal safety mechanism needs compiler barriers (signal > fences). READ_ONCE() should prevent the compiler from reordering the read. > I'm also not sure how READ_ONCE realizes atomic 64-bit reads on 32-bit > platforms. i386 can do them in user space via the FPU worst-case (if > the control word hasn't been corrupted). CMPXCHG8B is not applicable > here because it's a read-only mapping. Maybe add a comment at least > about that “strong prevailing wind”? There's read tearing in that case, which isn't super, but perhaps not all together harmful. Jason