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 84EE2C7EE23 for ; Thu, 8 Jun 2023 06:22:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234664AbjFHGWY (ORCPT ); Thu, 8 Jun 2023 02:22:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53986 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234521AbjFHGWV (ORCPT ); Thu, 8 Jun 2023 02:22:21 -0400 Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9DF6E1706 for ; Wed, 7 Jun 2023 23:22:18 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2b1a86cdec6so1536231fa.3 for ; Wed, 07 Jun 2023 23:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1686205336; x=1688797336; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=G0VwUCmEnGX86ZCMjrjzf2n2n4i6He7mE7SapcE39jQ=; b=zNzdPClVFDBPvA/Sd0tnWU4q+9TDxtptLUXsJI1uzuIKW7CepO/B7U20Akb2sVNjUf iChrVgfRdbCukBM3ZRmwq4tdN7GbqTVNPm4Xox66Jduri+joXchA/FrGDmJBY9C72PoA 9JoGjTa2qwQ8C/TagifFEu2pfvGsBppwIR4LCSL+HFIa45MERVcco2p7fbwRnAa7TA2u lx0OfDfvg2T2IMAMc0UEWdjcz1rk4DUFcQykgrPDKjlQyM0DlDvxRlbdJM7eblnLZyLs AKluKMuIfFTK1Co091kHLyCIp3XxSv6ZKpTdiRftP7uL9CGY9b+Y4s7r1XHzLTn+P78i OfUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686205336; x=1688797336; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=G0VwUCmEnGX86ZCMjrjzf2n2n4i6He7mE7SapcE39jQ=; b=KvOYSmkehALtY9vQ9NK6INui8LABxWlZivBmiXtgPkK7ekCp7iMlYSkSYPhNo8nPaX Rhfl6E2j71jrBETlyuQTrjs2+a5PKicJlEohv43usWTvG9lFe/hP6DgH2b+UIimUCAuV 5IK9TSFVyYL5gywd6DZxu+o1EBA8/R+tzFzTpPdNYAb75d560bYngFb5QQ98dPrLpByK e0AnEOLXmPKxLcB1Jly508o99N3Npkh+L1Csh3RJnaZlaIb0YxGFfPAcgBZiuIaFsItl M4ks+Rjx18n6M9Ne8sTa9Spxnpz4XFZ94ggrB2ef5FCvzKXUifU6NInJxpIYP29FUhew tuZw== X-Gm-Message-State: AC+VfDyOuJUTBUj/sXihYx4CRiFxZ/grPDC1NEEQnT0+LEsSc5ygqsF7 FtyR/Nvj7D3agaINL8TGTFFtZXuQwGXqHXObh+Ttuw== X-Google-Smtp-Source: ACHHUZ7NSvEUlT8UhkX/QkQM8okQgMSoDdPNJPAgRN0eGgLLO3YmB8/MiPHPVGgliaXCkm+PDURvo1SR5U1XDuifDtY= X-Received: by 2002:a2e:9d5a:0:b0:2af:32a7:4eef with SMTP id y26-20020a2e9d5a000000b002af32a74eefmr2576295ljj.35.1686205336661; Wed, 07 Jun 2023 23:22:16 -0700 (PDT) MIME-Version: 1.0 References: <20230526010748.1222-1-masahisa.kojima@linaro.org> <20230526010748.1222-4-masahisa.kojima@linaro.org> <0d3e0370-eb76-010f-3d30-9acc9b59645c@siemens.com> <4ff09002-e871-38b9-43ec-227a64bac731@siemens.com> <76da826f-b608-6add-5401-6de818b180e3@siemens.com> <871ece13-7d6e-44d4-3bda-317658202f6f@siemens.com> In-Reply-To: <871ece13-7d6e-44d4-3bda-317658202f6f@siemens.com> From: Ilias Apalodimas Date: Thu, 8 Jun 2023 09:21:40 +0300 Message-ID: Subject: Re: [PATCH v5 3/3] efi: Add tee-based EFI variable driver To: Jan Kiszka Cc: Sumit Garg , Ard Biesheuvel , Masahisa Kojima , Jens Wiklander , linux-kernel@vger.kernel.org, op-tee@lists.trustedfirmware.org, Johan Hovold , Maxime Coquelin , Alexandre Torgue , linux-efi@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, "Su, Bao Cheng (RC-CN DF FA R&D)" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jan On Wed, 7 Jun 2023 at 22:46, Jan Kiszka wrote: > > On 07.06.23 20:17, Ilias Apalodimas wrote: > > On Wed, 7 Jun 2023 at 20:14, Jan Kiszka wrote: > >> > >> On 07.06.23 18:59, Ilias Apalodimas wrote: > >>> On Wed, 7 Jun 2023 at 19:09, Ilias Apalodimas > >>> wrote: > >>>> > >>>> Hi Jan, > >>>> > >>>> [...] > >>>>>>>> No I don't, this will work reliably without the need to remount the efivarfs. > >>>>>>>> As you point out you will still have this dependency if you end up > >>>>>>>> building them as modules and you manage to mount the efivarfs before > >>>>>>>> those get inserted. Does anyone see a reasonable workaround? > >>>>>>>> Deceiving the kernel and making the bootloader set the RT property bit > >>>>>>>> to force the filesystem being mounted as rw is a nasty hack that we > >>>>>>>> should avoid. Maybe adding a kernel command line parameter that says > >>>>>>>> "Ignore the RTPROP I know what I am doing"? I don't particularly love > >>>>>>>> this either, but it's not unreasonable. > >>>>>>> > >>>>>>> In the context of https://github.com/OP-TEE/optee_os/issues/6094, > >>>>>>> basically this issue mapped on reboot/shutdown, I would really love to > >>>>>>> see the unhandy tee-supplicant daemon to be overcome. > >>>>>> > >>>>>> I have seen this error before and it has been on my todo list. So I > >>>>>> have tried to fix it here [1]. Feel free to test it and let me know if > >>>>>> you see any further issues. > >>>>>> > >>>>>> [1] https://lkml.org/lkml/2023/6/7/927 > >>>>>> > >>>>> > >>>>> Ah, nice, will test ASAP! > >>>>> > >>>>> Meanwhile more food: I managed to build a firmware that was missing > >>>>> STMM. But the driver loaded, and I got this: > >>>> > >>>> Thanks for the testing. I'll try to reproduce it locally and get back to you > >>> > >>> Can you provide a bit more info on how that was triggered btw? I would > >>> be helpful to know > >>> > >>> - OP-TEE version > >> > >> Today's master, 145953d55. > >> > >>> - was it compiled as a module or built-in? > >> > >> Sorry, not sure anymore, switching back and forth right now. I think it > >> was built-in. > >> > >>> - was the supplicant running? > >> > >> Yes. > >> > > > > Ok thanks, that helps. I guess this also means U-Boot was compiled to > > store the variables in a file in the ESP instead of the RPMB right? > > Otherwise, I can't see how the device booted in the first place. > > U-Boot was not configured to perform secure booting in this case. It had > RPMB support enabled, just didn't have to use it. In your initial mail you said you managed to build a firmware without StMM. If U-boot isn't reconfigured accordingly -- iow skip the EFI variable storage in an RPMB, the EFI subsystem will fail to start. In any case, I don't think the ooops you are seeing is not connected to this patchset. Looking at the kernel EFI stub we only set the SetVariableRT if the RTPROP table is set accordingly by the firmware. U-Boot never sets the EFI_RT_SUPPORTED_SET_VARIABLE property since it can't support it. What you are doing is remount the efivarfs as rw and then trying to set a variable, but the callback for it is NULL. I think you'll be able to replicate the same behavior on the kernel without even inserting the new module. Thanks /Ilias > > Jan > > -- > Siemens AG, Technology > Competence Center Embedded Linux >