linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Morse <james.morse@arm.com>
To: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: prsriva <prsriva@linux.microsoft.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-integrity@vger.kernel.org,
	kexec mailing list <kexec@lists.infradead.org>,
	Mark Rutland <mark.rutland@arm.com>,
	jean-philippe@linaro.org, arnd@arndb.de,
	takahiro.akashi@linaro.org, sboyd@kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	zohar@linux.ibm.com,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	duwe@lst.de, bauerman@linux.ibm.com,
	Thomas Gleixner <tglx@linutronix.de>,
	allison@lohutok.net, Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH V4 0/2] Add support for arm64 to carry ima measurement
Date: Fri, 25 Oct 2019 18:08:16 +0100	[thread overview]
Message-ID: <b53ba912-6fec-211d-9494-bc6ae6fa3f31@arm.com> (raw)
In-Reply-To: <CA+CK2bBVcE91YbJx1f_BkNqbD03wGLNtyane7PjCnEu8i_cH2Q@mail.gmail.com>

Hi Pavel,

On 15/10/2019 19:47, Pavel Tatashin wrote:
>> I think the UEFI persistent-memory-reservations thing is a better fit for this [0][1].

> Thank you for your thought. As I understand you propose the to use the
> existing method as such:
> 1. Use the existing kexec ABI to pass reservation from kernel to
> kernel using EFI the same as is done for GICv3 tables.
> 2. Allow this memory to be reservable only during first Linux boot via
> EFI memory reserve
> 3. Allow to have this memory pre-reserved by firmware or to be
> embedded into device tree.
> 
> A question I have is how to tell that a reserved region is reserved
> for IMA use. With GICv3 it is done by reading the registers, finding
> the interrupt tables memory, and check that the memory ranges are
> indeed pre-reserved.

Good point, efi_mem_reserve_persistent() has no way of describing what a region is for,
you have to know that from somewhere else.


> Is there a way to name memory with the current ABI that you think is acceptable?

This would need to go in the chosen node of the DT, like power-pc already does. This would
work on arm64:ACPI systems too (because they have a DT chosen node).


I'd like to understand why removing these entries is needed, it doesn't look like we have
an API call to remove them from the efi mem-reserve...

If it had a fixed position in memory its the sort of thing we'd expect firmware to
reserved during boot. (e.g. ramoops).

~

From ima_add_kexec_buffer() this really is a transient memory reservation over kexec.
I think the efi mem-reserve and a DT-chosen node entry with the PA is the only way to make
this work smoothly between DT<->ACPI systems.

We'd need a way of removing the efi mem-reserve in ima_free_kexec_buffer(), otherwise the
memory remains lost. The DT-chosen node entry should have its pointer zero'd out once
we've done this. (like we do for the KASLR seed).


Not considered is parsing the DT-chosen node entry as if it were a memreserve during early
boot. This wouldn't work if you kexec something that doesn't know what the node is, it
would overwrite the the memory and may not remove the node for the next kexec, which does.


Thanks,

James

  parent reply	other threads:[~2019-10-25 17:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-11  0:35 [PATCH V4 0/2] Add support for arm64 to carry ima measurement Prakhar Srivastava
2019-10-11  0:35 ` [PATCH V4 1/2] Add support for arm64 to carry ima measurement log in kexec_file_load Prakhar Srivastava
2019-10-11  0:36 ` [PATCH V4 2/2] update powerpc implementation to call into of_ima* Prakhar Srivastava
2019-10-14 18:02 ` [PATCH V4 0/2] Add support for arm64 to carry ima measurement James Morse
2019-10-15  1:31   ` prsriva
2019-10-15 17:39     ` James Morse
2019-10-15 18:47       ` Pavel Tatashin
2019-10-21 17:38         ` prsriva
2019-10-25 17:08         ` James Morse [this message]
2019-10-15 22:15       ` James Morris
2019-10-16  1:44       ` Mimi Zohar
2019-10-25 17:07         ` James Morse
2019-10-25 17:39           ` Mimi Zohar

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=b53ba912-6fec-211d-9494-bc6ae6fa3f31@arm.com \
    --to=james.morse@arm.com \
    --cc=allison@lohutok.net \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=bauerman@linux.ibm.com \
    --cc=catalin.marinas@arm.com \
    --cc=duwe@lst.de \
    --cc=jean-philippe@linaro.org \
    --cc=kexec@lists.infradead.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=pasha.tatashin@soleen.com \
    --cc=prsriva@linux.microsoft.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).