From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 C3E5682020 for ; Fri, 10 Feb 2017 06:16:54 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id r185so33575077ita.0 for ; Fri, 10 Feb 2017 06:16:54 -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=C6Xv6xaicp0Ixq0+h4jo9dXerU3DOEX5XkojafC8rkg=; b=a/4C/IBfOYRmo/8n9lY3i8Q1Rkl2vnMP/fDRnFxVm7cEIRQCeWwWal7iFqoIZkJ3+u djoBA+rfwzyX8Ojw7q4LED2jC6Ev8iYrxb6zcfEzzA1ijq3x2dz7D73hhwAdeOsbLngC /g36KNa1BiEA1F5dWmP5JfUqdaXJLzL2FvGfU= 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=C6Xv6xaicp0Ixq0+h4jo9dXerU3DOEX5XkojafC8rkg=; b=dhd8r9WvtK1u+rQMqc0aJaJxyn3zApUuJlpKWya3MzqLOIfP0fQu+VxP4rCxotFyk0 DI3UCPRNdv5xHgdpli+PxrWSqU+0gOLQinIqL85bqJTjKwifSXoxbml1V/MVwgRSlsDg /COfvdGsfRjz4F8afWTDdsWzFXMf5VrwPdWIvuSDWydMaYShwygt5U8jLt85SV+zaJDc V28Y03ZbZnuhJ+YxpuwrpblVIYQ5YXIb6wn3Q3652siN97B1naiyXs+if9a6fi/c6CaO 9kyAfcEJmbHoiBCtE7QyiIFIBU/7Cyfnuly2KjeeUDpUryDD3D0lM9y+QvL7qUsLYW/3 jKMA== X-Gm-Message-State: AIkVDXLBQNzwKU+1zoXkHnZ5Lq6Je6RncM1MqPUJpj3yYoeNMnNwp3a4A6hw0P4hdb2IzVxB+e6TAvswiNLw18iC X-Received: by 10.36.23.74 with SMTP id 71mr26434627ith.37.1486736213884; Fri, 10 Feb 2017 06:16:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.144.139 with HTTP; Fri, 10 Feb 2017 06:16:53 -0800 (PST) In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503A8ECAA8@shsmsx102.ccr.corp.intel.com> References: <1486624832-15736-1-git-send-email-jiewen.yao@intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A8EBD52@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A8EBEC3@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A8EBF20@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A8EC023@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A8EC093@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A8EC562@shsmsx102.ccr.corp.intel.com> <4F3E8C94-BFF2-42A5-8E12-C03F955627F8@linaro.org> <0ACD6B44-66A4-474E-A9E5-55A322FD169B@linaro.org> <74D8A39837DF1E4DA445A8C0B3885C503A8ECA37@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A8ECAA8@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Fri, 10 Feb 2017 14:16:53 +0000 Message-ID: To: "Yao, Jiewen" Cc: "Tian, Feng" , "edk2-devel@lists.01.org" , Leif Lindholm , "Kinney, Michael D" , "Fan, Jeff" , "Zeng, Star" Subject: Re: [PATCH V3 0/4] DXE Memory Protection X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 14:16:55 -0000 Content-Type: text/plain; charset=UTF-8 On 10 February 2017 at 12:59, Yao, Jiewen wrote: > Thanks for the info. > > > > Mike/Vincent also mentioned that FW does not own page tables after > ExitBootServices(), so the OS would have to relax NX protection of RT code > pages across SVA. > > Or delay setting NX protections on RT code pages until after SVA. > > > > I agree with you that we can mark RT region to be RW. > > Here is the pseudo code I plan to put to CoreExitBootServices(). > > > > ======================= > > VOID > > MemoryprotectionExitBootServicesCallback ( > > VOID > > ) > > { > > EFI_RUNTIME_IMAGE_ENTRY *RuntimeImage; > > LIST_ENTRY *Link; > > > > // > > // We need remove the RT protection, because RT relocation need write code > segment > > // at SetVirtualAddressMap(). We cannot assume OS/Loader has taken over > page table at that time. > > // > > // Firmware does not own page tables after ExitBootServices(), so the OS > would > > // have to relax protection of RT code pages across > SetVirtualAddressMap(), or > > // delay setting protections on RT code pages until after > SetVirtualAddressMap(). > > // OS may set protection on RT based upon EFI_MEMORY_ATTRIBUTES_TABLE > later. > > // > > if (mImageProtectionPolicy != 0) { > > for (Link = gRuntime->ImageHead.ForwardLink; Link != > &gRuntime->ImageHead; Link = Link->ForwardLink) { > > RuntimeImage = BASE_CR (Link, EFI_RUNTIME_IMAGE_ENTRY, Link); > > SetUefiImageMemoryAttributes ((UINT64)(UINTN)RuntimeImage->ImageBase, > ALIGN_VALUE(RuntimeImage->ImageSize, EFI_PAGE_SIZE), 0); > > } > > } > > } This looks correct to me, and it is the only place where we can deal with this situation.