From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::244; helo=mail-it0-x244.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 87539211299A3 for ; Wed, 12 Sep 2018 08:04:51 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id h1-v6so3442442itj.4 for ; Wed, 12 Sep 2018 08:04:51 -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=dQwOC+1RfunpYnluRXyOde8yX0gQ2mL13Xurej/g9c0=; b=XIjWRZhvAoPEgJqxqfiJjA9Vx3ttINWGeqQ4jvxIq8xtsA5xkSgouokEEW+OfBwrLV PkQ6lP3iQ5na52n6GlJ2rM9qOkv90D1G5akCPk0aURViMA5SHTn2lzKTZnIStInbBt96 29OGOrgVzTh7AEL96nYv1BvaiFeVIbqLyqnqE= 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=dQwOC+1RfunpYnluRXyOde8yX0gQ2mL13Xurej/g9c0=; b=HACAqLJMdOBUyrH+qz9WU0R/aV/7eysKPfQMV1AvXlERkGpYghT15pNM6Ru6cFNOzL t4KzpP4Dlhrd9dcATxlzq2Zjf+lS6pxFXfj6MBwIt01p7ygke2/iwgwsC39xOvK3aDsA 1wfrOly3R/+efHsV//FjE2K0vEnN8oLWlGgTEdMQmQ1MaSz1vGsYvFSvCH2YC9EcsgfE 76iSXdNTxVbXrimi858vX9CYmlSHK7XNAd+rADuAadLGaL2PSkxGhE3aqiCPXkDOJJNt gfwaZB+DUTek2cJviNcrIxaVgwTW1GioB4+hvepkCMzjCNFx5rqdgb1qWa+4oXE1qvKY TFjQ== X-Gm-Message-State: APzg51CUV4ls7NxFiwKFu9lOZCTok1ML+nVFJfXlq8vWH8Y0Y4GkvTUt J3ortRft3RmXEw2BF624hMO0FdD+E7eyVXgiJOPJpQ== X-Google-Smtp-Source: ANB0Vda88F2+Y09MYXacxlVBIje841XJ+0dPcyTgpDko087Krjr0+WCeDLY27UIkw87TnbD9vzOuAMo0xRILBXvcAB8= X-Received: by 2002:a02:1515:: with SMTP id j21-v6mr2207042jad.2.1536764690381; Wed, 12 Sep 2018 08:04:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:2848:0:0:0:0:0 with HTTP; Wed, 12 Sep 2018 08:04:49 -0700 (PDT) In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5BE03AED@SHSMSX104.ccr.corp.intel.com> References: <20180911051636.4888-1-jian.j.wang@intel.com> <599615e1-130a-79cb-467f-4afce7c13bda@Intel.com> <734D49CCEBEEF84792F5B80ED585239D5BE03AED@SHSMSX104.ccr.corp.intel.com> From: Ard Biesheuvel Date: Wed, 12 Sep 2018 17:04:49 +0200 Message-ID: To: "Ni, Ruiyu" Cc: "edk2-devel@lists.01.org" Subject: Re: [PATCH 0/5] expire the use of PcdSetNxForStack X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 15:04:51 -0000 Content-Type: text/plain; charset="UTF-8" On 12 September 2018 at 02:55, Ni, Ruiyu wrote: > > >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard >> Biesheuvel >> Sent: Wednesday, September 12, 2018 5:03 AM >> To: Ni, Ruiyu >> Cc: edk2-devel@lists.01.org >> Subject: Re: [edk2] [PATCH 0/5] expire the use of PcdSetNxForStack >> >> On 11 September 2018 at 11:13, Ni, Ruiyu wrote: >> > On 9/11/2018 4:57 PM, Ard Biesheuvel wrote: >> >> >> >> On 11 September 2018 at 07:16, Jian J Wang wrote: >> >>> >> >>> BZ#: https://bugzilla.tianocore.org/show_bug.cgi?id=1116 >> >>> >> >>> Since the stack memory is allocated as EfiBootServicesData, its NX >> >>> protection can be covered by BIT4 of PcdDxeNxMemoryProtectionPolicy. >> >>> To avoid confusing in setting related PCDs, PcdSetNxForStack will be >> >>> expired. Instead, If >> >>> BIT4 >> >>> of PcdDxeNxMemoryProtectionPolicy is set, the DxeIpl will set NX bit >> >>> in page table entries mapping the stack memory. >> >>> >> >> >> >> I disagree. This removes the possibility to map EfiBootServicesData >> >> as executable while still mapping the stack NX. As we all know, an >> >> executable stack is in a class of its own when it comes to >> >> exploitability, and should *never* be mapped executable unless in >> >> highly exceptional cases. Mapping all EfiBootServicesData as >> >> non-executable may cause backward compatibility problems. >> > >> > Ard, >> > Are you saying you want the capability of setting certain range of BS >> > data as executable? Why does ARM need such capability? >> > >> >> No, I am saying that mapping all BS data executable should be a separate >> decision from mapping the stack executable: if your platform cannot support the >> former (for historical reasons) you will likely still want the latter. > > Let me try to understand the specific problem in ARM64: > ARM64 uses 64KB page size to support 2^52 memory space. With 4KB page size, > it can only support 2^48 memory space. > But due to the DXE core AllocatePages() implementation, the hard-code 4KB granularity > (defined by UEFI spec) causes the page table protection for BS_DATA/BS_CODE is impossible. > So ARM64 chooses to disable the BS_DATA/BS_CODE protection, but only enable > the stack protection. > Correct? > If so, is changing spec to allow page-size platform configurable a better option? > I don't think so. We need to retain compatibility with PE/COFF and third party UEFI images, so changing the page size is likely to result in much more pain than it cures.