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::236; helo=mail-it0-x236.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 2F2D9220D4BE3 for ; Wed, 15 Nov 2017 07:54:56 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id f187so2308295itb.1 for ; Wed, 15 Nov 2017 07:59:04 -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=0O1gvW0IISpm2BDiEqhT6SV8EHSiXc2MKS5ti3bFiQQ=; b=jCJDMV4E3ahSroXHqDaOsWGUveZuQYvzbu6Rss281mG/WeGTAzqKUxECluwPU5F1aM ivALFLxtvkG9EAHFWzGQu8M/c6DxJG4kLjuZHUBVzTHg6OHf0mw0mok1MgSWQLgEyeem ksPm95FsIPCUCaYEKG/AbYKbpx1venhVDek1M= 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=0O1gvW0IISpm2BDiEqhT6SV8EHSiXc2MKS5ti3bFiQQ=; b=lypbfj+JEoFeG8nfSdiOuPssg56IqHgby5e10J/SMKj0MZAFSWZ0q864OEKoj8J7cQ yYmWQF6XcvrtiEVEm4u2hFqtS2KTfK2AXKwYkev9+7TWMNOVCC4pqyybg2dk3Ug8WYNc AFy26H8PR5lSH/vXNIe7xppZuVHFTYmSMjw8DuOXQcVQZDvxJWBtGzNa/2IiQB5mWb4n Y4ZRZISsYTscBvC6F1Jm/3NmWdeVra9tcEDBuzAZxDdkA+JWP2WBsxAWxGH4pSBwH9WK bASLHYmu+vP0NZpY1QgfeZV2cbzp0vTCYvSGz7WsbNEU9YP8AaoqQuZaDSlRaX6JkZ/F lnPg== X-Gm-Message-State: AJaThX52zSewA8gZqa7obpVRwR6giaklrktS50qA72TR39FlCqcZhZtd rLlT9zg+/7heVJqsoYoBnpX+qLB+sCtkshD5bCbdEg== X-Google-Smtp-Source: AGs4zMZ2VjOCAtg/4j0X39HcD8qXn2A/GYz9xxYA1nI8UD7dcRS27a0zsqTMmMZULj6jDXdkhmYhreaypFrNSMYjZr0= X-Received: by 10.36.31.212 with SMTP id d203mr19268980itd.48.1510761543688; Wed, 15 Nov 2017 07:59:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.104.20 with HTTP; Wed, 15 Nov 2017 07:59:03 -0800 (PST) In-Reply-To: References: <20171110010223.12696-1-jian.j.wang@intel.com> <9f53346f-c82c-c0ee-bca8-f53116227926@redhat.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B9B5921@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Wed, 15 Nov 2017 15:59:03 +0000 Message-ID: To: Laszlo Ersek Cc: "Wang, Jian J" , "Zeng, Star" , Matt Fleming , "edk2-devel@lists.01.org" , "Yao, Jiewen" , "Dong, Eric" Subject: Re: [PATCH v5] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map 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: Wed, 15 Nov 2017 15:54:56 -0000 Content-Type: text/plain; charset="UTF-8" On 15 November 2017 at 15:48, Laszlo Ersek wrote: > Hi Jian, > > On 11/15/17 10:27, Wang, Jian J wrote: >> I tried this workaround and there're no failure in booting Fedora 26 and Windows >> server 2016 now. If no objection, I'll merge it into new version of this patch. > > I'm not too familiar with the Linux kernel's EFI pieces myself; that's > why I added Ard and Matt earlier to the thread (when I responded with > the regression report) -- Ard and Matt maintain EFI in the Linux kernel. > > So, if you think there's a bug in Linux (i.e., a mis-interpretation of > the UEFI spec), can you guys please discuss that together? Below you wrote: > > - "I think it must be that the kernel will mark the memory block to be > RO/XP/RP memory according to its capabilities but not its current > attributes" > The UEFI spec does not distinguish between capabilities and attributes, so how on earth should the OS be able to make this distinction? For instance, the UEFI spec defines EFI_MEMORY_RO as """ Physical memory protection attribute: The memory region supports making this memory range read-only by system hardware. """ which is essentially a capability not an attribute. However, EFI_MEMORY_RO/XP are also used to convey information about the nature of the *contents* of the memory region, i.e., is it .text, .rodata or .data/.bss So given that the OS only has the UEFI memory map to go on, how exactly should it figure out what these attributes are meant to imply? > - "there's real gap between UEFI and OS on how to interpret the memory > capabilities" > Yes. There is also a gap between how GCD and the UEFI memory map interpret these attributes, which is why nobody bothers to set the protection capabilities for GCD: it gets copied into the UEFI memory map, and nobody has a clue how the OS should treat it. When the [short lived] EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA feature was introduced, it was essentially decided that RO and XP may be used to annotate the nature of the contents of memory regions, where code was mapped RO and data mapped XP. > Why is it wrong for the OS kernel, according to the UEFI spec, to change > the attributes / mappings of a memory area, as long as it stays > compliant with the advertised capabilities? How is an OS expected to > work, upon seeing those new "paging capabilities from UEFI memory map" > (in Star's words)? > > Apparently, it's not just Linux that's confused; see the Win2016 crash > too. Is the UEFI spec detailed enough on those capabilities? (Recently I > tried to review the paging capabilities myself in the spec, and I ended > up totally confused...) > I think it is simply impossible at this point to interpret those flags as attributes, i.e., RO means code that may be mapped read-only, and XP means data that may be mapped non-executable. Anything beyond that opens a can of worms that is bound to break stuff all over the place. -- Ard.