linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: prsriva <prsriva@linux.microsoft.com>
To: Thiago Jung Bauermann <bauerman@linux.ibm.com>
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
Subject: Re: [RFC PATCH v1 1/1] Add support for arm64 to carry ima measurement log in kexec_file_load
Date: Tue, 24 Sep 2019 13:27:06 -0700	[thread overview]
Message-ID: <baf74901-a594-c15d-b93f-f7d0a8c584b8@linux.microsoft.com> (raw)
In-Reply-To: <87zhiz1x9l.fsf@morokweng.localdomain>



On 9/19/19 8:07 PM, Thiago Jung Bauermann wrote:
> 
> Hello Prakhar,
> 
> Prakhar Srivastava <prsriva@linux.microsoft.com> 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.

<snip>

> 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
> 

      parent reply	other threads:[~2019-09-24 20:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-13 22:50 [RFC PATCH v1 0/1] Add support for arm64 to carry ima measurement log in kexec_file_load Prakhar Srivastava
2019-09-13 22:50 ` [RFC PATCH v1 1/1] " Prakhar Srivastava
2019-09-18 14:15   ` Mimi Zohar
2019-09-18 21:21     ` Mimi Zohar
2019-09-19  3:59       ` Thiago Jung Bauermann
2019-09-20  0:32         ` Prakhar Srivastava
2019-09-20  3:07   ` Thiago Jung Bauermann
2019-09-24 19:54     ` prsriva
2019-09-24 20:25       ` Thiago Jung Bauermann
2019-09-24 20:27     ` prsriva [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=baf74901-a594-c15d-b93f-f7d0a8c584b8@linux.microsoft.com \
    --to=prsriva@linux.microsoft.com \
    --cc=allison@lohutok.net \
    --cc=arnd@arndb.de \
    --cc=bauerman@linux.ibm.com \
    --cc=catalin.marinas@arm.com \
    --cc=duwe@lst.de \
    --cc=james.morse@arm.org \
    --cc=jean-philippe@linaro.org \
    --cc=kexec@lists.infradead.org \
    --cc=kristina.martsenko@arm.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=sboyd@kernel.org \
    --cc=takahiro.akashi@linaro.org \
    --cc=tglx@linutronix.de \
    --cc=yamada.masahiro@socionext.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).