From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 0B4EF8032C for ; Fri, 17 Mar 2017 05:11:12 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id g138so22899359itb.0 for ; Fri, 17 Mar 2017 05:11:12 -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=ZIHGVH3rAjNJ0J1X3c7ec/TBb3DPSBp6AMd6TlOJNfQ=; b=hZVED1CrRDPi8DZndzfvvgXqYviogWLObNw+fWdteFBQuw97Qp50H2be0nFkKCL27f XFGkfdi/m9LYMPslH1bSa2X0T9i/oZCacdNTXNfUHMcdi0xbrmSK2yGkLpMsVnoH+HOK iBs860kkLyC/PgbpVtqBobvZBtNFQpeQfuYkQ= 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=ZIHGVH3rAjNJ0J1X3c7ec/TBb3DPSBp6AMd6TlOJNfQ=; b=Lw54fuDXCfylm8zF1Z7uUtilpp1I8U2QBfk1F4SKQv7hn+xU7hz2a54JBS70QJVQqL yJregr2kamDXoW/8WwfT5746/BgdLxBVN2bbT0EKfbLglPGr0jQTXEpKJKyBQqkiL7xl 9mYZv0WXN+ufQ0LJYHKLH/NwDdWKQ0vvx+VJTdkb7eZt0wUDU8ikQhIhnB9x7pw+I7iL qRnj/ABfpb44OCin3uu31P9YSoz2LUOIEdy3DrLkIxtQSHmzUrQ8We8s3JYVYExCHnHP rYvC2UIPhOG5ofxQZnycozjYn1Ow7NDE1O1Kvq6SzwNgL/5HHn+WMO0iZOMqX8AMCajA yjUw== X-Gm-Message-State: AFeK/H0BRmBtkNh7Je7vd1p6/hgw1UM+BiYWX2fF7EHFdIBPYywAduBgPXf7Tl2zZsita8sX/T07S/LdqVgDL6v5 X-Received: by 10.107.168.21 with SMTP id r21mr13658145ioe.45.1489752671191; Fri, 17 Mar 2017 05:11:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.27 with HTTP; Fri, 17 Mar 2017 05:11:10 -0700 (PDT) In-Reply-To: <262ebc4d-629c-3437-2146-f4c0e5723f1a@redhat.com> References: <1487958664-10707-1-git-send-email-ard.biesheuvel@linaro.org> <74D8A39837DF1E4DA445A8C0B3885C503A8F5385@shsmsx102.ccr.corp.intel.com> <262ebc4d-629c-3437-2146-f4c0e5723f1a@redhat.com> From: Ard Biesheuvel Date: Fri, 17 Mar 2017 12:11:10 +0000 Message-ID: To: Laszlo Ersek Cc: "Yao, Jiewen" , "edk2-devel@lists.01.org" , "Gao, Liming" 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:11:12 -0000 Content-Type: text/plain; charset=UTF-8 On 17 March 2017 at 12:07, Laszlo Ersek wrote: > 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). > Well, the warning may be a bit loud, but this is expected behavior. I expect to be able to queue the linux/arm64 changes that split the PE/COFF sections and align them to 4 KB for v4.12, and so current kernels all consists of a single rwx section, which does not qualify as a code section. > 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. > It's a PE/COFF image not an ELF image.