From patchwork Mon Dec 4 02:57:50 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 120474 Delivered-To: patch@linaro.org Received: by 10.140.22.227 with SMTP id 90csp3919461qgn; Sun, 3 Dec 2017 18:54:43 -0800 (PST) X-Google-Smtp-Source: AGs4zMZ80b5pnNHpslfLfcd6sNSK7S27Y4m1ABQuslvMQl94KTbcFv93/PTctVrbgw+UY2Rzfmfj X-Received: by 10.99.117.12 with SMTP id q12mr12845796pgc.412.1512356083061; Sun, 03 Dec 2017 18:54:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512356083; cv=none; d=google.com; s=arc-20160816; b=TSoQtFzfdil7TSZOlb1dBOF2Vs4ogO0gYwoqvm1GGVgN5/o+gkKIxohdtCMk4F7xTZ akhndaN5ax4qsom6o18xraMywH5InAzuCtuORZaMsclPPbyWP2IGe0STDr8dOOY2vMcf Wx2cjPPvLNIAdRoGV+oPiVs1SaQFu/rg57y2321LYFbJmXyOYUJ0OPisOe2zGB7n7Ouj PTx8cPz9W/uQ6mE5ejgxl/2baFZZ7Z5ffVHxOV5epWNW8jYbGd2BfGkDTvAyOK2zo5TA dnGBkItwy/3EfmOee+ju0+e/W+oRPCWabuehWXH+tVhtlWTEhrsXAWcJW9UmFTtf6gYR q3yQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=dnIizBF+A/EOxSpAcSXehuK7NxczdeVDPKEY1nboEvM=; b=y8jWmoG7LZe7BFQP0HzmMf94Fn7651OHAZFxB0YZpTLgpv130dK64nhtRR7RAoUScT lfMeNa+/WLovoi5keNbFWGqVNOH32TCN+aKBX/lMHM9c7fYfujCHIjbFv4KiyoXi8abx B1gTSwd394Fgh/nrd458ZhAwy9BXwlz60GzKweXe9zoSfSF4yd+hRi3Fpw6QWdX4l6uJ WrEy7QRRX9N45UjQvueACLDD6M78yVGlvLOcizEu6B6/4xeKENDvPM5SIkMWBbR4wSOu HhqRMapNE1NborgGXNGKPeZuYKlEdzyGQD92OqNqh2vFaYYVOjhWd2CignJy0bewdWZV d2pQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=MvYTGslU; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t2si8679855pgf.516.2017.12.03.18.54.42; Sun, 03 Dec 2017 18:54:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=MvYTGslU; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753117AbdLDCyj (ORCPT + 28 others); Sun, 3 Dec 2017 21:54:39 -0500 Received: from mail-pg0-f54.google.com ([74.125.83.54]:33125 "EHLO mail-pg0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753056AbdLDCyh (ORCPT ); Sun, 3 Dec 2017 21:54:37 -0500 Received: by mail-pg0-f54.google.com with SMTP id g7so7211371pgs.0 for ; Sun, 03 Dec 2017 18:54:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=dnIizBF+A/EOxSpAcSXehuK7NxczdeVDPKEY1nboEvM=; b=MvYTGslUu3JDud5fQWsjRP+r29AGTlo+mqaYfV2aQDnftGJzhllUDFI1o7OAAvXW9v Clx9c/Lw8c1hDEtfJPKoS122gotu7zvtAo61ZzSaC6+i7Mn+pD1C34Syp/1PybPv1X6n lnDLCN+wxVHyG0JC+8iZyDolbff0Rx4vYW/Dk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=dnIizBF+A/EOxSpAcSXehuK7NxczdeVDPKEY1nboEvM=; b=RxLYxxhMusdydbPR5TxDBl2hm5LPw304Q/p9t7I4wuKgqcHxXsVAfByDcGT4jYXaMR RFkdC86tfVKxbEbJKBFusAJuui1gJXu3jYFsnRPhtSbOtXJRWRCET1SeDvzejVFb1L84 wd2zAgwTR7obEBcIYBolS1i2jTjwStJnAdPFlYiP9RBuMKYJ0zXGftirgw5V35cDWu1J 9kj9SygfWU0FoJcSJEHE4o/37IFvcdEUraZHJcddMNzrHZYBvbbOl1Tzommo+pehFyi1 HxRIgGyPLzk5aPc9soFLf3nppiWoXDWQDsMf40e6hFcoQEng81PCmxMkZmlY9OE/qBEV 53FQ== X-Gm-Message-State: AJaThX6kwM5kp4C7lYt8pINsv4ZJc5zXxbeVT08XzmnPjPIw+/5LdSBe DUG1mnzb3BbL3kHNVuW66bv8RA== X-Received: by 10.84.141.36 with SMTP id 33mr13226967plu.247.1512356076864; Sun, 03 Dec 2017 18:54:36 -0800 (PST) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id x15sm18644533pfh.27.2017.12.03.18.54.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Dec 2017 18:54:35 -0800 (PST) From: AKASHI Takahiro To: catalin.marinas@arm.com, will.deacon@arm.com, bauerman@linux.vnet.ibm.com, dhowells@redhat.com, vgoyal@redhat.com, herbert@gondor.apana.org.au, davem@davemloft.net, akpm@linux-foundation.org, mpe@ellerman.id.au, dyoung@redhat.com, bhe@redhat.com, arnd@arndb.de, ard.biesheuvel@linaro.org, julien.thierry@arm.com Cc: kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, AKASHI Takahiro Subject: [PATCH v7 00/11] arm64: kexec: add kexec_file_load() support Date: Mon, 4 Dec 2017 11:57:50 +0900 Message-Id: <20171204025801.12161-1-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.14.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is the seventh round of implementing kexec_file_load() support on arm64.[1] Most of the code is based on kexec-tools (along with some kernel code from x86, which also came from kexec-tools). This patch series enables us to * load the kernel, Image, via kexec_file_load() system call, and * optionally verify its signature at load time for trusted boot. To load the kernel via kexec_file_load() system call, a small change is also required on kexec-tools. See [2]. This enables '-s' option. (Please use v7.2.1+ crash utility for v4.14+ kernel) As we discussed a long time ago, users may not be allowed to specify device-tree file of the 2nd kernel explicitly with kexec-tools, hence re-using the blob of the first kernel. Regarding a kernel image verification, a signature must be presented along with the binary itself. A signature is basically a hash value calculated against the whole binary data and encrypted by a key which will be authenticated by the system's trusted certificate. Any attempt to read and load a to-be-kexec-ed kernel image through a system call will be checked and blocked if the binary's hash value doesn't match its associated signature. There are two methods available now: 1. implementing arch-specific verification hook of kexec_file_load() 2. utilizing IMA(Integrity Measurement Architecture)[3] appraisal framework Before my v7, I believed that my patch only supports (1) but am now confident that (2) comes free if IMA is enabled and properly configured. (1) Arch-specific verification hook If CONFIG_KEXEC_VERIFY_SIG is enabled, kexec_file_load() invokes an arch- defined (and hence file-format-specific) hook function to check for the validity of kernel binary. On x86, a signature is embedded into a PE file (Microsoft's format) header of binary. Since arm64's "Image" can also be seen as a PE file as far as CONFIG_EFI is enabled, we adopt this format for kernel signing. As in the case of UEFI applications, we can create a signed kernel image: $ sbsign --key ${KEY} --cert ${CERT} Image You may want to use certs/signing_key.pem, which is intended to be used for module sigining (CONFIG_MODULE_SIG), as ${KEY} and ${CERT} for test purpose. (2) IMA appraisal-based IMA was first introduced in linux in order to meet TCG (Trusted Computing Group) requirement that all the sensitive files be *measured* before reading/executing them to detect any untrusted changes/modification. Then appraisal feature, which allows us to ensure the integrity of files and even prevent them from reading/executing, was added later. Meanwhile, kexec_file_load() has been merged since v3.17 and evolved to enable IMA-appraisal type verification by the commit b804defe4297 ("kexec: replace call to copy_file_from_fd() with kernel version"). In this scheme, a signature will be stored in a extended file attribute, "security.ima" while a decryption key is hold in a dedicated keyring, ".ima" or "_ima". All the necessary process of verification is confined in a secure API, kernel_read_file_from_fd(), called by kexec_file_load(). Please note that powerpc is one of the two architectures now supporting KEXEC_FILE, and that it wishes to exntend IMA, where a signature may be appended to "vmlinux" file[4], like module signing, instead of using an extended file attribute. While IMA meant to be used with TPM (Trusted Platform Module) on secure platform, IMA is still usable without TPM. Here is an example procedure about how we can give it a try to run the feature using a self-signed root ca for demo/test purposes: 1) Generate needed keys and certificates, following "Generate trusted keys" section in README of ima-evm-utils[5]. 2) Build the kernel with the following kernel configurations, specifying "ima-local-ca.pem" for CONFIG_SYSTEM_TRUSTED_KEYS: CONFIG_EXT4_FS_SECURITY CONFIG_INTEGRITY_SIGNATURE CONFIG_INTEGRITY_ASYMMETRIC_KEYS CONFIG_INTEGRITY_TRUSTED_KEYRING CONFIG_IMA CONFIG_IMA_WRITE_POLICY CONFIG_IMA_READ_POLICY CONFIG_IMA_APPRAISE CONFIG_IMA_APPRAISE_BOOTPARAM CONFIG_SYSTEM_TRUSTED_KEYS Please note that CONFIG_KEXEC_VERIFY_SIG is not, actually should not be, enabled. 3) Sign(label) a kernel image binary to be kexec-ed on target filesystem: $ evmctl ima_sign --key /path/to/private_key.pem /your/Image 4) Add a command line parameter and boot the kernel: ima_appraise=enforce On live system, 5) Set a security policy: $ mount -t securityfs none /sys/kernel/security $ echo "appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig" \ > /sys/kernel/security/ima/policy 6) Add a key for ima: $ keyctl padd asymmetric my_ima_key %:.ima < /path/to/x509_ima.der (or evmctl import /path/to/x509_ima.der ) 7) Then try kexec as normal. Concerns(or future works): * Even if the kernel is configured with CONFIG_RANDOMIZE_BASE, the 2nd kernel won't be placed at a randomized address. We will have to add some boot code similar to efi-stub to implement the randomization. for approach (1), * While big-endian kernel can support kernel signing, I'm not sure that Image can be recognized as in PE format because x86 standard only defines little-endian-based format. * vmlinux support [1] http://git.linaro.org/people/takahiro.akashi/linux-aarch64.git branch:arm64/kexec_file [2] http://git.linaro.org/people/takahiro.akashi/kexec-tools.git branch:arm64/kexec_file [3] https://sourceforge.net/p/linux-ima/wiki/Home/ [4] http://lkml.iu.edu//hypermail/linux/kernel/1707.0/03669.html [5] https://sourceforge.net/p/linux-ima/ima-evm-utils/ci/master/tree/ Changes in v7 (Dec 4, 2017) * rebased to v4.15-rc2 * re-organize the patch set to separate KEXEC_FILE_VERIFY_SIG-related code from the others * revamp factored-out code in kernel/kexec_file.c due to the changes in original x86 code * redefine walk_sys_ram_res_rev() prototype due to change of callback type in the counterpart, walk_sys_ram_res() * make KEXEC_FILE_IMAGE_FMT defaut on if KEXEC_FILE selected Changes in v6 (Oct 24, 2017) * fix a for-loop bug in _kexec_kernel_image_probe() per Julien Changes in v5 (Oct 10, 2017) * fix kbuild errors around patch #3 per Julien's comments, * fix a bug in walk_system_ram_res_rev() with some cleanup * modify fdt_setprop_range() to use vmalloc() * modify fill_property() to use memset() Changes in v4 (Oct 2, 2017) * reinstate x86's arch_kexec_kernel_image_load() * rename weak arch_kexec_kernel_xxx() to _kexec_kernel_xxx() for better re-use * constify kexec_file_loaders[] Changes in v3 (Sep 15, 2017) * fix kbuild test error * factor out arch_kexec_kernel_*() & arch_kimage_file_post_load_cleanup() * remove CONFIG_CRASH_CORE guard from kexec_file.c * add vmapped kernel region to vmcore for gdb backtracing (see prepare_elf64_headers()) * merge asm/kexec_file.h into asm/kexec.h * and some cleanups Changes in v2 (Sep 8, 2017) * move core-header-related functions from crash_core.c to kexec_file.c * drop hash-check code from purgatory * modify purgatory asm to remove arch_kexec_apply_relocations_add() * drop older kernel support * drop vmlinux support (at least, for this series) Patch #1 to #9 are essential for KEXEC_FILE support (plus IMA-based verification): Patch #1 to #4 are all preparatory patches on generic side. Patch #5 to #8 are common for enabling kexec_file_load. Patch #9 is for 'Image'-specific loading. Patch #10 to #11 are for KEXEC_VERIFY_SIG (arch-specific verification) support AKASHI Takahiro (11): resource: add walk_system_ram_res_rev() kexec_file: factor out arch_kexec_kernel_*() from x86, powerpc kexec_file: factor out crashdump elf header function from x86 asm-generic: add kexec_file_load system call to unistd.h arm64: kexec_file: create purgatory arm64: kexec_file: load initrd, device-tree and purgatory segments arm64: kexec_file: set up for crash dump adding elf core header arm64: kexec_file: enable KEXEC_FILE config arm64: kexec_file: add Image format support include: pe.h: remove message[] from mz header definition arm64: kexec_file: enable KEXEC_VERIFY_SIG for Image arch/arm64/Kconfig | 30 +++ arch/arm64/Makefile | 1 + arch/arm64/include/asm/kexec.h | 93 +++++++ arch/arm64/kernel/Makefile | 4 +- arch/arm64/kernel/kexec_image.c | 105 ++++++++ arch/arm64/kernel/machine_kexec_file.c | 368 ++++++++++++++++++++++++++++ arch/arm64/purgatory/Makefile | 24 ++ arch/arm64/purgatory/entry.S | 55 +++++ arch/powerpc/include/asm/kexec.h | 2 +- arch/powerpc/kernel/kexec_elf_64.c | 2 +- arch/powerpc/kernel/machine_kexec_file_64.c | 39 +-- arch/x86/include/asm/kexec-bzimage64.h | 2 +- arch/x86/kernel/crash.c | 324 ------------------------ arch/x86/kernel/kexec-bzimage64.c | 2 +- arch/x86/kernel/machine_kexec_64.c | 45 +--- include/linux/ioport.h | 3 + include/linux/kexec.h | 32 ++- include/linux/pe.h | 2 +- include/uapi/asm-generic/unistd.h | 4 +- kernel/kexec_file.c | 365 ++++++++++++++++++++++++++- kernel/kexec_internal.h | 20 ++ kernel/resource.c | 57 +++++ 22 files changed, 1158 insertions(+), 421 deletions(-) create mode 100644 arch/arm64/kernel/kexec_image.c create mode 100644 arch/arm64/kernel/machine_kexec_file.c create mode 100644 arch/arm64/purgatory/Makefile create mode 100644 arch/arm64/purgatory/entry.S -- 2.14.1