linux-kernel - Re: [PATCH 1/1] char: tpm: handle HAS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4d08af651b95744dc6cfa0c2624c596d21d83d09.camel@linux.ibm.com>
Date: Fri, 05 Apr 2024 11:23:34 +0200
From: Niklas Schnelle <schnelle@...ux.ibm.com>
To: Arnd Bergmann <arnd@...nel.org>, Peter Huewe <peterhuewe@....de>,
        Jarkko
	Sakkinen <jarkko@...nel.org>
Cc: linux-integrity@...r.kernel.org, Heiko Carstens <hca@...ux.ibm.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] char: tpm: handle HAS_IOPORT dependencies

On Thu, 2024-04-04 at 17:56 +0200, Arnd Bergmann wrote:
> On Thu, Apr 4, 2024, at 17:41, Niklas Schnelle wrote:
> > 
> > Good find! I do see the same #ifdef in v5 but maybe something else
> > changed. I think this was also hidden during both my local test builds
> > and kernel test robot because of the PNP -> ACPI || ISA dependency
> > which I think implies HAS_IOPORT. So unless I'm missing something we
> > can't currently get here with HAS_IOPORT=n. Maybe that changed?
> 
> Rihgt, I just found that as well, so the TCG_INFINEON driver
> won't ever be enabled without CONFIG_HAS_IOPORT after all.
> 
> > I'm now thinking maybe keeping TPM_INF_IO_PORT is the cleaner choice.
> > It saves us 4 lines of #ifdeffery at the cost of one sometimes "unused"
> > define.
> 
> Agreed. I tried it out for reference, but it does get quite ugly,
> see below. Alternatively, we could just add a 'depends on HAS_IOPORT'
> to this driver after all. Even if it can be used on MMIO, it might
> never actually be built without PIO.

Oh yeah thats an even bigger change than I thought if we want to remove
the TPM_INF_IO_PORT define for HAS_IOPORT=n. It's also still bit of an
arbitrary point to stop since we could just as well argue that struct
tpm_inf_dev::iotype then also shouldn't be there. I think one could
handle this still with a bit of regrouping but not sure if it is worth
it.

I just confirmed that keeping the define it also compiles but I do
wonder if it's not even cleaner to just add an explicit HAS_IOPORT
dependency and no new #ifdefs in the code. I'm willing to send a patch
for any of these solutions though.

> 
> diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
> index 418c9ed59ffd..852bb9344788 100644
> --- a/drivers/char/tpm/Kconfig
> +++ b/drivers/char/tpm/Kconfig
> @@ -157,7 +157,7 @@ config TCG_ATMEL
>  
>  config TCG_INFINEON
>  	tristate "Infineon Technologies TPM Interface"
> -	depends on PNP
> +	depends on PNP || COMPILE_TEST
>  	help
>  	  If you have a TPM security chip from Infineon Technologies
>  	  (either SLD 9630 TT 1.1 or SLB 9635 TT 1.2) say Yes and it
> diff --git a/drivers/char/tpm/tpm_infineon.c b/drivers/char/tpm/tpm_infineon.c
> index 99c6e565ec8d..768ca65960d8 100644
> --- a/drivers/char/tpm/tpm_infineon.c
---8<---