From owner-svn-src-all@freebsd.org Sun Jan 12 20:47:39 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E97261EA370; Sun, 12 Jan 2020 20:47:39 +0000 (UTC) (envelope-from cem@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47wpgv5wbxz4pKv; Sun, 12 Jan 2020 20:47:39 +0000 (UTC) (envelope-from cem@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id C202C216EA; Sun, 12 Jan 2020 20:47:39 +0000 (UTC) (envelope-from cem@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id 00CKldg3084097; Sun, 12 Jan 2020 20:47:39 GMT (envelope-from cem@FreeBSD.org) Received: (from cem@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id 00CKld5M084094; Sun, 12 Jan 2020 20:47:39 GMT (envelope-from cem@FreeBSD.org) Message-Id: <202001122047.00CKld5M084094@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: cem set sender to cem@FreeBSD.org using -f From: Conrad Meyer Date: Sun, 12 Jan 2020 20:47:39 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r356667 - in head: lib/libc/sys sys/kern sys/sys X-SVN-Group: head X-SVN-Commit-Author: cem X-SVN-Commit-Paths: in head: lib/libc/sys sys/kern sys/sys X-SVN-Commit-Revision: 356667 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2020 20:47:40 -0000 Author: cem Date: Sun Jan 12 20:47:38 2020 New Revision: 356667 URL: https://svnweb.freebsd.org/changeset/base/356667 Log: getrandom(2): Add Linux GRND_INSECURE API flag Treat it as a synonym for GRND_NONBLOCK. The reasoning is this: We have two choices for handling Linux's GRND_INSECURE API flag. 1. We could ignore it completely (like GRND_RANDOM). However, this might produce the surprising result of GRND_INSECURE requests blocking, when the Linux API does not block. 2. Alternatively, we could treat GRND_INSECURE requests as requests for GRND_NONBLOCk. Here, the surprising result for Linux programs is that invocations with unseeded random(4) will produce EAGAIN, rather than garbage. Honoring the flag in the way Linux does seems fraught. If we actually use the output of a random(4) implementation prior to seeding, we leak some entropy (in an information theory and also practical sense) from what will be the initial seed to attackers (or allow attackers to arbitrary DoS initial seeding, if we don't leak). This seems unacceptable -- it defeats the purpose of blocking on initial seeding. Secondary to that concern, before seeding we may have arbitrarily little entropy collected; producing output from zero or a handful of entropy bits does not seem particularly useful to userspace. If userspace can accept garbage, insecure, non-random bytes, they can create their own insecure garbage with srandom(time(NULL)) or similar. Any program which would be satisfied with a 3-bit key CTR stream has no need for CSPRNG bytes. So asking the kernel to produce such an output from the secure getrandom(2) API seems inane. For now, we've elected to emulate GRND_INSECURE as an alternative spelling of GRND_NONBLOCK (2). Consider this API not-quite stable for now. We guarantee it will never block. But we will attempt to monitor actual port uptake of this bizarre API and may revise our plans for the unseeded behavior (prior stable/13 branching). Approved by: csprng(markm), manpages(bcr) See also: https://lwn.net/ml/linux-kernel/cover.1577088521.git.luto@kernel.org/ See also: https://lwn.net/ml/linux-kernel/20200107204400.GH3619@mit.edu/ Differential Revision: https://reviews.freebsd.org/D23130 Modified: head/lib/libc/sys/getrandom.2 head/sys/kern/sys_getrandom.c head/sys/sys/random.h Modified: head/lib/libc/sys/getrandom.2 ============================================================================== --- head/lib/libc/sys/getrandom.2 Sun Jan 12 20:25:11 2020 (r356666) +++ head/lib/libc/sys/getrandom.2 Sun Jan 12 20:47:38 2020 (r356667) @@ -1,5 +1,4 @@ -.\" Copyright (c) 2018 Conrad Meyer -.\" All rights reserved. +.\" Copyright 2020, 2018 Conrad Meyer . All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions @@ -24,7 +23,7 @@ .\" .\" $FreeBSD$ .\" -.Dd February 24, 2018 +.Dd January 12, 2020 .Dt GETRANDOM 2 .Os .Sh NAME @@ -64,13 +63,16 @@ This flag does nothing on and .Pa /dev/urandom are identical. +.It Ql GRND_INSECURE +This flag is treated as an alternative name for +.Dv GRND_NONBLOCK . +It is provided solely for API compatibility with Linux. .El .Pp If the .Xr random 4 device has been seeded, reads of up to 256 bytes will always return as many bytes as requested and will not be interrupted by signals. -.Pp .Sh RETURN VALUES Upon successful completion, the number of bytes which were actually read is returned. @@ -87,6 +89,8 @@ operation returns the following errors: .It Bq Er EAGAIN The .Ql GRND_NONBLOCK +(or +.Ql GRND_INSECURE ) flag was set and the .Xr random 4 device was not yet seeded. @@ -111,7 +115,7 @@ was larger than .Xr getentropy 3 , .Xr random 4 .Sh STANDARDS -.Fn getentropy +.Fn getrandom is non-standard. It is present in Linux. .Sh HISTORY @@ -119,3 +123,11 @@ The .Fn getrandom system call first appeared in .Fx 12.0 . +.Sh CAVEATS +Unlike Linux, the +.Dv GRND_INSECURE +flag on +.Fx +does not produce any output before the +.Xr random 4 +device is seeded. Modified: head/sys/kern/sys_getrandom.c ============================================================================== --- head/sys/kern/sys_getrandom.c Sun Jan 12 20:25:11 2020 (r356666) +++ head/sys/kern/sys_getrandom.c Sun Jan 12 20:47:38 2020 (r356667) @@ -38,7 +38,7 @@ __FBSDID("$FreeBSD$"); #include #include -#define GRND_VALIDFLAGS (GRND_NONBLOCK | GRND_RANDOM) +#define GRND_VALIDFLAGS (GRND_NONBLOCK | GRND_RANDOM | GRND_INSECURE) /* * random_read_uio(9) returns EWOULDBLOCK if a nonblocking request would block, @@ -59,6 +59,40 @@ kern_getrandom(struct thread *td, void *user_buf, size return (EINVAL); if (buflen > IOSIZE_MAX) return (EINVAL); + + /* + * Linux compatibility: We have two choices for handling Linux's + * GRND_INSECURE. + * + * 1. We could ignore it completely (like GRND_RANDOM). However, this + * might produce the surprising result of GRND_INSECURE requests + * blocking, when the Linux API does not block. + * + * 2. Alternatively, we could treat GRND_INSECURE requests as requests + * for GRND_NONBLOCk. Here, the surprising result for Linux programs + * is that invocations with unseeded random(4) will produce EAGAIN, + * rather than garbage. + * + * Honoring the flag in the way Linux does seems fraught. If we + * actually use the output of a random(4) implementation prior to + * seeding, we leak some entropy about the initial seed to attackers. + * This seems unacceptable -- it defeats the purpose of blocking on + * initial seeding. + * + * Secondary to that concern, before seeding we may have arbitrarily + * little entropy collected; producing output from zero or a handful of + * entropy bits does not seem particularly useful to userspace. + * + * If userspace can accept garbage, insecure non-random bytes, they can + * create their own insecure garbage with srandom(time(NULL)) or + * similar. Asking the kernel to produce it from the secure + * getrandom(2) API seems inane. + * + * We elect to emulate GRND_INSECURE as an alternative spelling of + * GRND_NONBLOCK (2). + */ + if ((flags & GRND_INSECURE) != 0) + flags |= GRND_NONBLOCK; if (buflen == 0) { td->td_retval[0] = 0; Modified: head/sys/sys/random.h ============================================================================== --- head/sys/sys/random.h Sun Jan 12 20:25:11 2020 (r356666) +++ head/sys/sys/random.h Sun Jan 12 20:47:38 2020 (r356667) @@ -159,6 +159,7 @@ void random_harvest_deregister_source(enum random_entr #define GRND_NONBLOCK 0x1 #define GRND_RANDOM 0x2 +#define GRND_INSECURE 0x4 __BEGIN_DECLS ssize_t getrandom(void *buf, size_t buflen, unsigned int flags);