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.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 F2F0AC3A5A2 for ; Fri, 20 Sep 2019 19:51:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BCFAB2173E for ; Fri, 20 Sep 2019 19:51:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1569009096; bh=aMvAeQtBhOA1b26ULafsZpV6g11dLlCr/Ml2//wce+M=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=cWDYadra8r7x0kw1ze+w6iDAkkqD8zAfisGqHhAYzKLi4icPOgdGH89MFScqqKTjr CFZUzVCuTJ8uSITqK+w0nLb5F4A4tIPFI4M25/y9ioIGAkoaXZloBdbE2W9fkotQl6 GuJKZslWmYoZlBCXDOchMJ5eVLIs7IHGSovTvO0E= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729766AbfITTvg (ORCPT ); Fri, 20 Sep 2019 15:51:36 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:35836 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727400AbfITTvf (ORCPT ); Fri, 20 Sep 2019 15:51:35 -0400 Received: by mail-lj1-f195.google.com with SMTP id m7so8223973lji.2 for ; Fri, 20 Sep 2019 12:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T/KRNd6WnVd1TN8iGmZGtSrb5q1ExNfe/4Yl0euZMS0=; b=iAXp/EtQxpgvqEzrvvxqiOyQr7c9BVQXW9AqVrmJ1uutftSkoOvoPGmu0/aiukB8Eh a4oRgtofk+kMsCJx0F/+Q7WlMYD9WpnDU1zVcsFNFP16vWm2XLFfmQumCUclks6ozIfb 3NBzrIVS9HrmA+u9BOyxaHHk9xq0ckXcDd5Vk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T/KRNd6WnVd1TN8iGmZGtSrb5q1ExNfe/4Yl0euZMS0=; b=O3inYnNpQdaL0S2dHB8rXVauBxvCG9V//owIFti/PFDrEZzw5oMxqTJ94i9Du3/+Id rXooEXaayxcKH2hzb8hAnmMXDN60+DWbdkhxShJk31KrZYP5lfJqMS51ZtoLtpaWMJeq ivdq2oXNraAec3KSy356beNzY8PdCl7MlE0u7ywLCq5KsviDOvWHxBlbt1kBe14IgxWu 0dVpeHS26+uxVQrLOJ4u+WpDWgMBdftKXu66m6HhbBiZzIqN5PUYbtyqWdlGeOC9s9SI H50jOUu53Zf4B955Igeon26kmOFaUO4laVn+wZBXp65djbKVEuirIAvYOG9UcOWLubOG Kv2Q== X-Gm-Message-State: APjAAAXxuQeaADa8aC5OAiIJ4TBWpx4xKsOXZ2UG3+HMewu0OleOLT3u COEeviwR7YJfH27prnKHjCJ/A/uptSI= X-Google-Smtp-Source: APXvYqzaqyRO2TTFgJEPF3JM+ok2znklkGj/CfA9nmCNnW1x0cUFBlry86Lx3Qw/to5CiOubsMm/dw== X-Received: by 2002:a2e:934f:: with SMTP id m15mr10262038ljh.101.1569009092358; Fri, 20 Sep 2019 12:51:32 -0700 (PDT) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com. [209.85.208.175]) by smtp.gmail.com with ESMTPSA id e7sm669120lfn.12.2019.09.20.12.51.30 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Sep 2019 12:51:30 -0700 (PDT) Received: by mail-lj1-f175.google.com with SMTP id l21so8227258lje.4 for ; Fri, 20 Sep 2019 12:51:30 -0700 (PDT) X-Received: by 2002:a2e:9854:: with SMTP id e20mr10431173ljj.72.1569009089004; Fri, 20 Sep 2019 12:51:29 -0700 (PDT) MIME-Version: 1.0 References: <20190912034421.GA2085@darwi-home-pc> <20190912082530.GA27365@mit.edu> <20190914122500.GA1425@darwi-home-pc> <008f17bc-102b-e762-a17c-e2766d48f515@gmail.com> <20190915052242.GG19710@mit.edu> <20190918211503.GA1808@darwi-home-pc> <20190918211713.GA2225@darwi-home-pc> <20190920134609.GA2113@pc> In-Reply-To: From: Linus Torvalds Date: Fri, 20 Sep 2019 12:51:12 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC v4 1/1] random: WARN on large getrandom() waits and introduce getrandom2() To: Andy Lutomirski Cc: "Ahmed S. Darwish" , Lennart Poettering , "Theodore Y. Ts'o" , "Eric W. Biederman" , "Alexander E. Patrakov" , Michael Kerrisk , Willy Tarreau , Matthew Garrett , lkml , Ext4 Developers List , Linux API , linux-man Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 20, 2019 at 12:12 PM Andy Lutomirski wrote: > > The problem is that new programs will have to try the new flag value > and, if it returns -EINVAL, fall back to 0. This isn't so great. Don't be silly. Of course they will do that, but so what? With a new kernel, they'll get the behavior they expect. And with an old kernel, they'll get the behavior they expect. They'd never fall back to to "0 means something I didn't want", exactly because we'd make this new flag be the first change. > Wait, are you suggesting that 0 means invoke jitter-entropy or > whatever and GRND_SECURE_BLOCKING means not wait forever and deadlock? > That's no good -- people will want to continue using 0 because the > behavior is better. I assume that "not wait forever" was meant to be "wait forever". So the one thing we have to do is break the "0 waits forever". I guarantee that will happen. I will override Ted if he just NAk's it, because we simply _cannot_ continue with it. So we absolutely _will_ come up with some way 0 ends the wait. Whether it's _just_ a timeout, or whether it's jitter-entropy or whatever, it will happen. But we'll also make getrandom(0) do the annoying warning, because it's just ambiguous. And I suspect you'll find that a lot of security people don't really like jitter-entropy, at least not in whatever cut-down format we'll likely have to use in the kernel. And we'll also have to make getrandom(0) be really _timely_. Security people would likely rather wait for minutes before they are happy with it. But because it's a boot constraint as things are now, it will not just be jitter-entropy, it will be _accelerated_ jitter-entropy in 15 seconds or whatever, and since it can't use up all of CPU time, it's realistically more like "15 second timeout, but less of actual CPU time for jitter". We can try to be clever with a background thread and a lot of yielding(), so that if the CPU is actually idle we'll get most of that 15 seconds for whatever jitter, but end result is that it's still accelerated. Do I believe we can do a good job in that kind of timeframe? Absolutely. The whole point should be that it's still "good enough", and as has been pointed out, that same jitter entropy that people are worried about is just done in user space right now instead. But do I believe that security people would prefer a non-accelerated GRND_SECURE_BLOCKING? Yes I do. That doesn't mean that GRND_SECURE_BLOCKING shouldn't use jitter entropy too, but it doesn't need the same kind of "let's hurry this up because it might be during early boot and block things". That said, if we can all convince everybody (hah!) that jitter entropy in the kernel would be sufficient, then we can make the whole point entirely moot, and just say "we'll just change crng_wait() to do jitter entropy instead and be done with it. Then any getrandom() user will just basically wait for a (very limited) time and the system will be happy. If that is the case we wouldn't need new flags at all. But I don't think you can make everybody agree to that, which is why I suspect we'll need the new flag, and I'll just take the heat for saying "0 is now off limits, because it does this thing that a lot of people dislike". > IMO this is confusing. The GRND_RANDOM flag was IMO a mistake and > should just be retired. Let's enumerate useful cases and then give > them sane values. That's basically what I'm doing. I enumerate the new values. But the enumerations have hidden meaning, because the actual bits do matter. The GRND_EXPLICIT bit isn't supposed to be used by any user, but it has the value it has because it makes old kernels return -EINVAL. But if people hate the bit names, we can just do an enum and be done with it: enum grnd_flags { GRND_NONBLOCK = 1, GRND_RANDOM, // Don't use! GRND_RANDOM_NONBLOCK, // Don't use GRND_UNUSED, GRND_INSECURE, GRND_SECURE_BLOCKING, GRND_SECURE_NONBLOCKING, }; but the values now have a _hidden_ pattern (because we currently have that "| GRND_NONBLOCK" pattern that I want to make sure still continues to work, rather than give unexpected behavior in case somebody continues to use it). So the _only_ difference between the above and what I suggested is that I made the bit pattern explicit rather than hidden in the value. > And the only real question is how to map existing users to these > semantics. I see two sensible choices: > > 1. 0 means "secure, blocking". I think this is not what we'd do if we > could go back in time and chage the ABI from day 1, but I think it's > actually good enough. As long as this mode won't deadlock, it's not > *that* bad if programs are using it when they wanted "insecure". It's exactly that "as long as it won't deadlock" that is our current problem. It *does* deadlock. So it can't mean "blocking" in any long-term meaning. It can mean "blocks for up to 15 seconds" or something like that. I'd honestly prefer a smaller number, but I think 15 seconds is an acceptable "your user space is buggy, but we won't make you think the machine hung". > 2. 0 means "secure, blocking, but warn". Some new value means > "secure, blocking, don't warn". The problem is that new applications > will have to fall back to 0 to continue supporting old kernels. The same comment about blocking. Maybe you came in in the middle, and didn't see the whole "reduced IO patterns means that boot blocks forever" part of the original problem. THAT is why 0 will absolutely change behaviour. Linus