From patchwork Thu Jul 16 14:25:30 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chun-Yi Lee X-Patchwork-Id: 6807401 X-Patchwork-Delegate: rjw@sisk.pl Return-Path: X-Original-To: patchwork-linux-pm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 9EAAFC05AD for ; Thu, 16 Jul 2015 14:27:56 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id A9CAB20595 for ; Thu, 16 Jul 2015 14:27:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7C4D320702 for ; Thu, 16 Jul 2015 14:27:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752606AbbGPO1d (ORCPT ); Thu, 16 Jul 2015 10:27:33 -0400 Received: from mail-pd0-f174.google.com ([209.85.192.174]:34826 "EHLO mail-pd0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755961AbbGPO1b (ORCPT ); Thu, 16 Jul 2015 10:27:31 -0400 Received: by pdrg1 with SMTP id g1so45175086pdr.2; Thu, 16 Jul 2015 07:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=2Hxp1XlZ+PycpFe8dnsH0iKnL7oZob2Vg/O3V24Rufk=; b=XlIuLCUCzMPqGFqkpfSICQYV7eQiGpANcXGjBQ2cQoe62b6ppCT9KvgQ2Lanlvc+N/ cztpeAjCF+8jOunOCJvtbDV45y8tuIwC8lafoPZL0RJl8vdTIFC0LH4RkJabK2Bgpt21 bB0PSBzOH3v4M4lh5h3eagAsuVoA6dJFNwOFFu3oGnFsYf+FDTpqszFguK+bTDx+X+Wh C474vG8OpGniPLIVciXonTPQDkzwvVd9TloXBigpivz5F4F4bH4hKk/1iw+2ew9/qk1C PS9vtk2L1ZBIDwCYSPzEjYDCEu5zgObGf7amD431q9qRPWl04tuy8MrY8KRhqhUAvJWb VnAQ== X-Received: by 10.68.224.162 with SMTP id rd2mr19040865pbc.2.1437056850186; Thu, 16 Jul 2015 07:27:30 -0700 (PDT) Received: from linux-rxt1.site.site ([124.11.22.254]) by smtp.gmail.com with ESMTPSA id r4sm8219910pap.8.2015.07.16.07.27.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jul 2015 07:27:29 -0700 (PDT) From: "Lee, Chun-Yi" X-Google-Original-From: "Lee, Chun-Yi" To: linux-kernel@vger.kernel.org Cc: linux-efi@vger.kernel.org, linux-pm@vger.kernel.org, "Rafael J. Wysocki" , Matthew Garrett , Len Brown , Pavel Machek , Josh Boyer , Vojtech Pavlik , Matt Fleming , Jiri Kosina , "H. Peter Anvin" , "Lee, Chun-Yi" Subject: [RFC PATCH 16/16] PM / hibernate: Document signature verification of hibernate snapshot Date: Thu, 16 Jul 2015 22:25:30 +0800 Message-Id: <1437056730-15247-17-git-send-email-jlee@suse.com> X-Mailer: git-send-email 1.8.4.5 In-Reply-To: <1437056730-15247-1-git-send-email-jlee@suse.com> References: <1437056730-15247-1-git-send-email-jlee@suse.com> Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Signed-off-by: Lee, Chun-Yi --- Documentation/power/swsusp-signature-verify.txt | 86 +++++++++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 Documentation/power/swsusp-signature-verify.txt diff --git a/Documentation/power/swsusp-signature-verify.txt b/Documentation/power/swsusp-signature-verify.txt new file mode 100644 index 0000000..492e047 --- /dev/null +++ b/Documentation/power/swsusp-signature-verify.txt @@ -0,0 +1,86 @@ +Signature verification of hibernate snapshot +============================================ + +1) Introduction +2) How to enable +3) How does it work +4) Trigger key re-generate + +1) Introduction +--------------------- + +The hibernate function provided by kernel was used to snapshot memory +to be a image for keeping in storage, then restored in appropriate time. +There have potential threat from hacking the memory snapshot image. +Cracker may triggers hibernating process through ioctl to grab snapshot +image, then restoring modified image back to memory. Another situation +is booting to other hacked OS to modify the snapshot image in swap +partition or file, then user may runs malware after image restored to +memory. In addition, the above weakness cause kernel is not fully trusted +in EFI secure boot environment. + +So, kernel hibernate function needs a mechanism to verify integrity of +hibernate snapshot image. + +The origin idea is from Jiri Kosina: Let EFI bootloader generates key-pair +in UEFI secure boot environment, then forwarding keys to boot kernel for +signing/verifying snapshot image. + + +2) How to enable +----------------- + +If the HIBERNATE_VERIFICATION compile option is true, kernel hibernate code +will generating and verifying the signature of memory snapshot image by +HMAC-SHA1 algorithm. Current solution relies on EFI stub on x86 architecture, +so the signature verification logic will be bypassed on legacy BIOS. + +When the snapshot image unsigned or signed with an unknown key, the signature +verification will be failed. The default behavior of verifying failed is +accept restoring image but tainting kernel with H taint flag. + +Like kernel module signature checking, there's both a config option and +a boot parameter which control whether we accept or stop whole recovery +process when verification failed. Using HIBERNATE_VERIFICATION_FORCE kernel +compile option or "sigenforce" kernel parameter to force hibernate recovery +process stop when verification failed. + + +3) How does it work +------------------- + +For signing hibernate image, kernel need a key for generating signature of +image. The origin idea is using PKI, the EFI bootloader, shim generates key +pair and forward to boot kernel for signing/verifying image. In Linux Plumbers +Conference 2013, we got response from community experts for just using +symmetric key algorithm to generate signature, that's simpler and no EFI +bootloader's involving. + +Current solution is using HMAC-SHA1 algorithm, it generating HMAC key in EFI +stub by using RDRAND, RDTSC and EFI RNG protocol to grab random number to be +the entropy of key. Then the HMAC key stored in efi boot service variable, +key's security relies on EFI secure boot: When EFI secure boot enabled, only +trusted efi program allowed accessing boot service variables. + +In every EFI stub booting stage, it loads key from variable then forward key +to boot kernel for waiting to sign snapshot image by user trigger hibernating. +The HMAC-SHA1 algorithm generates signature then kernel put signature to the +header with the memory snapshot image. The signature with image is delivered +to userspace hibernating application or direct stored in swap partition. + +When hibernate recovering, kernel will verify the image signature before +switch whole system to image kernel and image memory space. When verifying +failed, kernel is tainted or stop recovering and discarding image. + + +4) Trigger key re-generate +-------------------------- + +The hibernate signature verifying function allows user to trigger the key +re-generating process in EFI stub through SNAPSHOT_REGENERATE_KEY ioctl. + +User can raise a key-regen flag in kernel through ioctl. When system runs +normal shutdown or reboot, kernel writes a efi runtime variable as a flag +then EFI stub will query the flag in next boot cycle. To avoid the swsusp +key changes in hibernating cycle that causes hibernate restoring failed, +the regen flag will be clear in a hibernate cycle.