From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 58DF621B06E71 for ; Fri, 14 Jul 2017 11:39:47 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id r36so18868302ioi.1 for ; Fri, 14 Jul 2017 11:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=juhUxgTFo9TwcPUY7eHv92epT45cdohqruDElyLElVs=; b=GkHrrdpvZ2FnLkSPAEARV6tfkkYm4zUem/ituzwKslJ1Dz8pmniCG4Af3L5q0z6qTb Pj2qUZvZdotzDYhn9Ji41C5IUGDfpQEcDaAKYkUZT8l5PNAQN7EaBBiXoghlr3yQGt6P JfP3vEgXpBQijxH3rFkNSyJr98dkXkAwzHNCw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=juhUxgTFo9TwcPUY7eHv92epT45cdohqruDElyLElVs=; b=tkAf6f+VyiNBeDhvKYMgWxEHhdbtwfebrGMA7VhC2UeTZhU5zK7Su9qJBRBXOcIJIc AwYaOJaxFBNXOB9NsJ0X1wCRvLWmZH3kcY2HcKjJmKWEHEq+2gv/6wmdfqeuMdqB6gcr seEAz20OZJRUrO6SUYjiAK2yI9JF0mrCdshrlSM/MbmabUX2/JcUfd2PBuE5Iz5hbPFI LqhSwDsHezgWgNMMIDxXeRzDDbQkK3kFYOp9oPw8uevGY3ooL8uouq5GF7YJRWwk3zBb sFLufbanJmeWRy7ffRT/9rKY54K9usU7YZWuRDTq5RXgbU2ej0B0o2qOmFtLShr6AJrQ 3dUg== X-Gm-Message-State: AIVw11174yyYTZYhUZhEZdHT2vgULJeoKHYds7fPhfONfv4Tfmntk0Jl 4DZzh5jktB1LLycSPFMuZQxtoKWO/Le5 X-Received: by 10.107.176.11 with SMTP id z11mr9798760ioe.173.1500057696002; Fri, 14 Jul 2017 11:41:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.134.134 with HTTP; Fri, 14 Jul 2017 11:41:35 -0700 (PDT) In-Reply-To: <51a36161-0ddc-0a53-24c1-b782883e46cc@redhat.com> References: <20170714171913.28524-1-ard.biesheuvel@linaro.org> <51a36161-0ddc-0a53-24c1-b782883e46cc@redhat.com> From: Ard Biesheuvel Date: Fri, 14 Jul 2017 19:41:35 +0100 Message-ID: To: Laszlo Ersek Cc: "edk2-devel@lists.01.org" , qlong , "Ye, Ting" , Leif Lindholm Subject: Re: [PATCH] CryptoPkg/OpensslLib AARCH64: clear XIP CC flags X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 18:39:47 -0000 Content-Type: text/plain; charset="UTF-8" On 14 July 2017 at 19:22, Laszlo Ersek wrote: > On 07/14/17 19:19, Ard Biesheuvel wrote: >> Commit 0df6c8c157af ("BaseTools/tools_def AARCH64: avoid SIMD registers >> in XIP code") updated the compiler flags used by AARCH64 when building >> modules (including BASE libraries) that may execute before the MMU is >> enabled. >> >> This broke the build for OpensslLib/OpensslLibCrypto because the SIMD >> register file is shared with the FPU, and since OpenSSL contains some >> references to float/double types (which are mostly unused for UEFI btw), >> disabling floating point prevents the compiler from building OpenSSL >> at all. > > I'm with you until here. > >> >> When introducing the support for XIP CC flags, we were aware that this >> would affect BASE libraries as well, but were not expecting this to >> have any performance impact. However, in the case of software crypto, >> it makes sense not to needlessly inhibit the compiler's ability to >> generate fast code, and even if OpenssLib is a BASE library, it is >> guaranteed not to run with the MMU off, so we can create a local >> exception, and clear its XIP CC flags for AARCH64. > > I'm confused by the last paragraph. The fist two paragraphs, and commit > 0df6c8c157af explain why SIMD register code gen was disabled (in brief, > to work around a GCC bug). > > Now it turns out that some code in OpenSSL cannot be compiled at all, > without us allowing insn generation for SIMD registers (because OpenSSL > uses float/double). Such code is unsafe to execute for at least two > reasons ((a) with the MMU off it could trigger the same issue that > 0df6c8c157af meant to protect against, and (b) because we don't use > floating point in UEFI). But, said code in OpenSSL is never executed, so > we can allow the potentially invalid code to be produced at least. > > But why talk about performance then? > > Do you mean that, in OpenSSL, > (a) is not an issue, because the MMU is always on by then, so commit > 0df6c8c157af doesn't apply, > (b) although we don't use floating point, the integer arithmetic still > benefits from SIMD? > > If so, I think (hope!) that I understand the argument, I'd just like a > bit more hand-holding in the structure of the argument. Can you reword > the third paragraph as "... another benefit of reenabling SIMD is > restoring performance for at least OpenSSL's integer arithmetic, without > risk of faults (because OpenSSL never runs with the MMU disabled)". > > Sorry if I'm being dense. :) No, not at all, I just was a bit terse in the description. Before the mentioned commit, XIP CC flags was set to -mstrict-align, which is required for modules that may execute with the MMU off. This has nothing to do with SIMD or FP. When we added -mgeneral-regs-only to that, we broke the OpensslLib build, which drew my attention to the fact that it, being a BASE library, is also built with -mstrict-align, and /this/ is the potential performance concern. So clearing XIP CC flags serves two distinct purposes: - removing -mgeneral-regs-only to unbreak the build - removing -mstrict-align to let the compiler generate faster code. -- Ard.