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::242; helo=mail-it0-x242.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (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 CC60F220D4BE9 for ; Thu, 16 Nov 2017 01:25:21 -0800 (PST) Received: by mail-it0-x242.google.com with SMTP id y15so5165717ita.4 for ; Thu, 16 Nov 2017 01:29:31 -0800 (PST) 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=WsACG4LNIAy8MLVQyzjTGJxTNkbgQSQkN+tNND6ecBk=; b=GYDKUBEuDZFqPUOWo8nnzc6y8jYcMnj5m88YPqxQyQR/rpr8DtakDSlp10VM8abVvD hF2F1dDKFv/2rLVTxMx+rXisaSUunv3PTMJl40QYT7kSsO3UGO4vkrnEpCppEpFNsnhj K4agc0jvwbqlsbK/hmDr2Bthge3VB1zznh0pk= 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=WsACG4LNIAy8MLVQyzjTGJxTNkbgQSQkN+tNND6ecBk=; b=Ketyk2x3/nQnSTDOMGcKCPCupR8tWjpyca7rfcna6t0uDuM73roey406xBpRW7b9Db 6pd+2z8XjDvoxal04evI/UEFKvEMcnUh+6Ykp9WN2U3JQyA9J05XaQwa/ZiLGnvnPH/t 8pvJDKmfL8VEwFDmlTpNqC1NZp/lHibKbtm8btBWK7e0mBb3lE+zCKTcOuX3ImHm78he n3hoWHYOykQIvHWjEpKIY17AFjxqkDJYx8L80kjxKoaAoNkqMuXM6sBegkIHPSW6hYOs GjcKmIXWQpiUU3iE8c4haTXyY65cEbFwtlgFQ43ySyBGxlOlFEuq1YGTcLH2vv+Is1Uz eODQ== X-Gm-Message-State: AJaThX7vdXuGkoPUPsCxeypPgUH8t+bbsgD5xdrhAXaaWLAb2EsfmMH7 T1cd60ZoG4Kp1jby9v1VXWkVumDd5QcV1JOLqIu9eg== X-Google-Smtp-Source: AGs4zMYjtAKGmzQOlwFjI7ixxYMP2Z2UUDw24Ru2hsJq+giJ4CYVk3kaf1kiUe0QOC62egzuVmLblxqteeItunEZrz4= X-Received: by 10.36.48.4 with SMTP id q4mr1537220itq.34.1510824570488; Thu, 16 Nov 2017 01:29:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.104.3 with HTTP; Thu, 16 Nov 2017 01:29:30 -0800 (PST) In-Reply-To: <0C09AFA07DD0434D9E2A0C6AEB0483103B9B62E6@shsmsx102.ccr.corp.intel.com> References: <20171116072700.11456-1-jian.j.wang@intel.com> <20171116072700.11456-2-jian.j.wang@intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B9B62E6@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Thu, 16 Nov 2017 09:29:30 +0000 Message-ID: To: "Zeng, Star" Cc: "Wang, Jian J" , Laszlo Ersek , "edk2-devel@lists.01.org" , "Yao, Jiewen" Subject: Re: [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities 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: Thu, 16 Nov 2017 09:25:22 -0000 Content-Type: text/plain; charset="UTF-8" On 16 November 2017 at 09:28, Zeng, Star wrote: > Ard, > > EFI_MEMORY_WP is for cache. > > UefiSpec.h > // > // Note: UEFI spec 2.5 and following: use EFI_MEMORY_RO as write-protected physical memory > // protection attribute. Also, EFI_MEMORY_WP means cacheability attribute. > // > #define EFI_MEMORY_WP 0x0000000000001000ULL > Yes, but that was a change in v2.5, before that it was a permission attribute. So it should be filtered from the OS visible memory map as well. > Thanks, > Star > -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > Sent: Thursday, November 16, 2017 5:25 PM > To: Wang, Jian J > Cc: edk2-devel@lists.01.org; Yao, Jiewen ; Zeng, Star ; Laszlo Ersek > Subject: Re: [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities > > On 16 November 2017 at 07:26, Jian J Wang wrote: >> Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really set >> attributes and change memory paging attribute accordingly. >> But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by value from >> Capabilities in GCD memory map. This might cause boot problems. >> Clearing all paging related capabilities can workaround it. The code >> added in this patch is supposed to be removed once the usage of >> EFI_MEMORY_DESCRIPTOR.Attribute is clarified in UEFI spec and adopted >> by both EDK-II Core and all supported OSs. >> >> Cc: Jiewen Yao >> Cc: Star Zeng >> Cc: Laszlo Ersek >> Cc: Ard Biesheuvel >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Jian J Wang >> --- >> MdeModulePkg/Core/Dxe/Mem/Page.c | 17 +++++++++++++++++ >> 1 file changed, 17 insertions(+) >> >> diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c >> b/MdeModulePkg/Core/Dxe/Mem/Page.c >> index c9219cc068..783b576e35 100644 >> --- a/MdeModulePkg/Core/Dxe/Mem/Page.c >> +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c >> @@ -1829,6 +1829,23 @@ CoreGetMemoryMap ( >> // >> BufferSize = ((UINT8 *)MemoryMap - (UINT8 *)MemoryMapStart); >> >> + // >> + // WORKAROUND: Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really >> + // set attributes and change memory paging attribute accordingly. >> + // But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by >> + // value from Capabilities in GCD memory map. This might cause >> + // boot problems. Clearing all paging related capabilities can >> + // workaround it. Following code is supposed to be removed once >> + // the usage of EFI_MEMORY_DESCRIPTOR.Attribute is clarified in >> + // UEFI spec and adopted by both EDK-II Core and all supported >> + // OSs. >> + // >> + while (MemoryMapStart < MemoryMap) { >> + MemoryMapStart->Attribute &= ~(UINT64)(EFI_MEMORY_RP | EFI_MEMORY_RO | >> + EFI_MEMORY_XP); > > Why is EFI_MEMORY_WP missing here? > >> + MemoryMapStart = NEXT_MEMORY_DESCRIPTOR(MemoryMapStart, Size); } >> + >> Status = EFI_SUCCESS; >> >> Done: >> -- >> 2.14.1.windows.1 >> > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel