Devicetree
 help / color / mirror / Atom feed
From: Thiago Jung Bauermann <bauerman@linux.ibm.com>
To: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>,
	robh@kernel.org, gregkh@linuxfoundation.org, james.morse@arm.com,
	catalin.marinas@arm.com, sashal@kernel.org, will@kernel.org,
	mpe@ellerman.id.au, benh@kernel.crashing.org, paulus@samba.org,
	robh+dt@kernel.org, frowand.list@gmail.com,
	vincenzo.frascino@arm.com, mark.rutland@arm.com,
	dmitry.kasatkin@gmail.com, jmorris@namei.org, serge@hallyn.com,
	pasha.tatashin@soleen.com, allison@lohutok.net,
	kstewart@linuxfoundation.org, takahiro.akashi@linaro.org,
	tglx@linutronix.de, masahiroy@kernel.org, bhsharma@redhat.com,
	mbrugger@suse.com, hsinyi@chromium.org, tao.li@vivo.com,
	christophe.leroy@c-s.fr, linux-integrity@vger.kernel.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	prsriva@linux.microsoft.com, balajib@linux.microsoft.com
Subject: Re: [PATCH v7 1/4] powerpc: Refactor kexec functions to move arch independent code to kernel
Date: Fri, 23 Oct 2020 00:46:58 -0300	[thread overview]
Message-ID: <87v9f1eh8t.fsf@morokweng.localdomain> (raw)
In-Reply-To: <af13db86-09c1-db12-330e-57e24bd07b9a@linux.microsoft.com>


Hello Lakshmi,

Lakshmi Ramasubramanian <nramas@linux.microsoft.com> writes:

> On 10/20/20 8:17 PM, Mimi Zohar wrote:
>> On Tue, 2020-10-20 at 19:25 -0700, Lakshmi Ramasubramanian wrote:
>>> On 10/20/20 1:00 PM, Mimi Zohar wrote:
>>>> Hi Lakshmi,
>>>>
>>>> On Wed, 2020-09-30 at 13:59 -0700, Lakshmi Ramasubramanian wrote:
>>>>> The functions remove_ima_buffer() and delete_fdt_mem_rsv() that handle
>>>>> carrying forward the IMA measurement logs on kexec for powerpc do not
>>>>> have architecture specific code, but they are currently defined for
>>>>> powerpc only.
>>>>>
>>>>> remove_ima_buffer() and delete_fdt_mem_rsv() are used to remove
>>>>> the IMA log entry from the device tree and free the memory reserved
>>>>> for the log. These functions need to be defined even if the current
>>>>> kernel does not support carrying forward IMA log across kexec since
>>>>> the previous kernel could have supported that and therefore the current
>>>>> kernel needs to free the allocation.
>>>>>
>>>>> Rename remove_ima_buffer() to remove_ima_kexec_buffer().
>>>>> Define remove_ima_kexec_buffer() and delete_fdt_mem_rsv() in kernel.
>>>>> A later patch in this series will use these functions to free
>>>>> the allocation, if any, made by the previous kernel for ARM64.
>>>>>
>>>>> Define FDT_PROP_IMA_KEXEC_BUFFER for the chosen node, namely
>>>>> "linux,ima-kexec-buffer", that is added to the DTB to hold
>>>>> the address and the size of the memory reserved to carry
>>>>> the IMA measurement log.
>>>>
>>>>> Co-developed-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
>>>>> Signed-off-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
>>>>> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
>>>>> Reported-by: kernel test robot <lkp@intel.com> error: implicit declaration of function 'delete_fdt_mem_rsv' [-Werror,-Wimplicit-function-declaration]
>>>>
>>>> Much better!  This version limits unnecessarily changing the existing
>>>> code to adding a couple of debugging statements, but that looks to be
>>>> about it.
>>> Yes Mimi - that's correct.
>>>
>>>>
>>>> Based on Chester Lin's "ima_arch" support for arm64 discussion, the IMA generic
>>>> EFI support will be defined in ima/ima-efi.c.  Similarly, I think it would make sense to put the generic device tree support in ima/ima_kexec_fdt.c or ima/ima_fdt.c, as opposed to kernel/.  (Refer to my comments on 2/4 about the new file named ima_kexec_fdt.c.)
>>>
>>> The functions remove_ima_kexec_buffer() and delete_fdt_mem_rsv(), which
>>> are defined in kernel/ima_kexec.c and kernel/kexec_file_fdt.c
>>> respectively, are needed even when CONFIG_IMA is not defined. These
>>> functions need to be called by the current kernel to free the ima kexec
>>> buffer resources allocated by the previous kernel. This is the reason,
>>> these functions are defined under "kernel" instead of
>>> "security/integrity/ima".
>>>
>>> If there is a better location to move the above C files, please let me
>>> know. I'll move them.
>> Freeing the previous kernel measurement list is currently called from
>> ima_load_kexec_buffer(), only after the measurement list has been
>> restored.  The only other time the memory is freed is when the
>> allocated memory size isn't sufficient to hold the measurement list,
>> which could happen if there is a delay between loading and executing
>> the kexec.
>> 
>
> There are two "free" operations we need to perform with respect to ima buffer on
> kexec:
>
> 1, The ima_free_kexec_buffer() called from ima_load_kexec_buffer() - the one you
> have stated above.
>
> Here we remove the "ima buffer" node from the "OF" tree and free the memory
> pages that were allocated for the measurement list.
>
> This one is already present in ima and there's no change in that in my patches.
>
> 2, The other one is remove_ima_kexec_buffer() called from setup_ima_buffer()
> defined in "arch/powerpc/kexec/ima.c"
>
>  This function removes the "ima buffer" node from the "FDT" and also frees the
> physical memory reserved for the "ima measurement list" by the previous kernel.
>
>  This "free" operation needs to be performed even if the current kernel does not
> support IMA kexec since the previous kernel could have passed the IMA
> measurement list (in FDT and reserved physical memory).
>
> For this reason, remove_ima_kexec_buffer() cannot be defined in "ima" but some
> other place which will be built even if ima is not enabled. I chose to define
> this function in "kernel" since that is guaranteed to be always built.
>
> thanks,
>  -lakshmi

That is true. I believe a more fitting place for these functions is
drivers/of/fdt.c rather than these new files in kernel/. Both CONFIG_PPC
and CONFIG_ARM64 select CONFIG_OF and CONFIG_OF_FLATTREE (indirectly,
via CONFIG_OF_EARLY_FLATTREE) so they will both build that file.

-- 
Thiago Jung Bauermann
IBM Linux Technology Center

  reply	other threads:[~2020-10-23  3:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-30 20:59 [PATCH v7 0/3] Carry forward IMA measurement log on kexec on ARM64 Lakshmi Ramasubramanian
2020-09-30 20:59 ` [PATCH v7 1/4] powerpc: Refactor kexec functions to move arch independent code to kernel Lakshmi Ramasubramanian
2020-10-20 20:00   ` Mimi Zohar
2020-10-21  2:25     ` Lakshmi Ramasubramanian
2020-10-21  3:17       ` Mimi Zohar
2020-10-21 16:58         ` Lakshmi Ramasubramanian
2020-10-23  3:46           ` Thiago Jung Bauermann [this message]
2020-10-26 18:36             ` Lakshmi Ramasubramanian
2020-09-30 20:59 ` [PATCH v7 2/4] powerpc: Refactor kexec functions to move arch independent code to ima Lakshmi Ramasubramanian
2020-10-20 20:01   ` Mimi Zohar
2020-10-21  2:38     ` Lakshmi Ramasubramanian
2020-10-21  3:50       ` Mimi Zohar
2020-10-21 16:20         ` Lakshmi Ramasubramanian
2020-09-30 20:59 ` [PATCH v7 3/4] arm64: Store IMA log information in kimage used for kexec Lakshmi Ramasubramanian
2020-09-30 20:59 ` [PATCH v7 4/4] arm64: Add IMA kexec buffer to DTB Lakshmi Ramasubramanian

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=87v9f1eh8t.fsf@morokweng.localdomain \
    --to=bauerman@linux.ibm.com \
    --cc=allison@lohutok.net \
    --cc=balajib@linux.microsoft.com \
    --cc=benh@kernel.crashing.org \
    --cc=bhsharma@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=christophe.leroy@c-s.fr \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hsinyi@chromium.org \
    --cc=james.morse@arm.com \
    --cc=jmorris@namei.org \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=masahiroy@kernel.org \
    --cc=mbrugger@suse.com \
    --cc=mpe@ellerman.id.au \
    --cc=nramas@linux.microsoft.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=paulus@samba.org \
    --cc=prsriva@linux.microsoft.com \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=sashal@kernel.org \
    --cc=serge@hallyn.com \
    --cc=takahiro.akashi@linaro.org \
    --cc=tao.li@vivo.com \
    --cc=tglx@linutronix.de \
    --cc=vincenzo.frascino@arm.com \
    --cc=will@kernel.org \
    --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