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 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 35493C433EF for ; Fri, 22 Jul 2022 16:33:38 +0000 (UTC) Received: from localhost ([::1]:41276 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oEvaq-000800-PQ for qemu-devel@archiver.kernel.org; Fri, 22 Jul 2022 12:33:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60254) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEvZj-0007K8-5Z for qemu-devel@nongnu.org; Fri, 22 Jul 2022 12:32:27 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:52010) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEvZf-0006UP-BG for qemu-devel@nongnu.org; Fri, 22 Jul 2022 12:32:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1658507542; 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: in-reply-to:in-reply-to:references:references; bh=W/dgnGk6i2wzyD9pRZ31gA1uZdNHSF4g57z/vEXMpYQ=; b=TXIfaZfw4zgh4O2xTRP1oWy2idNuiQ3tq+BeUTxCOhMUTugvFXpswoci17qNz4+qcM+CHR eOvYEmFpV6FAvVWjensdSTGg7yUd2kAkqJ3HVL1KEdFhcRHh5AnZJdC7lu2vWXlwMGsTfF OLAnHUUBMuIJcSXS3D+3x7RQn41CEOM= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-575-HqoEs2cgNGWw8Mp17brYxQ-1; Fri, 22 Jul 2022 12:32:20 -0400 X-MC-Unique: HqoEs2cgNGWw8Mp17brYxQ-1 Received: by mail-lf1-f70.google.com with SMTP id z28-20020a0565120c1c00b0048a2049d2feso1979967lfu.22 for ; Fri, 22 Jul 2022 09:32:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W/dgnGk6i2wzyD9pRZ31gA1uZdNHSF4g57z/vEXMpYQ=; b=XNe2mNx1i3JX27s+Go56ejwgHa/RkP103UvtjILVVfBahlcQOTjo8Ey7a/ZLtSetT2 vFa7VzSpOflNnQnUegrHLUWjfcLhr4mqA0pcnj3mV1WEIdqPu8xyj2/5wa/nHqNPMyjV LD/+I0c6W6nNqWphAMtdPbWXDJs+8JM9G5ZQY8FOa+Re9o4OVL4h/S6MubyFPGmMSQfK FFvQ2coQ3zdyh8RfdqNmXJ/4asBtIlWrQE8UMyYucVUoGzY/1H6UbqQE3D1KHHbAFiaa sgIsIVMN/85J0xnOZIOIwE2lHg5DSYlT7dwKjiXaub9OAcEgpNl6D7sARsTYIpsKp7TE ok5w== X-Gm-Message-State: AJIora8l/f2tGVU4jnovsEGhCSrfqgDZxRkHicWKLICjI+40juEoHBay R1OwUPGnZlVY6vxgurg7uVgimjr0bUni+o9PR0p9YGyfDRh0g41IMWjwk/rMOoVbNeanpZRZA3D lcIGIrhd8D3o6jGxB2ejFXseA1f37OH4= X-Received: by 2002:a2e:a289:0:b0:258:e917:36a4 with SMTP id k9-20020a2ea289000000b00258e91736a4mr301680lja.510.1658507538838; Fri, 22 Jul 2022 09:32:18 -0700 (PDT) X-Google-Smtp-Source: AGRyM1u6X5qFV4mr4rZvLmsZspxjaU92OTTXL/RwQ53Gqu4DRdldrwMNXwBOJFTKN+zfF0EmOAOE6AvOXqtcHLHjgxE= X-Received: by 2002:a2e:a289:0:b0:258:e917:36a4 with SMTP id k9-20020a2ea289000000b00258e91736a4mr301674lja.510.1658507538567; Fri, 22 Jul 2022 09:32:18 -0700 (PDT) MIME-Version: 1.0 References: <20220721163621.761513-1-pbonzini@redhat.com> <20220721163621.761513-8-pbonzini@redhat.com> <87tu7az28k.fsf@linaro.org> <87o7xhscey.fsf@linaro.org> <87k085rz6b.fsf@linaro.org> In-Reply-To: <87k085rz6b.fsf@linaro.org> From: Paolo Bonzini Date: Fri, 22 Jul 2022 18:32:06 +0200 Message-ID: Subject: Re: [PULL 7/9] hw/guest-loader: pass random seed to fdt To: =?UTF-8?B?QWxleCBCZW5uw6ll?= Cc: "Jason A. Donenfeld" , qemu-devel Content-Type: multipart/alternative; boundary="000000000000b1aa0405e467606b" Received-SPF: pass client-ip=170.10.129.124; envelope-from=pbonzini@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -28 X-Spam_score: -2.9 X-Spam_bar: -- X-Spam_report: (-2.9 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.082, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --000000000000b1aa0405e467606b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ok I will resend the pull request. Apologies for overstepping. Paolo Il ven 22 lug 2022, 16:37 Alex Benn=C3=A9e ha scri= tto: > > "Jason A. Donenfeld" writes: > > > Hey Alex, > > > > On Fri, Jul 22, 2022 at 10:45:19AM +0100, Alex Benn=C3=A9e wrote: > >> All the guest-loader does is add the information about where in memory= a > >> guest and/or it's initrd have been placed in memory to the DTB. It's > >> entirely up to the initial booted code (usually a hypervisor in this > >> case) to decide what gets passed up the chain to any subsequent guests= . > > > > I think that's also my understanding, but let me tell you what I was > > thinking with regards to rng-seed there, and you can tell me if I'm way > > off. > > > > The guest-loader puts in memory various loaders in a multistage boot. > > Let's call it stage0, stage1, stage2, and finally the kernel. Normally, > > rng-seed is only given to one of these stages. That stage may or may no= t > > pass it to the next one, and it most probably does not. And why should > > it? The host is in a better position to generate these seeds, rather > > than adding finicky and fragile crypto ratcheting code into each stage > > bootloader. So, instead, QEMU can just give each stage its own seed, fo= r > > it to do whatever with. This way, if stage1 does nothing, at least > > there's a fresh unused one available for the kernel when it finally get= s > > there. > > That sounds suspiciously like inventing a new ABI between QEMU and > guests which we generally try to avoid. The DTB exposed to the first > stage may never be made visible to the following stages or more likely a > sanitised version is prepared by the previous stage. Generally QEMU just > tries to get the emulation right so the firmware/software can get on > with it's thing. Indeed the dynamic DTB for -M virt and friends is an > oddity compared to most of the other machine types which assume the user > has a valid DTB. > > Either way given how close to release we are I'd rather drop this patch. > > > Does what I describe correspond at all with the use of guest-loader? If > > so, maybe this patch should stay? If not, discard it as rubbish. > > The original intent of the guest-loader was to make testing of > hypervisors easier because the alternative is getting a multi-stage boot > chain of firmware, boot-loaders and distro specific integration working > which can be quite opaque to debug (c.f. why -kernel/-initrd exist and > not everyone boots via -bios/-pflash). > > > > > Jason > > > -- > Alex Benn=C3=A9e > > --000000000000b1aa0405e467606b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok I will resend the pull request. Apologies for overstep= ping.

Paolo

Il ven 22 lug= 2022, 16:37 Alex Benn=C3=A9e <alex.bennee@linaro.org> ha scritto:

"Jason A. Donenfeld" <Jason@zx2c4.com> writes:

> Hey Alex,
>
> On Fri, Jul 22, 2022 at 10:45:19AM +0100, Alex Benn=C3=A9e wrote:
>> All the guest-loader does is add the information about where in me= mory a
>> guest and/or it's initrd have been placed in memory to the DTB= . It's
>> entirely up to the initial booted code (usually a hypervisor in th= is
>> case) to decide what gets passed up the chain to any subsequent gu= ests.
>
> I think that's also my understanding, but let me tell you what I w= as
> thinking with regards to rng-seed there, and you can tell me if I'= m way
> off.
>
> The guest-loader puts in memory various loaders in a multistage boot.<= br> > Let's call it stage0, stage1, stage2, and finally the kernel. Norm= ally,
> rng-seed is only given to one of these stages. That stage may or may n= ot
> pass it to the next one, and it most probably does not. And why should=
> it? The host is in a better position to generate these seeds, rather > than adding finicky and fragile crypto ratcheting code into each stage=
> bootloader. So, instead, QEMU can just give each stage its own seed, f= or
> it to do whatever with. This way, if stage1 does nothing, at least
> there's a fresh unused one available for the kernel when it finall= y gets
> there.

That sounds suspiciously like inventing a new ABI between QEMU and
guests which we generally try to avoid. The DTB exposed to the first
stage may never be made visible to the following stages or more likely a sanitised version is prepared by the previous stage. Generally QEMU just tries to get the emulation right so the firmware/software can get on
with it's thing. Indeed the dynamic DTB for -M virt and friends is an oddity compared to most of the other machine types which assume the user has a valid DTB.

Either way given how close to release we are I'd rather drop this patch= .

> Does what I describe correspond at all with the use of guest-loader? I= f
> so, maybe this patch should stay? If not, discard it as rubbish.

The original intent of the guest-loader was to make testing of
hypervisors easier because the alternative is getting a multi-stage boot chain of firmware, boot-loaders and distro specific integration working
which can be quite opaque to debug (c.f. why -kernel/-initrd exist and
not everyone boots via -bios/-pflash).

>
> Jason


--
Alex Benn=C3=A9e

--000000000000b1aa0405e467606b--