From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id CEE6B8040B for ; Fri, 17 Mar 2017 05:07:37 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 383DBC01B3F7; Fri, 17 Mar 2017 12:07:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 383DBC01B3F7 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 383DBC01B3F7 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-70.phx2.redhat.com [10.3.116.70]) by smtp.corp.redhat.com (Postfix) with ESMTP id 04E50627DD; Fri, 17 Mar 2017 12:07:36 +0000 (UTC) To: Ard Biesheuvel , "Yao, Jiewen" References: <1487958664-10707-1-git-send-email-ard.biesheuvel@linaro.org> <74D8A39837DF1E4DA445A8C0B3885C503A8F5385@shsmsx102.ccr.corp.intel.com> Cc: "edk2-devel@lists.01.org" , "Gao, Liming" From: Laszlo Ersek Message-ID: <262ebc4d-629c-3437-2146-f4c0e5723f1a@redhat.com> Date: Fri, 17 Mar 2017 13:07:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 17 Mar 2017 12:07:38 +0000 (UTC) Subject: Re: [PATCH] MdeModulePkg/DxeCore: base code protection on permission attributes 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, 17 Mar 2017 12:07:38 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 02/26/17 15:00, Ard Biesheuvel wrote: > On 25 February 2017 at 04:04, Yao, Jiewen wrote: >> Hi Ard >> I agree with you on this enhancement. >> >> I prefer to adding the description as comment in the code, so that people >> can get clear picture when he/she reads the code. >> >> // >> // Instead of assuming that a PE/COFF section of type EFI_IMAGE_SCN_CNT_CODE >> // can always be mapped read-only, classify a section as a code section only >> // if it has the executable attribute set and the writable attribute >> cleared. >> // >> // This adheres more closely to the PE/COFF spec, and avoids issues with >> // Linux OS loaders that consists of a single read/write/execute section. >> // >> if ((Section[Index].Characteristics & (EFI_IMAGE_SCN_MEM_WRITE | >> EFI_IMAGE_SCN_MEM_EXECUTE)) == EFI_IMAGE_SCN_MEM_EXECUTE) { >> >> With comment update, reviewed-by: Jiewen.yao@intel.com >> > > Thanks Jiewen > > Pushed as a2ed40c02bf2 Is it possible that (recent?) Linux EFI stubs (aarch64) don't pass the above check? I got a report from a colleague: !!!!!!!! ProtectUefiImageCommon - CodeSegmentCount is 0 !!!!!!!! EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... I tried to reproduce it with "4.5.0-15.el7.aarch64", and with "4.8.7-300.fc25.aarch64", and I'm not seeing the message with either. I asked him about the exact kernel version (no answer yet, his workday hasn't started yet). Any idea how I could validate the section headers of a (decompressed) kernel image? I tried "aarch64-linux-gnu-objdump --section-headers", but it doesn't recognize the image. Thanks, Laszlo >>> -----Original Message----- >>> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] >>> Sent: Saturday, February 25, 2017 1:51 AM >>> To: edk2-devel@lists.01.org; Yao, Jiewen >>> Cc: Gao, Liming ; Ard Biesheuvel >>> >>> Subject: [PATCH] MdeModulePkg/DxeCore: base code protection on permission >>> attributes >> >> >>> >>> Instead of assuming that a PE/COFF section of type EFI_IMAGE_SCN_CNT_CODE >>> can always be mapped read-only, classify a section as a code section only >>> if it has the executable attribute set and the writable attribute cleared. >>> >>> This adheres more closely to the PE/COFF spec, and avoids issues with >>> Linux OS loaders that consists of a single read/write/execute section. >>> >>> Contributed-under: TianoCore Contribution Agreement 1.0 >>> Signed-off-by: Ard Biesheuvel >>> --- >>> MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c >>> b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c >>> index 1142dcc5a83d..3e037607a6be 100644 >>> --- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c >>> +++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c >>> @@ -533,7 +533,7 @@ ProtectUefiImageCommon ( >>> Name[7] >>> )); >>> >>> - if ((Section[Index].Characteristics & EFI_IMAGE_SCN_CNT_CODE) != 0) { >>> + if ((Section[Index].Characteristics & (EFI_IMAGE_SCN_MEM_WRITE | >>> EFI_IMAGE_SCN_MEM_EXECUTE)) == EFI_IMAGE_SCN_MEM_EXECUTE) { >>> DEBUG ((DEBUG_VERBOSE, " VirtualSize - 0x%08x\n", >>> Section[Index].Misc.VirtualSize)); >>> DEBUG ((DEBUG_VERBOSE, " VirtualAddress - 0x%08x\n", >>> Section[Index].VirtualAddress)); >>> DEBUG ((DEBUG_VERBOSE, " SizeOfRawData - 0x%08x\n", >>> Section[Index].SizeOfRawData)); >>> -- >>> 2.7.4 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel >