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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 70DE0C433F5 for ; Mon, 3 Oct 2022 22:36:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229758AbiJCWgM (ORCPT ); Mon, 3 Oct 2022 18:36:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60098 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229514AbiJCWgK (ORCPT ); Mon, 3 Oct 2022 18:36:10 -0400 Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9D4F12657B for ; Mon, 3 Oct 2022 15:36:09 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id q7so3841364pfl.9 for ; Mon, 03 Oct 2022 15:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date; bh=Bg3bkDSB5Rie05Qpuc6aVORV4OAik7UrPscyfhGNsaI=; b=I1tecMML8qAvywZ8EcCfrXEVSIAfj5Hl+TGGjtaywYdLot8hD0UiX/b4lpQcvGnC8h 8BmhYqW3ifkJi6xVat/mbherD6PZL+WhHVtmxulTdfm/VPxvRvIywKLMZ6G6uLaVa8IY UKBp4gtt2iqOrcDtzQmqUtUsKlWQIFKooEfX0p6gR167G7ScPQzYvmfi7yZqtWdF4BVS OlXX8iejB+jQnVyoZ+0/pFm0Ia2hVNujX6gyF4aCxQDL1KNYE69T5rrMf8SRuky33UB+ BIkJaD88RJWagt+klR00KC2xJOoQElZk3NO2ZTaXwcZwKmPlh/V3RB9KM357lq+gadcR ELeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date; bh=Bg3bkDSB5Rie05Qpuc6aVORV4OAik7UrPscyfhGNsaI=; b=kLDtDjUVYvKgvQLmkR7YjdJ/3f9HZsMgcnVSZC4LUerttAIyCTf/OTcEpU3++1KHI6 wzdmSV7TmFVH9371BU7thxakckvq3l7VcD/P0kuepXR7Lu8141rYdLtGvvxBdhRxxcrL YxrrHvwRozRLf3XL/NribU6OzWbZYDFetNltZQZzB+grmC7Lzjp2nw2DTXacv68QDbzm Sv8PeEbQXhQ1anptNopaebtPcjRwLVIFiQeXPkjAHunwI967AmkxAB85xJvhfFcguP7f qdrf1WXnFq+7BiKo3N8AnEza+4yCytc/tpQEET7v7l+twX+zqUAEEFVBaP+/dnRA6vB/ yiWA== X-Gm-Message-State: ACrzQf1gkVaAFSLIDAt8GOA//5UXvTXnAevZ8928K9iI4bzH9uW3t9uO ztyH55Cr76W6b8pAZ5XW4pg= X-Google-Smtp-Source: AMsMyM6zAiok65R6bvlwGEhT9m/OQe63yLDEtUTxK6a52WXzIWscx2EYSc5EBZCqYcL3sICm4Aj0ag== X-Received: by 2002:a63:ff1b:0:b0:43c:e4ee:e5e0 with SMTP id k27-20020a63ff1b000000b0043ce4eee5e0mr19775305pgi.540.1664836569138; Mon, 03 Oct 2022 15:36:09 -0700 (PDT) Received: from [192.168.1.115] ([185.126.107.38]) by smtp.gmail.com with ESMTPSA id d17-20020a170902b71100b0017f61576dbesm2104467pls.304.2022.10.03.15.36.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Oct 2022 15:36:08 -0700 (PDT) Sender: =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= Message-ID: Date: Tue, 4 Oct 2022 00:36:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 Subject: Re: [PATCH v2] mips/malta: pass RNG seed to to kernel via env var Content-Language: en-US To: "Jason A. Donenfeld" , qemu-devel@nongnu.org Cc: Jiaxun Yang , Aurelien Jarno , kvm-devel , Laurent Vivier , =?UTF-8?Q?Daniel_P=2e_Berrang=c3=a9?= References: <20221003103627.947985-1-Jason@zx2c4.com> From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= In-Reply-To: <20221003103627.947985-1-Jason@zx2c4.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Jason, Per https://www.qemu.org/docs/master/devel/submitting-a-patch.html#when-resending-patches-add-a-version-tag: Send each new revision as a new top-level thread, rather than burying it in-reply-to an earlier revision, as many reviewers are not looking inside deep threads for new patches. On 3/10/22 12:36, Jason A. Donenfeld wrote: > As of the kernel commit linked below, Linux ingests an RNG seed > passed from the hypervisor. So, pass this for the Malta platform, and > reinitialize it on reboot too, so that it's always fresh. > > Cc: Philippe Mathieu-Daudé > Cc: Jiaxun Yang > Cc: Aurelien Jarno > Link: https://git.kernel.org/mips/c/056a68cea01 You seem to justify this commit by the kernel commit, which justifies itself mentioning hypervisor use... So the egg comes first before the chicken. > Signed-off-by: Jason A. Donenfeld > --- > Changes v1->v2: > - Update commit message. > - No code changes. > > hw/mips/malta.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/hw/mips/malta.c b/hw/mips/malta.c > index 0e932988e0..9d793b3c17 100644 > --- a/hw/mips/malta.c > +++ b/hw/mips/malta.c > @@ -26,6 +26,7 @@ > #include "qemu/units.h" > #include "qemu/bitops.h" > #include "qemu/datadir.h" > +#include "qemu/guest-random.h" > #include "hw/clock.h" > #include "hw/southbridge/piix.h" > #include "hw/isa/superio.h" > @@ -1017,6 +1018,17 @@ static void G_GNUC_PRINTF(3, 4) prom_set(uint32_t *prom_buf, int index, > va_end(ap); > } > > +static void reinitialize_rng_seed(void *opaque) > +{ > + char *rng_seed_hex = opaque; > + uint8_t rng_seed[32]; > + > + qemu_guest_getrandom_nofail(rng_seed, sizeof(rng_seed)); > + for (size_t i = 0; i < sizeof(rng_seed); ++i) { > + sprintf(rng_seed_hex + i * 2, "%02x", rng_seed[i]); > + } > +} > + > /* Kernel */ > static uint64_t load_kernel(void) > { > @@ -1028,6 +1040,8 @@ static uint64_t load_kernel(void) > long prom_size; > int prom_index = 0; > uint64_t (*xlate_to_kseg0) (void *opaque, uint64_t addr); > + uint8_t rng_seed[32]; > + char rng_seed_hex[sizeof(rng_seed) * 2 + 1]; > > #if TARGET_BIG_ENDIAN > big_endian = 1; > @@ -1115,9 +1129,20 @@ static uint64_t load_kernel(void) > > prom_set(prom_buf, prom_index++, "modetty0"); > prom_set(prom_buf, prom_index++, "38400n8r"); > + > + qemu_guest_getrandom_nofail(rng_seed, sizeof(rng_seed)); > + for (size_t i = 0; i < sizeof(rng_seed); ++i) { > + sprintf(rng_seed_hex + i * 2, "%02x", rng_seed[i]); > + } > + prom_set(prom_buf, prom_index++, "rngseed"); > + prom_set(prom_buf, prom_index++, "%s", rng_seed_hex); You use the firmware interface to pass rng data to an hypervisor... Look to me you are forcing one API to ease another one. From the FW PoV it is a lie, because the FW will only change this value if an operator is involved. Here PROM stands for "programmable read-only memory", rarely modified. Having the 'rngseed' updated on each reset is surprising. Do you have an example of firmware doing that? (So I can understand whether this is the best way to mimic this behavior here). Aren't they better APIs to have hypervisors pass data to a kernel? Regards, Phil. > prom_set(prom_buf, prom_index++, NULL); > > rom_add_blob_fixed("prom", prom_buf, prom_size, ENVP_PADDR); > + qemu_register_reset(reinitialize_rng_seed, > + memmem(rom_ptr(ENVP_PADDR, prom_size), prom_size, > + rng_seed_hex, sizeof(rng_seed_hex))); > > g_free(prom_buf); > return kernel_entry; 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 1AA38C433FE for ; Mon, 3 Oct 2022 22:48:44 +0000 (UTC) Received: from localhost ([::1]:47174 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ofUEo-0001g2-88 for qemu-devel@archiver.kernel.org; Mon, 03 Oct 2022 18:48:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50192) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofU2m-0006MV-E3 for qemu-devel@nongnu.org; Mon, 03 Oct 2022 18:36:14 -0400 Received: from mail-pg1-x52c.google.com ([2607:f8b0:4864:20::52c]:46841) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ofU2k-0003oW-Ht for qemu-devel@nongnu.org; Mon, 03 Oct 2022 18:36:12 -0400 Received: by mail-pg1-x52c.google.com with SMTP id 78so10857313pgb.13 for ; Mon, 03 Oct 2022 15:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date; bh=Bg3bkDSB5Rie05Qpuc6aVORV4OAik7UrPscyfhGNsaI=; b=I1tecMML8qAvywZ8EcCfrXEVSIAfj5Hl+TGGjtaywYdLot8hD0UiX/b4lpQcvGnC8h 8BmhYqW3ifkJi6xVat/mbherD6PZL+WhHVtmxulTdfm/VPxvRvIywKLMZ6G6uLaVa8IY UKBp4gtt2iqOrcDtzQmqUtUsKlWQIFKooEfX0p6gR167G7ScPQzYvmfi7yZqtWdF4BVS OlXX8iejB+jQnVyoZ+0/pFm0Ia2hVNujX6gyF4aCxQDL1KNYE69T5rrMf8SRuky33UB+ BIkJaD88RJWagt+klR00KC2xJOoQElZk3NO2ZTaXwcZwKmPlh/V3RB9KM357lq+gadcR ELeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date; bh=Bg3bkDSB5Rie05Qpuc6aVORV4OAik7UrPscyfhGNsaI=; b=uQ121O3UeLbf/gIdcWzy+CD0yQHlh/PEF26dcyGIt6tbNQ91LP1lIBbDh2v4ZQJHwv b/XisrhsONFtTOqEFzdh43uqOJOLyLaYO7P3UPif0r79k6bTFf7vPcrBQoo8VRnpJv2R dMcmixt/pdwiOjOTozhfd+5TCYqxiILSbqYk6ZYC9tx2brER8hgoRahmbRp9XJO59I6F zS/QyA232/nXGSYNjWMDTCEhsT9H1HktJov49kWV8uvx9Y02IFVCVcGivoaIgdKMIpA7 BgdOfY3ZK11me+a2fWJfYIqsZHFNZHqRoaS2yLtGBuFFFMm7Uvfa8pYNq19MHajYJdSe LJbA== X-Gm-Message-State: ACrzQf0oe8n+oIQy7m2Wb7yeESfLSrdrHjFD1FT5iGrz4Otmj0MfU7Np wmH6bH3KlrNAZtgkk52lgQI= X-Google-Smtp-Source: AMsMyM6zAiok65R6bvlwGEhT9m/OQe63yLDEtUTxK6a52WXzIWscx2EYSc5EBZCqYcL3sICm4Aj0ag== X-Received: by 2002:a63:ff1b:0:b0:43c:e4ee:e5e0 with SMTP id k27-20020a63ff1b000000b0043ce4eee5e0mr19775305pgi.540.1664836569138; Mon, 03 Oct 2022 15:36:09 -0700 (PDT) Received: from [192.168.1.115] ([185.126.107.38]) by smtp.gmail.com with ESMTPSA id d17-20020a170902b71100b0017f61576dbesm2104467pls.304.2022.10.03.15.36.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Oct 2022 15:36:08 -0700 (PDT) Message-ID: Date: Tue, 4 Oct 2022 00:36:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 Subject: Re: [PATCH v2] mips/malta: pass RNG seed to to kernel via env var Content-Language: en-US To: "Jason A. Donenfeld" , qemu-devel@nongnu.org Cc: Jiaxun Yang , Aurelien Jarno , kvm-devel , Laurent Vivier , =?UTF-8?Q?Daniel_P=2e_Berrang=c3=a9?= References: <20221003103627.947985-1-Jason@zx2c4.com> In-Reply-To: <20221003103627.947985-1-Jason@zx2c4.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2607:f8b0:4864:20::52c; envelope-from=philippe.mathieu.daude@gmail.com; helo=mail-pg1-x52c.google.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-1.467, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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" Reply-to: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= via Hi Jason, Per https://www.qemu.org/docs/master/devel/submitting-a-patch.html#when-resending-patches-add-a-version-tag: Send each new revision as a new top-level thread, rather than burying it in-reply-to an earlier revision, as many reviewers are not looking inside deep threads for new patches. On 3/10/22 12:36, Jason A. Donenfeld wrote: > As of the kernel commit linked below, Linux ingests an RNG seed > passed from the hypervisor. So, pass this for the Malta platform, and > reinitialize it on reboot too, so that it's always fresh. > > Cc: Philippe Mathieu-Daudé > Cc: Jiaxun Yang > Cc: Aurelien Jarno > Link: https://git.kernel.org/mips/c/056a68cea01 You seem to justify this commit by the kernel commit, which justifies itself mentioning hypervisor use... So the egg comes first before the chicken. > Signed-off-by: Jason A. Donenfeld > --- > Changes v1->v2: > - Update commit message. > - No code changes. > > hw/mips/malta.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/hw/mips/malta.c b/hw/mips/malta.c > index 0e932988e0..9d793b3c17 100644 > --- a/hw/mips/malta.c > +++ b/hw/mips/malta.c > @@ -26,6 +26,7 @@ > #include "qemu/units.h" > #include "qemu/bitops.h" > #include "qemu/datadir.h" > +#include "qemu/guest-random.h" > #include "hw/clock.h" > #include "hw/southbridge/piix.h" > #include "hw/isa/superio.h" > @@ -1017,6 +1018,17 @@ static void G_GNUC_PRINTF(3, 4) prom_set(uint32_t *prom_buf, int index, > va_end(ap); > } > > +static void reinitialize_rng_seed(void *opaque) > +{ > + char *rng_seed_hex = opaque; > + uint8_t rng_seed[32]; > + > + qemu_guest_getrandom_nofail(rng_seed, sizeof(rng_seed)); > + for (size_t i = 0; i < sizeof(rng_seed); ++i) { > + sprintf(rng_seed_hex + i * 2, "%02x", rng_seed[i]); > + } > +} > + > /* Kernel */ > static uint64_t load_kernel(void) > { > @@ -1028,6 +1040,8 @@ static uint64_t load_kernel(void) > long prom_size; > int prom_index = 0; > uint64_t (*xlate_to_kseg0) (void *opaque, uint64_t addr); > + uint8_t rng_seed[32]; > + char rng_seed_hex[sizeof(rng_seed) * 2 + 1]; > > #if TARGET_BIG_ENDIAN > big_endian = 1; > @@ -1115,9 +1129,20 @@ static uint64_t load_kernel(void) > > prom_set(prom_buf, prom_index++, "modetty0"); > prom_set(prom_buf, prom_index++, "38400n8r"); > + > + qemu_guest_getrandom_nofail(rng_seed, sizeof(rng_seed)); > + for (size_t i = 0; i < sizeof(rng_seed); ++i) { > + sprintf(rng_seed_hex + i * 2, "%02x", rng_seed[i]); > + } > + prom_set(prom_buf, prom_index++, "rngseed"); > + prom_set(prom_buf, prom_index++, "%s", rng_seed_hex); You use the firmware interface to pass rng data to an hypervisor... Look to me you are forcing one API to ease another one. From the FW PoV it is a lie, because the FW will only change this value if an operator is involved. Here PROM stands for "programmable read-only memory", rarely modified. Having the 'rngseed' updated on each reset is surprising. Do you have an example of firmware doing that? (So I can understand whether this is the best way to mimic this behavior here). Aren't they better APIs to have hypervisors pass data to a kernel? Regards, Phil. > prom_set(prom_buf, prom_index++, NULL); > > rom_add_blob_fixed("prom", prom_buf, prom_size, ENVP_PADDR); > + qemu_register_reset(reinitialize_rng_seed, > + memmem(rom_ptr(ENVP_PADDR, prom_size), prom_size, > + rng_seed_hex, sizeof(rng_seed_hex))); > > g_free(prom_buf); > return kernel_entry;