From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7B9F21CD3C for ; Fri, 26 Jan 2024 15:23:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706282639; cv=none; b=RORId+igA2s2i5dqAJ1vS3OrvQsKViWTIE+aykxdQUu3Mm2zUVo9VUmk8el7f5oMBSWIHQpoA92t/e4zXr5t7yC1lBhikkfHmRx9C6/G0RyegwdtlFwuJSh6IWVqHgFK9V6q3fB7fu4DA3tkC4+e/0sLk+gEZlNG8Wm4IGRop7M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706282639; c=relaxed/simple; bh=ydPZ3tu4FlaDxMtV6SOM9OK/z2p8/IzKH4YoVsZ330U=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=OqcPEx7sbhuQLuObHFynUOLypbnE8UkvhKdakMXQHyQPm5tRxonrI8qunEWrAGJXKmtkLxsYnoRSesru7RUKGYfGp7j129xsYGH/DW4dPhvl+wnJokJyuywE7wewhYLLJaSRxisiib7NhfVgIAV2Jpvqb2DPdCRtu5V3YWtayKA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Ua3DLU4I; arc=none smtp.client-ip=209.85.210.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Ua3DLU4I" Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-6ddded741bfso489454b3a.1 for ; Fri, 26 Jan 2024 07:23:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706282638; x=1706887438; darn=lists.linux.dev; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=uy3R1AKMbIaUlXE1Nr9/RuFwNoQzqIu4pzJFsA3j5jw=; b=Ua3DLU4IrCRWhXyS5Q3ERzJSLOrQPIck87L/xWzLkvad/79wJTLjABmZO7DSmY1FER p2J7bLX67pT5HA09ru3lmvUq4DE5QRBT5l3r3wmfpyQ4rRjUtyTqgo9P0lpKflVoRP+d 0zpVY97etyIx/SggQun1RlFlsIeVdtjWgN9yF2mmZhbyDE9xdhWfojgCKr5lQSijVWLr Mu1vIkSi7jUVh4yTl+eyap6ngmPCK7n4pqNimOxoCgaDFe1RaSve8mpOMzq2qpKWvaIR EWU3rVS5HNjJL+xp3aaC3uyadJcTSq8xxJ5IoABh3ZZSUwFq7JU2bW1Vwwnge83gS6PY MCAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706282638; x=1706887438; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=uy3R1AKMbIaUlXE1Nr9/RuFwNoQzqIu4pzJFsA3j5jw=; b=Lmq+2mZwtURm9Apl9gAXApeCzID+7afIrJ4mLunsPi4PM38pFnFW16fanx4AEqkO7k O3FWrrNwncGlPHAwK8gvI2y0w9sjtd9tZ1znzbhk33llSyJtSHAUpRfANXkDv0UoqVnu 3w6KQ+FEPz5FsB/oc0gd7mTnqIJrzy0rJETiZof1M9aiVZIIimLAZkqGOgrk/UJqcEFs EB0BaAu1E5/U2/sKSNkp3JkJ/Q9R3HpDD/zAgq92bzIdwUJWIz8a09zKHBq0ckG5FE5o Rdf1jHXZu2QH9+GlDcIP01wvV+a1B4s0wZwEv8skVT+tuNj+as8hQLmAoRaImnTWWWkr ByYQ== X-Gm-Message-State: AOJu0YwK5NhRJgrWMB9BnIbQ5yYLbOAJNYQjKWeFvKFHQofqhyP5Dqj8 kWh9sZovFEhakxb+sZFJ0Eyxxn7v5fSX5syP1/Jg+I8bz6CeVpMLmHYcrk30S5Iy9FME1qSFpmy iWw== X-Google-Smtp-Source: AGHT+IHQfxRoZeNwOqFJdXs7U9dhuzak/9AcePRZQYH58f/39D52wykb9ESAoZ9pjQpLXy9fdKdTaNW+gCM= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6a00:1d1d:b0:6de:622:2ebf with SMTP id a29-20020a056a001d1d00b006de06222ebfmr81316pfx.3.1706282637856; Fri, 26 Jan 2024 07:23:57 -0800 (PST) Date: Fri, 26 Jan 2024 07:23:55 -0800 In-Reply-To: <20240126134230.1166943-1-kirill.shutemov@linux.intel.com> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20240126134230.1166943-1-kirill.shutemov@linux.intel.com> Message-ID: Subject: Re: [RFC] Randomness on confidential computing platforms From: Sean Christopherson To: "Kirill A. Shutemov" Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , x86@kernel.org, "Theodore Ts'o" , "Jason A. Donenfeld" , Kuppuswamy Sathyanarayanan , Elena Reshetova , Jun Nakajima , Tom Lendacky , Ashish Kalra , linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 26, 2024, Kirill A. Shutemov wrote: > Problem Statement >=20 > Currently Linux RNG uses the random inputs obtained from x86 > RDRAND/RDSEED instructions (if present) during early initialization > stage (by mixing the obtained input into the random pool via > _mix_pool_bytes()), as well as for seeding/reseeding ChaCha-based CRNG. > When the calls to both RDRAND/RDSEED fail (including RDRAND internal > retries), the timing-based fallbacks are used in the latter case, and > during the early boot case this source of entropy input is simply > skipped. Overall Linux RNG has many other sources of entropy that it > uses (also depending on what HW is used), but the dominating one is > interrupts. >=20 > In a Confidential Computing Guest threat model, given the absence of any > special trusted HW for the secure entropy input, RDRAND/RDSEED > instructions is the only entropy source that is unobservable outside of > Confidential Computing Guest TCB. However, with enough pressure on these > instructions from multiple cores (see Intel SDM, Volume 1, Section > 7.3.17, =E2=80=9CRandom Number Generator Instructions=E2=80=9D), they can= be made to > fail on purpose and force the Confidential Computing Guest Linux RNG to > use only Host/VMM controlled entropy sources. >=20 > Solution options >=20 > There are several possible solutions to this problem and the intention > of this RFC is to initiate a joined discussion. Here are some options > that has been considered: >=20 > 1. Do nothing and accept the risk. > 2. Force endless looping on RDRAND/RDSEED instructions when run in a > Confidential Computing Guest (this patch). This option turns the > attack against the quality of cryptographic randomness provided by > Confidential Computing Guest=E2=80=99s Linux RNG into a DoS attack aga= inst > the Confidential Computing Guest itself (DoS attack is out of scope > for the Confidential Computing threat model). > 3. Panic after enough re-tries of RDRAND/RDSEED instructions fail. > Another DoS variant against the Guest. > 4. Exit to the host/VMM with an error indication after a Confidential > Computing Guest failed to obtain random input from RDRAND/RDSEED > instructions after reasonable number of retries. This option allows > host/VMM to take some correction action for cases when the load on > RDRAND/RDSEED instructions has been put by another actor, i.e. the > other guest VM. The exit to host/VMM in such cases can be made > transparent for the Confidential Computing Guest in the TDX case with > the assistance of the TDX module component. Hell no. Develop better hardware if you want to guarantee forward progress= . Don't push more complexity into the host stack for something that in all li= kelihood will never happen outside of buggy software or hardware. > 5. Anything other better option? Give the admin the option to choose between "I don't care, carry-on with le= ss randomness" and "I'm paranoid, panic, panic, panic!". In other words, let = the admin choose between #1 and #3 at boot time. You could probably even let t= he admin control the number of retries, though that's probably a bit excessive= . And don't tie it to CoCo VMs, e.g. if someone is relying on randomness for = a bare metal workload, they might prefer to panic if hardware is acting funky.