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 33B0AC04A68 for ; Thu, 28 Jul 2022 16:56:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231929AbiG1Q4k (ORCPT ); Thu, 28 Jul 2022 12:56:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41394 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231881AbiG1Q4j (ORCPT ); Thu, 28 Jul 2022 12:56:39 -0400 Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com [IPv6:2607:f8b0:4864:20::1129]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7208A5FAC2 for ; Thu, 28 Jul 2022 09:56:37 -0700 (PDT) Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-32269d60830so26016537b3.2 for ; Thu, 28 Jul 2022 09:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oc0lYZZen+n96H3YkJlz8amsnvCsXfd6yw7H3HRAv34=; b=LvEPmb5gwSpnB2b/XfP2TsjWKUpKxjPvyNp/0TXuTe4dFBociwyBIFRmRBMgLufeqQ JbU7CU+ASwWDDo1aahIXU8O8h5SOOSRK/N7ugORv963f/VE1GEuPnMhMlQm0dNeH/unJ nZhQsjgzp0g4VX+AN+FU04VjYDYJp7WRZiDRl6Yk8NynNfO4fn8O01ME0GF3gijiDDkt k/OamyyajXQvcH/bO9zXFot9OOwaauBMAUwcR/pb/W4OfhawaBwLPrHvpv3AsRGuYRqF k9kdy25z5AKsLkQFzaEWhfsA7PJhpB9XiDCdiUa/axhtsSe6qASTK67wSRx9/5cXQE8v g74g== 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=oc0lYZZen+n96H3YkJlz8amsnvCsXfd6yw7H3HRAv34=; b=Mq96MvXWoAZfPaa0q3moAlccyoeewyLq2DA7beGkF2RjDoTaN2BOro2fUsR+OGG6MU L0rSCSS4xHYGmOCcUr3nZKHv685m2uhcKWhS2SaRlB0dEPxd5pDLR28mPBxKn4vm5Ur7 ec7iZ67Jtypu1y/tlyg1rNUpCruKi9um0//aswfNoGXUSkN8xGBMpkotRfgE3z/lnu+P j18xW0qcoA/l8yefdwBLtR6gFFTx8RRzZszeLkQ9nBow9G6cN/c0Vr6Wc3FZ91YWUDXa 2t9TGvFRck/tPhNfSQSvFtDkpheL5Y233JsV+dprBGWT3nqVGgEKUXAL6YZYm+Qfp5Pd r9lg== X-Gm-Message-State: ACgBeo0+dVS/spnDphd9WmFM1P9UzREGfMNVdO84GIrqWGZC6EBsskdg gG2TECdwsEmRbpzliCRm0f9+3qrigV0dlYxrwKjt0Q== X-Google-Smtp-Source: AA6agR42EGEUyzYTo3gBZ8QlvPbpFDUMcDOY9xlNbtBF0J/wWPwVHlB4+Nl+tb/UgglFFTHYed3NhawdldcN4gc+Y2E= X-Received: by 2002:a81:6a07:0:b0:323:8614:10c2 with SMTP id f7-20020a816a07000000b00323861410c2mr1192910ywc.191.1659027396641; Thu, 28 Jul 2022 09:56:36 -0700 (PDT) MIME-Version: 1.0 References: <20220723224949.1089973-1-luzmaximilian@gmail.com> <20220723224949.1089973-5-luzmaximilian@gmail.com> <20220726143005.wt4be7yo7sbd3xut@bogus> <829c8fee-cae5-597d-933d-784b4b57bd73@gmail.com> <20220726154138.74avqs6iqlzqpzjk@bogus> <7284953b-52bb-37ac-fbe1-1fa845c44ff9@linaro.org> <3d752603-365d-3a33-e13e-ca241cee9a11@gmail.com> <20220727132437.pjob3z2nyxsuxgam@bogus> In-Reply-To: From: Ilias Apalodimas Date: Thu, 28 Jul 2022 19:56:00 +0300 Message-ID: Subject: Re: [PATCH 4/4] dt-bindings: firmware: Add Qualcomm UEFI Secure Application client To: Maximilian Luz Cc: Sudeep Holla , Krzysztof Kozlowski , Andy Gross , Bjorn Andersson , Ard Biesheuvel , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , Steev Klimaszewski , Shawn Guo , Cristian Marussi , Greg Kroah-Hartman , linux-arm-msm@vger.kernel.org, linux-efi@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Thu, 28 Jul 2022 at 15:49, Maximilian Luz wrote: > [...] > >> > >>> I have an ancient branch somewhere that I can polish up and send an > >>> RFC [1], but the way I enabled that was to install an empty config > >>> table from the firmware. That empty table is basically an indication > >>> to the kernel saying "Hey I can't store variables, can you do that for > >>> me". > >>> > >>> Is there any chance we can do something similar on that device (or > >>> find a reasonable way of inferring that we need to replace some > >>> services). That way we could at least have a common entry point to > >>> the kernel and leave out the DT changes. > >>> > >>> [1] https://git.linaro.org/people/ilias.apalodimas/net-next.git/log/?h=setvar_rt_optee_3 > >> > >> I would very much like to avoid the need for special bootloaders. The > >> devices we're talking about are WoA devices, meaning they _should_ > >> ideally boot just fine with EFI and ACPI. > > > > I've already responded to following email, but I'll repeat it here for > > completeness. It's not a special bootloader. It's the opposite, it's > > a generic UEFI compliant bootloader which takes advantage of the fact > > EFI is extensible. We are doing something very similar in how we load > > our initrd via the EFI_LOAD_FILE2 protocol. Whether Qualcomm can add > > that to their bootloaders is a different topic though. But at some > > point we need to draw a line than keep overloading the DT because a > > vendor decided to go down it's own path. > > But still, you're asking users to install an extra thing in the boot > chain. Not users. EFI firmware implementations that want to support this in a generic way. > That's what I mean by "special". So the situation would then be > this: User needs a) GRUB (or something similar) for booting the kernel > (or dual-booting, ...), b) DTBLoader for loading the device-tree because > we don't support the ACPI Qualcomm provided, and c) your thing for EFI > variables and potentially other firmware fix-ups. b) and c) are both > things that "normal" users don't expect. IMHO we should try to get rid > of those "non-standard" things, not add more. But that's exactly why EFI is extensible . You can have non standard functionality on your firmware for cases like this which doesn't need to land in the spec. > > >> From an end-user perspective, it's annoying enough that we'll have to > >> stick with DTs for the time being due to the use of PEPs in ACPI. I > >> really don't want to add some special bootloader for fixups to that. > >> Also, this would just move the problem from kernel to bootloader. > > > > But it *is* a bootloader problem. The bootloader is aware of the fact > > that it can't provide runtime services for X reasons and that's > > exactly why we are trying to set EFI_RT_PROPERTIES_TABLE correctly > > from the firmware. All we are doing is install a config table to tell > > the OS "I can't do that, can you find a way around it?". > > Sure, but is making the Linux installation process more device > dependent and complicated really the best way to solve this? Isn't it device dependent already? That boat has sailed already since we need to change the very definition of runtime services and replace them with OS specific ones. If we add it on the DT, you'll end up with different DTs per OS and potentially per use case. In my head the DTs should be part of the firmware (and authenticated by the firmware as well) instead of loading whatever we want each time. By using a config table we can add a u64 (random thought), that tells the kernel which TEE implementation will handle variable storage. So we can have a common extension to boot loaders, which at least uses EFI interfaces to communicate the functionality. I really prefer this to adding it on a DT, but I am not that picky. Your email raises an important topic of replacing runtime services with OS specific ones, which is unfortunately very much needed and we should fix that. Thanks /Ilias > > Regards, > Max