From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3BDB0C43331 for ; Wed, 1 Apr 2020 05:19:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6B4F82071A for ; Wed, 1 Apr 2020 05:19:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6B4F82071A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=SDF.ORG Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0A0856B006C; Wed, 1 Apr 2020 01:19:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 029A96B006E; Wed, 1 Apr 2020 01:19:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E5B426B0070; Wed, 1 Apr 2020 01:19:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0163.hostedemail.com [216.40.44.163]) by kanga.kvack.org (Postfix) with ESMTP id C98466B006C for ; Wed, 1 Apr 2020 01:19:39 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7A555180AD802 for ; Wed, 1 Apr 2020 05:19:39 +0000 (UTC) X-FDA: 76658133678.05.maid83_37263362a6d2b X-HE-Tag: maid83_37263362a6d2b X-Filterd-Recvd-Size: 3230 Received: from mx.sdf.org (mx.sdf.org [205.166.94.20]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Wed, 1 Apr 2020 05:19:38 +0000 (UTC) Received: from sdf.org (IDENT:lkml@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 0315I32g012695 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 1 Apr 2020 05:18:03 GMT Received: (from lkml@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 0315Hxjv027273; Wed, 1 Apr 2020 05:17:59 GMT Date: Wed, 1 Apr 2020 05:17:59 +0000 From: George Spelvin To: "Theodore Y. Ts'o" Cc: David Laight , Dan Williams , Linux Kernel Mailing List , Qian Cai , Kees Cook , Michal Hocko , Andrew Morton , Linux MM , Thomas Garnier , lkml@sdf.org Subject: lib/random32.c security Message-ID: <20200401051759.GA9616@SDF.ORG> References: <202003281643.02SGhPmY017434@sdf.org> <20200328182817.GE5859@SDF.ORG> <98bd30f23b374ccbb61dd46125dc9669@AcuMS.aculab.com> <20200329174122.GD4675@SDF.ORG> <20200329214214.GB768293@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200329214214.GB768293@mit.edu> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, Mar 29, 2020 at 05:42:14PM -0400, Theodore Y. Ts'o wrote: > If anyone is trying to rely on prandom_u32() as being "strong" in any > sense of the word in terms of being reversable by attacker --- they > shouldn't be using prandom_u32(). That's going to be true no matter > *what* algorithm we use. > > Better distribution? Sure. Making prandom_u32() faster? Absolutely; > that's its primary Raison d'Etre. I'd like your comments on an idea I had to add a second PRNG state for security-interesting applications. There are some ASLR tasks, notably slab freelist shuffling and per-syscall stack offset randomization, which need a Very Fast source of random numbers. No crypto-grade generator qualifies, and both currently use very bad ad-hoc generators. The per-syscall stack offset code currently uses the lsbits of the TSC, which is obviously bad as they're observable by the (presumed malicious) userspace immediately before the call and thus highly predictable. Likewise, the slab shuffling currently precomputes a permutation and just picks a random starting position for every slab. Both are saved by the fact that their PRNG outputs are mostly unobservable, so an attacker can't start to predict them. I was thinking that a second PRNG, identical to the prandom_u32() one but seeded speartely, could be used for this purpose. The good distribution would preclude trivial patterns in their output, which is about all we can hope for. The difference is that it would only be used for applications which both require high speed and are (mostly) unobservable to an attacker. Any opinions, anyone?