From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752489AbcFWXtT (ORCPT ); Thu, 23 Jun 2016 19:49:19 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:34150 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752451AbcFWXtR (ORCPT ); Thu, 23 Jun 2016 19:49:17 -0400 X-IBM-Helo: d24dlp01.br.ibm.com X-IBM-MailFrom: bauerman@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org From: Thiago Jung Bauermann To: Balbir Singh Cc: linuxppc-dev@lists.ozlabs.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC Date: Thu, 23 Jun 2016 20:49:10 -0300 User-Agent: KMail/4.14.3 (Linux/3.13.0-87-generic; KDE/4.14.13; x86_64; ; ) In-Reply-To: <576C63B4.8060302@gmail.com> References: <1466538521-31216-1-git-send-email-bauerman@linux.vnet.ibm.com> <1612090.Qxo4UiJulB@hactar> <576C63B4.8060302@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16062323-0032-0000-0000-0000025CF497 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16062323-0033-0000-0000-00000E8F7ADC Message-Id: <1489849.szMRu2Hvtq@hactar> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-06-23_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606230252 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Freitag, 24 Juni 2016, 08:33:24 schrieb Balbir Singh: > On 24/06/16 02:44, Thiago Jung Bauermann wrote: > > Sorry, I still don't understand your concern. What kind of cheating? > > Which values? If it's the values in the event log, there's no need to > > trust the old kernel. The new kernel knows that the old kernel didn't > > pass wrong measurement values in the event log because it can > > recalculate the PCR extend operations recorded in the log and compare > > the results of the replay with the current PCR values stored in the TPM > > device. If they match, then the event log is guaranteed to be correct. > > If they don't match, either the memory was corrupted somehow during the > > kexec process, or the old kernel tried to pass a falsified event log. > > Yep, get it/got it. My concern was anything using passed on the values > should compare the results with the current PCR values. > > BTW, what do we gain by passing the values if we are relying on the PCR > registers anyway, can't we directly read them off from there? Aren't we > going to ready anyway to compare, what does passing the values gain? The PCR values themselves change for reasons that the application/user may not care about. For example, just changing the order in which measurements are made changes the final value of the PCR, even if all the measurements themselves don't change. And in current multi-processor machines this order does change at each boot, so you can't rely on two boots of the same machine with the same software to have the same PCR values. Also, you may want to verify only the measurement of one of the components and not care about the other components. With an event log, you can verify the checksum of each measured component individually, and the PCR value serves to confirm that the event log is correct. Just having the final PCR value without the event log, you don't know which measurements were made. > >> and > >> > >> How do we know the new kernel is safe to load - I guess via a signature > >> that the new kernel is signed with (assuming it is present in the key > >> ring). > > > > Correct. That goal is met by signature verification, not by integrity > > assurance. > > > > I'll note that even with both of my patch series there's still code > > missing for kernel signature verification in PowerPC. I believe there's > > not a file format defined yet for how to store a signature in a PowerPC > > kernel image. > > > > Integrity assurance doesn't depend on kernel signature verification > > though. There's value in both my patch series even without kernel > > signature verification support. They're complementary features. > > Thanks for clarifying Thank you for your interest. -- []'s Thiago Jung Bauermann IBM Linux Technology Center From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5] helo=mx0a-001b2d01.pphosted.com) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1bGENO-0001yX-Tq for kexec@lists.infradead.org; Thu, 23 Jun 2016 23:49:39 +0000 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u5NNnGAV122236 for ; Thu, 23 Jun 2016 19:49:16 -0400 Received: from e24smtp04.br.ibm.com (e24smtp04.br.ibm.com [32.104.18.25]) by mx0b-001b2d01.pphosted.com with ESMTP id 23ra2mtt6t-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 23 Jun 2016 19:49:16 -0400 Received: from localhost by e24smtp04.br.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 23 Jun 2016 20:49:14 -0300 Received: from d24relay02.br.ibm.com (d24relay02.br.ibm.com [9.13.184.26]) by d24dlp02.br.ibm.com (Postfix) with ESMTP id EC59C1DC006D for ; Thu, 23 Jun 2016 19:49:04 -0400 (EDT) Received: from d24av04.br.ibm.com (d24av04.br.ibm.com [9.8.31.97]) by d24relay02.br.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u5NNnCfC26935628 for ; Thu, 23 Jun 2016 20:49:12 -0300 Received: from d24av04.br.ibm.com (localhost [127.0.0.1]) by d24av04.br.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u5NNnBV8023503 for ; Thu, 23 Jun 2016 20:49:12 -0300 From: Thiago Jung Bauermann Subject: Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC Date: Thu, 23 Jun 2016 20:49:10 -0300 In-Reply-To: <576C63B4.8060302@gmail.com> References: <1466538521-31216-1-git-send-email-bauerman@linux.vnet.ibm.com> <1612090.Qxo4UiJulB@hactar> <576C63B4.8060302@gmail.com> MIME-Version: 1.0 Message-Id: <1489849.szMRu2Hvtq@hactar> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Balbir Singh Cc: kexec@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Am Freitag, 24 Juni 2016, 08:33:24 schrieb Balbir Singh: > On 24/06/16 02:44, Thiago Jung Bauermann wrote: > > Sorry, I still don't understand your concern. What kind of cheating? > > Which values? If it's the values in the event log, there's no need to > > trust the old kernel. The new kernel knows that the old kernel didn't > > pass wrong measurement values in the event log because it can > > recalculate the PCR extend operations recorded in the log and compare > > the results of the replay with the current PCR values stored in the TPM > > device. If they match, then the event log is guaranteed to be correct. > > If they don't match, either the memory was corrupted somehow during the > > kexec process, or the old kernel tried to pass a falsified event log. > > Yep, get it/got it. My concern was anything using passed on the values > should compare the results with the current PCR values. > > BTW, what do we gain by passing the values if we are relying on the PCR > registers anyway, can't we directly read them off from there? Aren't we > going to ready anyway to compare, what does passing the values gain? The PCR values themselves change for reasons that the application/user may not care about. For example, just changing the order in which measurements are made changes the final value of the PCR, even if all the measurements themselves don't change. And in current multi-processor machines this order does change at each boot, so you can't rely on two boots of the same machine with the same software to have the same PCR values. Also, you may want to verify only the measurement of one of the components and not care about the other components. With an event log, you can verify the checksum of each measured component individually, and the PCR value serves to confirm that the event log is correct. Just having the final PCR value without the event log, you don't know which measurements were made. > >> and > >> > >> How do we know the new kernel is safe to load - I guess via a signature > >> that the new kernel is signed with (assuming it is present in the key > >> ring). > > > > Correct. That goal is met by signature verification, not by integrity > > assurance. > > > > I'll note that even with both of my patch series there's still code > > missing for kernel signature verification in PowerPC. I believe there's > > not a file format defined yet for how to store a signature in a PowerPC > > kernel image. > > > > Integrity assurance doesn't depend on kernel signature verification > > though. There's value in both my patch series even without kernel > > signature verification support. They're complementary features. > > Thanks for clarifying Thank you for your interest. -- []'s Thiago Jung Bauermann IBM Linux Technology Center _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec