mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
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, kexec@lists.infradead.org,
	linux-efi@vger.kernel.org, iommu@lists.linux.dev
Cc: dpsmith@apertussolutions.com, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de, hpa@zytor.com,
	dave.hansen@linux.intel.com, ardb@kernel.org,
	mjg59@srcf.ucam.org, James.Bottomley@hansenpartnership.com,
	peterhuewe@gmx.de, jarkko@kernel.org, jgg@ziepe.ca,
	luto@amacapital.net, nivedita@alum.mit.edu,
	herbert@gondor.apana.org.au, davem@davemloft.net, corbet@lwn.net,
	ebiederm@xmission.com, dwmw2@infradead.org,
	baolu.lu@linux.intel.com, kanth.ghatraju@oracle.com,
	andrew.cooper3@citrix.com, trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v15 19/28] x86/tpm: Early TPM PCR extending driver
Date: Tue, 16 Dec 2025 13:53:35 -0800	[thread overview]
Message-ID: <56929e8b-a7cf-4390-b4ec-0b4c2c32b311@intel.com> (raw)
In-Reply-To: <20251215233316.1076248-20-ross.philipson@oracle.com>

I'm mostly spot-checking this to see what kind of shape it's in and how
much work and diligence has been applied in the last 8 months since v14.

On 12/15/25 15:33, Ross Philipson wrote:
...
> The driver could be extended for further operations if needed. This
> TPM dirver implementation relies as much as possible on existing mainline

<sigh>

v15 and no spell checking. :(

> --- /dev/null
> +++ b/arch/x86/boot/compressed/early_tpm_extend.c
> @@ -0,0 +1,601 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2010-2012 United States Government, as represented by
> + * the Secretary of Defense.  All rights reserved.

IANAL, but this looks fishy.

It's theoretically fine to go grab random code off the Internet and
submit it to the kernel, given the correct license. But I do want to
know what its story is and where it came from.

I also seem to remember that there are special rules around the US
federal government's inability to hold copyrights. This seems worth at
least a mention ... somewhere.

This is helpful, for instance:

> + * based off of the original tools/vtpm_manager code base which is:
> + * Copyright (c) 2005, Intel Corp.
> + * All rights reserved.

so thanks for that one.

> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + *
> + *   * Redistributions of source code must retain the above copyright
> + *     notice, this list of conditions and the following disclaimer.
> + *   * Redistributions in binary form must reproduce the above
> + *     copyright notice, this list of conditions and the following
> + *     disclaimer in the documentation and/or other materials provided
> + *     with the distribution.
> + *   * Neither the name of Intel Corporation nor the names of its
> + *     contributors may be used to endorse or promote products derived
> + *     from this software without specific prior written permission.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
> + * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> + * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> + * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
> + * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
> + * OF THE POSSIBILITY OF SUCH DAMAGE.
> + */

Also, IANAL, but this looks BSD-ish.

I would have kinda expected the SPDX header to say BSD-blah-blah and not
GPL-2.0-only.

I'd really appreciate if you could go have a huddle with your corporate
Open Source folks and make sure this is all proper. To me, it looks
fishy at _best_.

...
> +/*
> + * We're far too early to calibrate time.  Assume a 5GHz processor (the upper
> + * end of the Fam19h range), which causes us to be wrong in the safe direction
> + * on slower systems.
> + */

https://docs.kernel.org/process/maintainer-tip.html#changelog

Imperative voice please.

...
> +static int __tis_recv_data(struct tpm_chip *chip, u8 *buf, int count)
> +{
> +	int size = 0;
> +	int burstcnt;
> +
> +	while (size < count && __tis_wait_for_stat(chip, TPM_STS_DATA_AVAIL | TPM_STS_VALID, chip->timeout_c) == 0) {
> +		burstcnt = __tis_get_burstcount(chip);
> +
> +		for ( ; burstcnt > 0 && size < count; --burstcnt)
> +			buf[size++] = tpm_read8(chip, TPM_DATA_FIFO(chip->locality));
> +	}
> +
> +	return size;
> +}
> +
> +/**
> + * tpm_tis_check_locality - Check if the given locality is the active one
> + * @chip:	The TPM chip instance
> + * @loc:	The locality to check
> + *
> + * Return: true - locality active, false - not active
> + */
> +bool tpm_tis_check_locality(struct tpm_chip *chip, int loc)
> +{
> +	if ((tpm_read8(chip, TPM_ACCESS(loc)) & (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) == (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) {
> +		chip->locality = loc;
> +		return true;
> +	}
> +
> +	return false;
> +}
> +
> +/**
> + * tpm_tis_release_locality - Release the active locality
> + * @chip:	The TPM chip instance
> + */
> +void tpm_tis_release_locality(struct tpm_chip *chip)
> +{
> +	if ((tpm_read8(chip, TPM_ACCESS(chip->locality)) & (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID)) == (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID))
> +		tpm_write8(chip, TPM_ACCESS(chip->locality), TPM_ACCESS_RELINQUISH_LOCALITY);
> +
> +	chip->locality = 0;
> +}

I guess some folks aren't enforcing the 80-column limits. But this is
not even close. It's almost 80x2.

Has there even been an attempt to make this conform to kernel coding
style? What other checkpatch.pl warnings are being ignored?

  reply	other threads:[~2025-12-16 21:53 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-15 23:32 [PATCH v15 00/28] x86: Secure Launch support for Intel TXT Ross Philipson
2025-12-15 23:32 ` [PATCH v15 01/28] tpm: Initial step to reorganize TPM public headers Ross Philipson
2026-01-19 23:40   ` Jarkko Sakkinen
2026-01-19 23:52     ` Jarkko Sakkinen
2026-02-01 16:21       ` Daniel P. Smith
2026-02-01 16:20     ` Daniel P. Smith
2026-02-01 22:46       ` Jarkko Sakkinen
2025-12-15 23:32 ` [PATCH v15 02/28] tpm: Move TPM1 specific definitions and functions to new headers Ross Philipson
2026-01-19 23:57   ` Jarkko Sakkinen
2026-02-01 16:23     ` Daniel P. Smith
2026-02-04 17:44       ` ross.philipson
2026-02-08 13:39         ` Jarkko Sakkinen
2025-12-15 23:32 ` [PATCH v15 03/28] tpm: Move TPM2 " Ross Philipson
2025-12-15 23:32 ` [PATCH v15 04/28] tpm: Move TPM common base definitions to new public common header Ross Philipson
2025-12-15 23:32 ` [PATCH v15 05/28] tpm: Move platform specific definitions to the new PTP header Ross Philipson
2025-12-15 23:32 ` [PATCH v15 06/28] tpm: Add TPM buffer support header for standalone reuse Ross Philipson
2025-12-15 23:32 ` [PATCH v15 07/28] tpm: Remove main TPM header from TPM event log header Ross Philipson
2025-12-15 23:32 ` [PATCH v15 08/28] tpm/tpm_tis: Close all localities Ross Philipson
2026-03-29 22:57   ` Josh Snyder
2025-12-15 23:32 ` [PATCH v15 09/28] tpm/tpm_tis: Address positive localities in tpm_tis_request_locality() Ross Philipson
2025-12-15 23:32 ` [PATCH v15 10/28] tpm/tpm_tis: Allow locality to be set to a different value Ross Philipson
2025-12-15 23:32 ` [PATCH v15 11/28] tpm/sysfs: Show locality used by kernel Ross Philipson
2025-12-15 23:33 ` [PATCH v15 12/28] Documentation/x86: Secure Launch kernel documentation Ross Philipson
2025-12-15 23:33 ` [PATCH v15 13/28] x86: Secure Launch Kconfig Ross Philipson
2025-12-16  3:20   ` Randy Dunlap
2025-12-17 18:11     ` ross.philipson
2025-12-15 23:33 ` [PATCH v15 14/28] x86: Secure Launch Resource Table header file Ross Philipson
2025-12-15 23:33 ` [PATCH v15 15/28] x86: Secure Launch main " Ross Philipson
2025-12-15 23:33 ` [PATCH v15 16/28] x86/txt: Intel Trusted eXecution Technology (TXT) definitions Ross Philipson
2025-12-16 22:14   ` Dave Hansen
2025-12-17 18:44     ` ross.philipson
2025-12-18 16:34   ` Dave Hansen
2025-12-18 18:17     ` ross.philipson
2025-12-15 23:33 ` [PATCH v15 17/28] x86: Add early SHA-1 support for Secure Launch early measurements Ross Philipson
2025-12-16  0:21   ` Eric Biggers
2025-12-17 18:10     ` ross.philipson
2025-12-15 23:33 ` [PATCH v15 18/28] x86: Add early SHA-256 " Ross Philipson
2025-12-15 23:33 ` [PATCH v15 19/28] x86/tpm: Early TPM PCR extending driver Ross Philipson
2025-12-16 21:53   ` Dave Hansen [this message]
2025-12-17 18:40     ` ross.philipson
2025-12-17 19:06       ` Dave Hansen
2025-12-19 21:26     ` Daniel P. Smith
2026-01-03 20:44       ` Dave Hansen
2026-01-08 16:21         ` Daniel P. Smith
2026-01-20  0:10   ` Jarkko Sakkinen
2025-12-15 23:33 ` [PATCH v15 20/28] x86/msr: Add variable MTRR base/mask and x2apic ID registers Ross Philipson
2025-12-15 23:33 ` [PATCH v15 21/28] x86/boot: Place TXT MLE header in the kernel_info section Ross Philipson
2025-12-15 23:33 ` [PATCH v15 22/28] x86: Secure Launch kernel early boot stub Ross Philipson
2025-12-16 22:32   ` Dave Hansen
2025-12-17 18:47     ` ross.philipson
2025-12-15 23:33 ` [PATCH v15 23/28] x86: Secure Launch kernel late " Ross Philipson
2025-12-15 23:33 ` [PATCH v15 24/28] x86: Secure Launch SMP bringup support Ross Philipson
2025-12-15 23:33 ` [PATCH v15 25/28] kexec: Secure Launch kexec SEXIT support Ross Philipson
2025-12-15 23:33 ` [PATCH v15 26/28] x86/reboot: Secure Launch SEXIT support on reboot paths Ross Philipson
2025-12-15 23:33 ` [PATCH v15 27/28] x86: Secure Launch late initcall platform module Ross Philipson
2025-12-15 23:33 ` [PATCH v15 28/28] x86/efi: EFI stub DRTM launch support for Secure Launch Ross Philipson
2025-12-16  3:46 ` [PATCH v15 00/28] x86: Secure Launch support for Intel TXT Jarkko Sakkinen
2025-12-17 18:15   ` ross.philipson
2025-12-16 22:14 ` Dave Hansen
2026-01-08 16:36   ` Daniel P. Smith
2026-01-08 16:41     ` Dave Hansen
2026-01-08 16:46       ` Daniel P. Smith
2026-02-09 14:04 ` Ard Biesheuvel
2026-02-12 19:49   ` Daniel P. Smith
2026-02-12 19:54     ` Dave Hansen
2026-02-12 20:39     ` Ard Biesheuvel
2026-02-18 17:30       ` Ard Biesheuvel
2026-02-18 18:02         ` ross.philipson
2026-02-26 18:31         ` ross.philipson
2026-02-26 22:33           ` Ard Biesheuvel
2026-02-18 20:03       ` Andy Lutomirski
2026-02-18 20:29         ` H. Peter Anvin
2026-02-18 20:34           ` Andy Lutomirski
2026-02-18 21:04             ` Simo Sorce
2026-02-18 21:54               ` Andy Lutomirski
2026-02-19  7:54                 ` Ard Biesheuvel
2026-02-19 17:10                   ` H. Peter Anvin
2026-02-19 17:34                   ` Andy Lutomirski
2026-02-20  8:30                     ` Ard Biesheuvel
2026-02-23 21:37                       ` Daniel P. Smith

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=56929e8b-a7cf-4390-b4ec-0b4c2c32b311@intel.com \
    --to=dave.hansen@intel.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ardb@kernel.org \
    --cc=baolu.lu@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=dpsmith@apertussolutions.com \
    --cc=dwmw2@infradead.org \
    --cc=ebiederm@xmission.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux.dev \
    --cc=jarkko@kernel.org \
    --cc=jgg@ziepe.ca \
    --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=peterhuewe@gmx.de \
    --cc=ross.philipson@oracle.com \
    --cc=tglx@linutronix.de \
    --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

all inboxes | Powered by JetHome®