linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Ross Philipson <ross.philipson@oracle.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	linux-integrity@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-crypto@vger.kernel.org, iommu@lists.linux-foundation.org,
	kexec@lists.infradead.org, linux-efi@vger.kernel.org
Cc: ross.philipson@oracle.com, dpsmith@apertussolutions.com,
	mingo@redhat.com, bp@alien8.de, hpa@zytor.com, ardb@kernel.org,
	mjg59@srcf.ucam.org, James.Bottomley@hansenpartnership.com,
	luto@amacapital.net, nivedita@alum.mit.edu,
	kanth.ghatraju@oracle.com, trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v6 08/14] x86: Secure Launch kernel late boot stub
Date: Fri, 12 May 2023 17:44:00 +0200	[thread overview]
Message-ID: <87jzxdblmn.ffs@tglx> (raw)
In-Reply-To: <20230504145023.835096-9-ross.philipson@oracle.com>

On Thu, May 04 2023 at 14:50, Ross Philipson wrote:
> The routine slaunch_setup is called out of the x86 specific setup_arch

Can you please make functions visible in changelogs by appending (),
i.e. setup_arch() ?

See https://www.kernel.org/doc/html/latest/process/maintainer-tip.html
for further hints.

> +static u32 sl_flags;
> +static struct sl_ap_wake_info ap_wake_info;
> +static u64 evtlog_addr;
> +static u32 evtlog_size;
> +static u64 vtd_pmr_lo_size;

Is any of this modifyable after boot? If not then this wants to be
annotated with __ro_after_init.

> +/* This should be plenty of room */
> +static u8 txt_dmar[PAGE_SIZE] __aligned(16);
> +
> +u32 slaunch_get_flags(void)
> +{
> +	return sl_flags;
> +}
> +EXPORT_SYMBOL(slaunch_get_flags);

What needs this export? If there is a reason then please EXPORT_SYMBOL_GPL()

> +struct sl_ap_wake_info *slaunch_get_ap_wake_info(void)
> +{
> +	return &ap_wake_info;
> +}

If you return a pointer, then there is not much of point for encapsulating.

> +struct acpi_table_header *slaunch_get_dmar_table(struct acpi_table_header *dmar)

Some explanation on public visible functions would be really useful.

> +{
> +	/* The DMAR is only stashed and provided via TXT on Intel systems */

-ENOPARSE.

> +	if (memcmp(txt_dmar, "DMAR", 4))
> +		return dmar;
> +
> +	return (struct acpi_table_header *)(&txt_dmar[0]);

s/&txt_dmar[0]/txt_dmar/ No?

> +}

> +void __noreturn slaunch_txt_reset(void __iomem *txt,
> +				  const char *msg, u64 error)

Please avoid these line breaks. We lifted the 80 character limit quite
some time ago.

> +
> +	/* Iterate over heap tables looking for table of "type" */
> +	for (i = 0; i < type; i++) {
> +		base += offset;
> +		heap = early_memremap(base, sizeof(u64));
> +		if (!heap)
> +			slaunch_txt_reset(txt,
> +				"Error early_memremap of heap for heap walk\n",
> +				SL_ERROR_HEAP_MAP);

This is horrible to read.

		if (!heap) {
			slaunch_txt_reset(txt, "Error early_memremap of heap for heap walk\n",
                        		  SL_ERROR_HEAP_MAP);
                }

See documentation about bracket rules.

> +
> +/*
> + * TXT stashes a safe copy of the DMAR ACPI table to prevent tampering.
> + * It is stored in the TXT heap. Fetch it from there and make it available
> + * to the IOMMU driver.
> + */
> +static void __init slaunch_copy_dmar_table(void __iomem *txt)
> +{
> +	struct txt_sinit_mle_data *sinit_mle_data;
> +	u32 field_offset, dmar_size, dmar_offset;
> +	void *dmar;
> +
> +	memset(&txt_dmar, 0, PAGE_SIZE);

txt_dmar is statically allocated so it's already zero, no?

> +/*
> + * Intel TXT specific late stub setup and validation.
> + */
> +void __init slaunch_setup_txt(void)
> +{
> +	u64 one = TXT_REGVALUE_ONE, val;
> +	void __iomem *txt;
> +
> +	if (!boot_cpu_has(X86_FEATURE_SMX))
> +		return;
> +
> +	/*
> +	 * If booted through secure launch entry point, the loadflags
> +	 * option will be set.
> +	 */
> +	if (!(boot_params.hdr.loadflags & SLAUNCH_FLAG))
> +		return;
> +
> +	/*
> +	 * See if SENTER was done by reading the status register in the
> +	 * public space. If the public register space cannot be read, TXT may
> +	 * be disabled.
> +	 */
> +	txt = early_ioremap(TXT_PUB_CONFIG_REGS_BASE,
> +			    TXT_NR_CONFIG_PAGES * PAGE_SIZE);
> +	if (!txt)
> +		return;

Wait. You have established above that SMX is available and the boot has
set the SLAUNCH flag.

So if that ioremap() fails then there is an issue with the fixmaps.

How is returning here sensible? The system will just die later on in the
worst case with some undecodable issue.

Thanks,

        tglx

  parent reply	other threads:[~2023-05-12 15:44 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-04 14:50 [PATCH v6 00/14] x86: Trenchboot secure dynamic launch Linux kernel support Ross Philipson
2023-05-04 14:50 ` [PATCH v6 01/14] x86/boot: Place kernel_info at a fixed offset Ross Philipson
2023-05-04 14:50 ` [PATCH v6 02/14] Documentation/x86: Secure Launch kernel documentation Ross Philipson
2023-05-05 16:19   ` Simon Horman
2023-05-05 17:32     ` Ross Philipson
2023-05-06  8:48   ` Bagas Sanjaya
2023-05-10 15:41     ` Ross Philipson
2023-05-12 10:47   ` Matthew Garrett
2023-06-16 16:44     ` Daniel P. Smith
2023-06-16 16:54       ` Matthew Garrett
2023-06-16 18:21         ` Daniel P. Smith
2023-05-12 13:19   ` Thomas Gleixner
2023-05-04 14:50 ` [PATCH v6 03/14] x86: Secure Launch Kconfig Ross Philipson
2023-05-04 14:50 ` [PATCH v6 04/14] x86: Secure Launch Resource Table header file Ross Philipson
2023-05-05 16:22   ` Simon Horman
2023-05-05 17:34     ` Ross Philipson
2023-05-10 23:04   ` Jarkko Sakkinen
2023-05-15 20:58     ` Daniel P. Smith
2023-05-12 10:55   ` Matthew Garrett
2023-05-15 21:15     ` Daniel P. Smith
2023-05-15 21:22       ` Matthew Garrett
2023-05-16  0:41         ` Daniel P. Smith
2023-05-16  1:43           ` Matthew Garrett
2023-06-16 20:01             ` Daniel P. Smith
2023-06-16 20:15               ` Matthew Garrett
2023-07-07 19:31                 ` Daniel P. Smith
2023-05-04 14:50 ` [PATCH v6 05/14] x86: Secure Launch main " Ross Philipson
2023-05-05 16:25   ` Simon Horman
2023-05-05 17:37     ` Ross Philipson
2023-05-12 11:00   ` Matthew Garrett
2023-05-12 16:10     ` Ross Philipson
2023-10-31 21:37       ` ross.philipson
2023-05-04 14:50 ` [PATCH v6 06/14] x86: Add early SHA support for Secure Launch early measurements Ross Philipson
2023-05-05 16:34   ` Simon Horman
2023-05-09 16:09     ` Daniel P. Smith
2023-05-10  1:21   ` Eric Biggers
2023-05-10 22:28     ` Jarkko Sakkinen
2023-05-12 11:04     ` Matthew Garrett
2023-05-12 11:18       ` Ard Biesheuvel
2023-05-12 11:28         ` Matthew Garrett
2023-05-12 11:58           ` Ard Biesheuvel
2023-05-12 12:24             ` Andrew Cooper
2023-05-14 18:18               ` Eric Biggers
2023-05-14 19:11                 ` Matthew Garrett
2023-05-12 13:24           ` Thomas Gleixner
2023-05-12 16:13             ` Matthew Garrett
2023-05-12 18:17               ` Thomas Gleixner
2023-05-12 19:12                 ` Matthew Garrett
2023-05-12 19:42                   ` Andrew Cooper
2023-05-15 21:23     ` Daniel P. Smith
2023-05-11  3:33   ` Herbert Xu
2023-05-16  0:50     ` Daniel P. Smith
2023-05-04 14:50 ` [PATCH v6 07/14] x86: Secure Launch kernel early boot stub Ross Philipson
2023-05-05 17:47   ` Simon Horman
2023-05-05 18:58     ` Ross Philipson
2023-05-05 19:46       ` Simon Horman
2023-05-12 11:26   ` Matthew Garrett
2023-05-12 16:17     ` Ross Philipson
2023-05-12 16:27       ` Matthew Garrett
2023-05-16  1:11       ` Daniel P. Smith
2023-05-16  1:45         ` Matthew Garrett
2023-06-15 18:00           ` Ross Philipson
2023-05-12 18:04   ` Thomas Gleixner
2023-05-15 20:13     ` Ross Philipson
2023-09-20 21:40     ` ross.philipson
2023-05-04 14:50 ` [PATCH v6 08/14] x86: Secure Launch kernel late " Ross Philipson
2023-05-05 17:52   ` Simon Horman
2023-05-05 18:59     ` Ross Philipson
2023-05-10 23:02   ` Jarkko Sakkinen
2023-05-12 15:58     ` Ross Philipson
2023-05-24  2:55       ` Jarkko Sakkinen
2023-05-12 15:44   ` Thomas Gleixner [this message]
2023-05-15 20:06     ` Ross Philipson
2023-05-04 14:50 ` [PATCH v6 09/14] x86: Secure Launch SMP bringup support Ross Philipson
2023-05-05 17:54   ` Simon Horman
2023-05-05 18:59     ` Ross Philipson
2023-05-10 22:55   ` Jarkko Sakkinen
2023-05-11 16:21     ` Ross Philipson
2023-05-12 18:02   ` Thomas Gleixner
2023-05-15 20:19     ` Ross Philipson
2023-05-04 14:50 ` [PATCH v6 10/14] kexec: Secure Launch kexec SEXIT support Ross Philipson
2023-05-04 14:50 ` [PATCH v6 11/14] reboot: Secure Launch SEXIT support on reboot paths Ross Philipson
2023-05-12 11:40   ` Matthew Garrett
2023-05-15 18:16     ` Ross Philipson
2023-05-16  1:23       ` Daniel P. Smith
2023-05-04 14:50 ` [PATCH v6 12/14] x86: Secure Launch late initcall platform module Ross Philipson
2023-05-05 19:42   ` Simon Horman
2023-05-08 15:07     ` Ross Philipson
2023-05-10 22:39   ` Jarkko Sakkinen
2023-05-12 15:53     ` Ross Philipson
2023-05-10 22:40   ` Jarkko Sakkinen
2023-05-12 15:54     ` Ross Philipson
2023-05-04 14:50 ` [PATCH v6 13/14] tpm: Allow locality 2 to be set when initializing the TPM for Secure Launch Ross Philipson
2023-05-12 11:43   ` Matthew Garrett
2023-05-12 16:22     ` Ross Philipson
2023-05-16  1:37       ` Daniel P. Smith
2023-05-04 14:50 ` [PATCH v6 14/14] x86: EFI stub DRTM launch support " Ross Philipson
2023-05-05  8:39 ` [PATCH v6 00/14] x86: Trenchboot secure dynamic launch Linux kernel support Bagas Sanjaya
2023-05-05 15:45   ` Ross Philipson
2023-05-06  7:56     ` Bagas Sanjaya

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=87jzxdblmn.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=dpsmith@apertussolutions.com \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=kanth.ghatraju@oracle.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=mjg59@srcf.ucam.org \
    --cc=nivedita@alum.mit.edu \
    --cc=ross.philipson@oracle.com \
    --cc=trenchboot-devel@googlegroups.com \
    --cc=x86@kernel.org \
    /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).