Received: by 10.213.65.68 with SMTP id h4csp313425imn; Mon, 12 Mar 2018 14:55:16 -0700 (PDT) X-Google-Smtp-Source: AG47ELtmWRt/81fZpfTSMbDGH1BIBK9tO+wST8MQIiOpFGAi79i8mDokXvbuNMSu+bE5zaR4cmD0 X-Received: by 10.101.102.79 with SMTP id z15mr7667610pgv.181.1520891716559; Mon, 12 Mar 2018 14:55:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520891716; cv=none; d=google.com; s=arc-20160816; b=LCrHB9mfUrVOeHmgT/EXvftRSIuvwUxEsHPBvLC3zKrzBfcxleJ6X7/NgeSYzDBohk ftMvGYkXfUYOw4KBqkw+4jWTLPLFCZ1JDVfdpUPpxZJF2WhBmvABZ6TsN2dgjJxAodb1 F1Hw56BsG9wjcUbJrnB0FpQPoUUQSbr9bULUjuLM0GcjFZ2XeA8VJ672q7qi5EneTaQZ cCGq+LldeQKTf8NBQJcuC8b6QTIOUkMJekbghisrUZOGIVyLg8fohN8gXEDy2Llhsz9W Jdl+437T4v0bPNESmIZC6/XNMuuYc1BCzRpaXFgFLTiYQsjK9RVx9mUw+SH11agaDEeV ZWsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:content-transfer-encoding :mime-version:references:in-reply-to:date:cc:to:from:subject :arc-authentication-results; bh=Mh0AwYyRY/LRDZJHpC72bX2fbTnvCQ6y0tYsVtO4xj4=; b=zMClyEcgrS4p+53krPvTHJwq5cIQJuQLP7gAskQlHbfyKMRqaZUzHSzTlIyOHwTXXD W7PTmSuamCSR2lcmQpgt/3WH5kEWDRdF8WybPgSuvvaeTT2qbAv2RO/W6onqnFVAWLux fF1ptZpH2RRKtG10IlEHsC5KtiaRXr7S5LrNhAcor8ZP39NlcKWfzi+42KxGQjI7xFPS Yp6peKwlQr1BVXmEpMpP2r8gkaOtFMldVmdWxqM9P4yFx9WvNwm/kwr7JvyGe4FTgsZf BOwqHIp4xSxbYC5SD8cvKXvNiZGawHfVmkWwWZzn/+dUoAj+DBO2a3JgCy6eO6pJhiKo /sBg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 38-v6si768533plc.228.2018.03.12.14.55.02; Mon, 12 Mar 2018 14:55:16 -0700 (PDT) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932495AbeCLVxb (ORCPT + 99 others); Mon, 12 Mar 2018 17:53:31 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:54108 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932265AbeCLVx3 (ORCPT ); Mon, 12 Mar 2018 17:53:29 -0400 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2CLn98m112908 for ; Mon, 12 Mar 2018 17:53:28 -0400 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0b-001b2d01.pphosted.com with ESMTP id 2gnx6y08x2-1 (version=TLSv1.2 cipher=AES256-SHA256 bits=256 verify=NOT) for ; Mon, 12 Mar 2018 17:53:28 -0400 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 12 Mar 2018 21:53:26 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 12 Mar 2018 21:53:21 -0000 Received: from d06av24.portsmouth.uk.ibm.com (mk.ibm.com [9.149.105.60]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w2CLrKYk53411848; Mon, 12 Mar 2018 21:53:20 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8BB7342045; Mon, 12 Mar 2018 21:45:37 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4D4054203F; Mon, 12 Mar 2018 21:45:36 +0000 (GMT) Received: from dhcp-9-2-55-16.watson.ibm.com (unknown [9.2.55.16]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 12 Mar 2018 21:45:36 +0000 (GMT) Subject: Re: [PATCH] security: Fix IMA Kconfig for dependencies on ARM64 From: Mimi Zohar To: James Bottomley , Jiandi An , Jason Gunthorpe Cc: dmitry.kasatkin@gmail.com, jmorris@namei.org, serge@hallyn.com, linux-integrity@vger.kernel.org, linux-ima-devel@lists.sourceforge.net, linux-ima-user@lists.sourceforge.net, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, David Safford Date: Mon, 12 Mar 2018 17:53:18 -0400 In-Reply-To: <1520615461.12216.6.camel@HansenPartnership.com> References: <1520400386-17674-1-git-send-email-anjiandi@codeaurora.org> <20180307185132.GA30102@ziepe.ca> <1520448953.10396.565.camel@linux.vnet.ibm.com> <1520449719.5558.28.camel@HansenPartnership.com> <1520450495.10396.587.camel@linux.vnet.ibm.com> <1520451662.24314.5.camel@HansenPartnership.com> <1520461156.10396.654.camel@linux.vnet.ibm.com> <191cfd49-0c66-a5ef-3d2b-b6c4132aa294@codeaurora.org> <1520615461.12216.6.camel@HansenPartnership.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 18031221-0020-0000-0000-000004028E7F X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18031221-0021-0000-0000-00004296E08E Message-Id: <1520891598.3547.190.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-03-12_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=3 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1803120237 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2018-03-09 at 09:11 -0800, James Bottomley wrote: > On Thu, 2018-03-08 at 12:42 -0600, Jiandi An wrote: > [...] > > I'm no expert on IMA and its driver.  James, will you be kind enough > > to look into overhauling the IMA driver to not measure until after  > > initrd phase if that's the consensus on resolving this? > > I'll add it to my todo list. > > Since my TPM 2.0 test environment is a VM with a tpm that has a network > connection to an emulator on my host, it's impossible to set it up so > that it's built in (because you need the network config before you init > the TPM) so I might accelerate if I suddenly need to debug IMA issues > in this configuration. There are a number of different issues being discussed. - When IMA is enabled, unlike some other TPM device drivers, the TPM 2.0 is not forced to be builtin. This is addressed by Jiandi's patch. - Jason's comment questioning having Kconfig force the TPM to be builtin. Using Kconfig to force the TPM to be builtin is not required, but helpful.  Users interested in IMA-measurement could configure the TPM as builtin themselves.  Without the TPM builtin, IMA goes into TPM- bypass mode. Extending a TPM with IMA measurements, which was not builtin, but loaded at some unspecified point in time, changes the existing meaning of the IMA-measurement list. - This use case, when the TPM is not builtin and unavailable before IMA is initialized. I would classify this use case as an IMA testing/debugging environment, when it cannot, for whatever reason, be builtin the kernel or initialized before IMA. From Dave Safford: For the TCG chain of trust to have any meaning, all files have to be measured and extended into the TPM before they are accessed. If the TPM driver is loaded after any unmeasured file, the chain is broken, and IMA is useless for any use case or any threat model. While the initramfs may be measured by the bootloader, there are two problems: 1. IMA has no way of knowing if the kernel or initramfs has accessed any unmeasured files before TPM driver loading and IMA initialization. 2. Even if we can somehow guarantee that nothing outside the initramfs has been accessed prior to IMA initialization, it is difficult if not impossible for the attestation server to know what a good initramfs measurement should be, as the initramfs is built on the suspect device in the first place.  We can sort of trust the initramfs measurement in the reference manifest, but after that, the attestation server has no way to trust a reported initramfs measurement. Mimi