All of lore.kernel.org
 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: 17+ 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-01  1:21   ` kernel test robot
2020-10-01  9:08   ` kernel test robot
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.