Linux-Integrity Archive on lore.kernel.org
 help / color / Atom feed
From: James Morse <james.morse@arm.com>
To: Prakhar Srivastava <prsriva@linux.microsoft.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-integrity@vger.kernel.org, kexec@lists.infradead.org,
	mark.rutland@arm.com, jean-philippe@linaro.org, arnd@arndb.de,
	takahiro.akashi@linaro.org, sboyd@kernel.org,
	catalin.marinas@arm.com, zohar@linux.ibm.com,
	yamada.masahiro@socionext.com, kristina.martsenko@arm.org,
	duwe@lst.de, bauerman@linux.ibm.com, james.morse@arm.org,
	tglx@linutronix.de, allison@lohutok.net
Subject: Re: [PATCH V4 0/2] Add support for arm64 to carry ima measurement
Date: Mon, 14 Oct 2019 19:02:28 +0100
Message-ID: <87d92514-e5e4-a79f-467f-f24a4ed279b6@arm.com> (raw)
In-Reply-To: <20191011003600.22090-1-prsriva@linux.microsoft.com>

Hi Prakhar,

(You've CC'd a few folk who work for 'arm.org'...)

On 11/10/2019 01:35, Prakhar Srivastava wrote:
> Add support to carry ima measurement log
> to the next kexec'ed session triggered via kexec_file_load.

I don't know much about 'ima', I'm assuming its the list of 'stuff' that has already been
fed into the TPM as part of SecureBoot. Please forgive the stupid questions,


> Currently during kexec the kernel file signatures are/can be validated
> prior to actual load, the information(PE/ima signature) is not carried
> to the next session. This lead to loss of information.
> 
> Carrying forward the ima measurement log to the next kexec'ed session 
> allows a verifying party to get the entire runtime event log since the
> last full reboot, since that is when PCRs were last reset.

Hmm, You're adding this as a linux-specific thing in the chosen node, which points at a
memreserve.

The question that normally needs answering when adding to the stuff we have to treat as
ABI over kexec is: how would this work from a bootloader that isn't kexec? Does it need to
work for non-linux OS?

Changing anything other than the chosen node of the DT isn't something the kernel should
be doing. I suspect if you need reserved memory for this stuff, it should be carved out by
the bootloader, and like all other memreserves: should not be moved or deleted.

('fdt_delete_mem_rsv()' is a terrifying idea, we depend on the memreserve nodes to tell
use which 'memory' we shouldn't touch!)


Sharing with powerpc is a great starting point ... but, how does this work for ACPI systems?
How does this work if I keep kexecing between ACPI and DT?

I'd prefer it we only had one way this works on arm64, so whatever we do has to cover both.

Does ima work without UEFI secure-boot?
If not, the Linux-specific UEFI 'memreserve' table might be a better fit, this would be
the same for both DT and ACPI systems. Given U-boot supports the UEFI API too, its
probably the right thing to do regardless of secure-boot.

It looks like x86 doesn't support this either yet. If we have to add something to support
ACPI, it would be good if it covers both firmware mechanisms for arm64, and works for x86
in the same way.

(How does this thing interact with EFI's existing efi_tpm_eventlog_init()?)


Thanks,

James

  parent reply index

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-11  0:35 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 ` James Morse [this message]
2019-10-15  1:31   ` [PATCH V4 0/2] Add support for arm64 to carry ima measurement 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
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 publically 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=87d92514-e5e4-a79f-467f-f24a4ed279b6@arm.com \
    --to=james.morse@arm.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=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

Linux-Integrity Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-integrity/0 linux-integrity/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-integrity linux-integrity/ https://lore.kernel.org/linux-integrity \
		linux-integrity@vger.kernel.org
	public-inbox-index linux-integrity

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-integrity


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git