Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp1767651ybn; Thu, 26 Sep 2019 01:48:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqziyhfb9AooLsVShh8fLQBVA8YhJKVqDMr+Pr3FL7/X1Dsp7hhF+Avftm0V/m0NbhoQ4/xA X-Received: by 2002:a50:8933:: with SMTP id e48mr2266893ede.51.1569487685066; Thu, 26 Sep 2019 01:48:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569487685; cv=none; d=google.com; s=arc-20160816; b=mNNhGKooX2JFIgPaPejoDv6MtcZ3dPeW7J4znmB2FCDr2vvZORtgFT1XMzEsHTx4u5 svu4H/K9t2ssZKF5k3ZxPCc4TKFDhjdASVI3S77k2OZSrLcA+iXSWtL7ZFwYfd9LHCaz 4iRrXKUHhCbzRTZkdcQucuAdUkojp9X8VVMrBImrPmjo4HBkydFkVvACo47EahcDZOqa s5kzcV/qKlTLeDhKwczlOSCFGUkRpzxQa7q8INW5rgXsCJYlgsxK7ejwRXi+697qlhkw GypCUGx1wGxvupbMLws+cpyf+sVij9BRZY7xSsKh4CcjoQv7uyhIVzQpnDd44rWavPVh WO4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=jIYaPbRP5QjengI0MPJklmWjP0qC9NfEbqBldn7nW4E=; b=bKeMRrJyJPte2P9LAipkuvpHYAuexUH/td0NcvzNk8lFlH43QBNN21r3HL7f286H2Z I7gmGfgwUyRpm7Yae/zkeWAmZYjf29uMVfPnaHOkxIRSTvvf02y+1RjwsEIrzNGELVw3 s6KVjDqYDGTsk9uAYua1ayJPl933G2DjuGrSiXk4cbohMJlYNQ+hyqB7YTQTiDM4nhJo bMLxhjnBzAvXWQ8xsN2T+DO3cimtCRZ+3tty4A69yM9HJKXyuDL/47r2WfT+btDq09UR GJbXTcGOc+FIqQSmCJY5v4TK8r1V18ptqQmLn/zrqh55MqJXnoU9FRkubz6xZzY8Jl/h 97/g== 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=linux.microsoft.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i22si630695ejr.267.2019.09.26.01.47.41; Thu, 26 Sep 2019 01:48:05 -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=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2410485AbfIXU1I (ORCPT + 99 others); Tue, 24 Sep 2019 16:27:08 -0400 Received: from linux.microsoft.com ([13.77.154.182]:58042 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726156AbfIXU1I (ORCPT ); Tue, 24 Sep 2019 16:27:08 -0400 Received: from [10.200.156.146] (unknown [167.220.2.18]) by linux.microsoft.com (Postfix) with ESMTPSA id 0EEC620BBF87; Tue, 24 Sep 2019 13:27:07 -0700 (PDT) Subject: Re: [RFC PATCH v1 1/1] Add support for arm64 to carry ima measurement log in kexec_file_load To: Thiago Jung Bauermann Cc: mark.rutland@arm.com, jean-philippe@linaro.org, arnd@arndb.de, takahiro.akashi@linaro.org, sboyd@kernel.org, catalin.marinas@arm.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, zohar@linux.ibm.com, yamada.masahiro@socionext.com, kristina.martsenko@arm.org, duwe@lst.de, allison@lohutok.net, james.morse@arm.org, linux-integrity@vger.kernel.org, tglx@linutronix.de, linux-arm-kernel@lists.infradead.org References: <20190913225009.3406-1-prsriva@linux.microsoft.com> <20190913225009.3406-2-prsriva@linux.microsoft.com> <87zhiz1x9l.fsf@morokweng.localdomain> From: prsriva Message-ID: Date: Tue, 24 Sep 2019 13:27:06 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <87zhiz1x9l.fsf@morokweng.localdomain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/19/19 8:07 PM, Thiago Jung Bauermann wrote: > > Hello Prakhar, > > Prakhar Srivastava writes: > >> During kexec_file_load, carrying forward the ima measurement log allows >> a verifying party to get the entire runtime event log since the last >> full reboot since that is when PCRs were last reset. > In the previous patch, you took the powerpc file and made a few > modifications to fit your needs. This file is now somewhat different > than the powerpc version, but I don't understand to what purpose. It's > not different in any significant way. > > Based on review comments from your previous patch, I was expecting to > see code from the powerpc file moved to an arch-independent part of the > the kernel and possibly adapted so that both arm64 and powerpc could use > it. Can you explain why you chose this approach instead? What is the > advantage of having superficially different but basically equivalent > code in the two architectures? > > Actually, there's one change that is significant: instead of a single > linux,ima-kexec-buffer property holding the start address and size of > the buffer, ARM64 is now using two properties (linux,ima-kexec-buffer > and linux,ima-kexec-buffer-end) for the start and end addresses. In my > opinion, unless there's a good reason for it Linux should be consistent > accross architectures when possible. > > -- > Thiago Jung Bauermann > IBM Linux Technology Center I looked at the of_ drivers are it became apparent that the driver calls were already available for consumption. Adding ima specific code will be same as adding wrapper code for any other property. Which is true for all properties, effectively setting the property name and pass through for other parameters. I still like to move both implementations to a arch independent code path, i could not convince my self that of_*ima is probably the place, but if that's the best place?, then i will go ahead and make that change as well. Regarding using two properties, it just seemed more consistent how the properties(start-end) are being used in the kexec, and hides the inner details for the cell structures, thats all. Its just the placement of the wrapper functions, but once thats done both archs will call the same. Thanks, Prakhar Srivastava > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >