RE: [PATCH] tpm: Fix the description error of the help information in Kconfig
Hi, On 2020/7/27 15:10, Arnd Bergmann wrote: > On Mon, Jul 27, 2020 at 4:54 AM Tianjia Zhang > wrote: >> >> Obviously, the TPM version number in the help message is wrong, which >> will cause confusion. This patch fixes it. > > How is this "obvious"? I tried finding the specification and could not > see anything to back up TIS 1.3 being only supported with TPM 1.3, or > the existence of a TPM 1.3 specification at all. > There is no TPM 1.3. There is a TIS Specification 1.3 which applies to TPM1.2 These are different specs, with different version numbers. So the fix is incorrect. Thanks, Peter
RE: [PATCH v2] tpm_tis: Remove the HID IFX0102
Hi,
NACK
> % git --no-pager grep IFX0102 drivers/char/tpm
> drivers/char/tpm/tpm_infineon.c: {"IFX0102", 0},
> drivers/char/tpm/tpm_tis.c: {"IFX0102", 0}, /* Infineon */
> Obviously IFX0102 was added to the HID table for the TCG TIS driver by
> mistake.
The HID IFX0102 was NOT added by mistake.
Let me explain the history a bit:
Old SLB 9635 / 9630 TPMs had two ways to interface them
- proprietary 'io' mapped protocol (tpm_infineon)
- tis protocol (tpm_tis)
Both match the same HID.
However with the emerging of the tis protocol, the io protocol eventually went
away for newer products.
So all TPM1.2 by IFX match the HID0102 and the TCG generic ones PNP0C31
So basically you break TPM1.2 support for all (newer) Infineon chips if the
platform vendor used the IFX0102 HID as they would speak via tpm_infineon
driver.
The bug must be something different, especially as it only seems to happen
after suspend resume.
Thanks,
Peter
RE: [PATCH] MAINTAINERS: update TPM driver infrastructure changes
>> +Q: https://patchwork.kernel.org/project/linux-integrity/list/ > Is there a way of viewing not just the posted patches, but the discussion as > well? Do we need to set up an archive as well? Spinics is archiving us at https://www.spinics.net/lists/linux-integrity/ It would be good to add this to the vger page + documented on the wiki, which should be added to MAINTAINERS. http://kernsec.org/wiki/index.php/Linux_Kernel_Integrity as wiki page Peter
RE: [PATCH] MAINTAINERS: update TPM driver infrastructure changes
>> +Q: https://patchwork.kernel.org/project/linux-integrity/list/ > Is there a way of viewing not just the posted patches, but the discussion as > well? Do we need to set up an archive as well? Spinics is archiving us at https://www.spinics.net/lists/linux-integrity/ It would be good to add this to the vger page + documented on the wiki, which should be added to MAINTAINERS. http://kernsec.org/wiki/index.php/Linux_Kernel_Integrity as wiki page Peter
RE: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands
> 1. I've got a TPM that implements vendor-specific command codes. Those > cannot be send to the TPM anymore, but are rejected with EINVAL. > >> 2. When upgrading the firmware on my TPM, it switches to a >> non-standard communication mode for the upgrade process and does not >> communicate using TPM2.0 commands during this time. Rejecting >> non-TPM2.0 commands means upgrading won't be possible anymore. >How non standard? Is the basic header even there? Are the lengths and status >code right? >This might be an argument to add a 'raw' ioctl or something specifically for >this special case. It follows the regular TPM command syntax and looks something like 1.2 commands. Peter
RE: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands
> 1. I've got a TPM that implements vendor-specific command codes. Those > cannot be send to the TPM anymore, but are rejected with EINVAL. > >> 2. When upgrading the firmware on my TPM, it switches to a >> non-standard communication mode for the upgrade process and does not >> communicate using TPM2.0 commands during this time. Rejecting >> non-TPM2.0 commands means upgrading won't be possible anymore. >How non standard? Is the basic header even there? Are the lengths and status >code right? >This might be an argument to add a 'raw' ioctl or something specifically for >this special case. It follows the regular TPM command syntax and looks something like 1.2 commands. Peter
RE: [tpmdd-devel] tpm_tis driver failed to suspend, error -62
Hi Aaron, Rajob, PeterA and everybody else, (sorry for the late reply) >On 03/27/2013 11:22 PM, Rajiv Andrade wrote: >> Sorry for the delay. Can you send us the dmesg output after setting >> loglevel=7 at boot time? Additionally, can you send us the TPM manufacturer >> model/version >>> On Thu, Mar 21, 2013 at 10:17 AM, wrote: Hi! Sadly, I have to say that I'm totally oblivious to power-related stuff both in software and hardware, so I have no idea what you are asking or proposing.. : According to the BootDmesg.txt it's an Infineon TPM [0.293936] pnp 00:0a: Plug and Play ACPI device, IDs IFX0102 PNP0c31 (active) [ 12.413651] tpm_tis 00:0a: 1.2 TPM (device-id 0xB, rev-id 16) @PeterA: Can you perhaps try find out the exact tpm version? 1) Install trousers and tpm_tools (emerge app-crypt/trousers app-crypt/tpm-tools) 2) Kill the tcsd and run it in the foreground # pkill -9 tcsd # tcsd -f (if it says up and running you can send it to background) 3) Run #tpm_version and post the output. Also the flags etc would perhaps be handy, they can be retrieved via sysfs - on you machine it _should_ be # cat /sys/devices/pnp0/00:0a/* and also post the output. What also might be worth a look - in your bugzilla it states: [ 0.225891] pnp 00:0a: Plug and Play ACPI device, IDs IFX0102 PNP0c31 (active) [ 9.150673] tpm_tis 00:0a: 1.2 TPM (device-id 0xB, rev-id 16) [ 9.292148] tpm_tis 00:0a: Adjusting TPM timeout parameters. [ 10.084067] tpm_tis 00:0a: A TPM error (7) occurred attempting to read a pcr value [ 10.084077] tpm_tis 00:0a: TPM is disabled/deactivated (0x7) Can you perhaps try to enable your TPM in the BIOS? It's quite often hidden under "embedded security device" or "system security". Quite often you have to have a bios password set to access these settings. If your system does not have bios support for TPMs, please tell me so and I'll try to help you out. Thanks, PeterH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] tpm_tis driver failed to suspend, error -62
Hi Aaron, Rajob, PeterA and everybody else, (sorry for the late reply) On 03/27/2013 11:22 PM, Rajiv Andrade wrote: Sorry for the delay. Can you send us the dmesg output after setting loglevel=7 at boot time? Additionally, can you send us the TPM manufacturer model/version On Thu, Mar 21, 2013 at 10:17 AM, peteraspl...@gentoo.se wrote: Hi! Sadly, I have to say that I'm totally oblivious to power-related stuff both in software and hardware, so I have no idea what you are asking or proposing.. : According to the BootDmesg.txt it's an Infineon TPM [0.293936] pnp 00:0a: Plug and Play ACPI device, IDs IFX0102 PNP0c31 (active) [ 12.413651] tpm_tis 00:0a: 1.2 TPM (device-id 0xB, rev-id 16) @PeterA: Can you perhaps try find out the exact tpm version? 1) Install trousers and tpm_tools (emerge app-crypt/trousers app-crypt/tpm-tools) 2) Kill the tcsd and run it in the foreground # pkill -9 tcsd # tcsd -f (if it says up and running you can send it to background) 3) Run #tpm_version and post the output. Also the flags etc would perhaps be handy, they can be retrieved via sysfs - on you machine it _should_ be # cat /sys/devices/pnp0/00:0a/* and also post the output. What also might be worth a look - in your bugzilla it states: [ 0.225891] pnp 00:0a: Plug and Play ACPI device, IDs IFX0102 PNP0c31 (active) [ 9.150673] tpm_tis 00:0a: 1.2 TPM (device-id 0xB, rev-id 16) [ 9.292148] tpm_tis 00:0a: Adjusting TPM timeout parameters. [ 10.084067] tpm_tis 00:0a: A TPM error (7) occurred attempting to read a pcr value [ 10.084077] tpm_tis 00:0a: TPM is disabled/deactivated (0x7) Can you perhaps try to enable your TPM in the BIOS? It's quite often hidden under embedded security device or system security. Quite often you have to have a bios password set to access these settings. If your system does not have bios support for TPMs, please tell me so and I'll try to help you out. Thanks, PeterH -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] TPM: Retry SaveState command in suspend path
Hi > The TPM is too busy to respond to the command immediately, but the > command could be resubmitted at a later time. The TPM MAY return > TPM_RETRY for any command at any time. > It can take several seconds before the TPM will respond again. I measured a > typical time between 3 and 4 seconds and the timeout is set at a safe 5 > seconds. > I tested a variety of TPMs from Infineon, Nuvoton, Atmel, and STMicro but was > only able to reproduce this with LPC and I2C TPMs from Infineon. Yes, our TPMs respond with TPM_RETRY if the time between two TPM_SaveState is too short to prevent wear leveling. If I remember correctly the internal timer is set to 5sec. As you've already said this is compliant with the TCG specification. Nevertheless, the patch looks good to me. Reviewed-by: Peter Huewe Acked-by: Peter Huewe Thanks, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] TPM: Retry SaveState command in suspend path
Hi The TPM is too busy to respond to the command immediately, but the command could be resubmitted at a later time. The TPM MAY return TPM_RETRY for any command at any time. It can take several seconds before the TPM will respond again. I measured a typical time between 3 and 4 seconds and the timeout is set at a safe 5 seconds. I tested a variety of TPMs from Infineon, Nuvoton, Atmel, and STMicro but was only able to reproduce this with LPC and I2C TPMs from Infineon. Yes, our TPMs respond with TPM_RETRY if the time between two TPM_SaveState is too short to prevent wear leveling. If I remember correctly the internal timer is set to 5sec. As you've already said this is compliant with the TCG specification. Nevertheless, the patch looks good to me. Reviewed-by: Peter Huewe peter.hu...@infineon.com Acked-by: Peter Huewe peter.hu...@infineon.com Thanks, Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH RESEND] char/tpm: Convert struct i2c_msg initialization to C99 format
>> Yes, no problem. >> I'll create a patch without it - >> I'll make it this way that you can apply the conversion patch first >> and then the change. >Thanks! >Kent The new version of my patch was just sent - please apply this one first. Thanks, Peter --- Peter Huewe Dipl. Inf. (FH) Infineon Technologies AG CCS TI SWT SW ESW Tel:+49 821 25851-86 Fax:+49 821 25851-40 peter.hu...@infineon.com VISIT US AT: www.infineon.com * Infineon Technologies AG Vorsitzender des Aufsichtsrats: Wolfgang Mayrhuber Vorstand: Dr. Reinhard Ploss (Vorsitzender), Dominik Asam, Arunjai Mittal Sitz der Gesellschaft: Neubiberg Registergericht: München HRB 126492 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH RESEND] char/tpm: Convert struct i2c_msg initialization to C99 format
Yes, no problem. I'll create a patch without it - I'll make it this way that you can apply the conversion patch first and then the change. Thanks! Kent The new version of my patch was just sent - please apply this one first. Thanks, Peter --- Peter Huewe Dipl. Inf. (FH) Infineon Technologies AG CCS TI SWT SW ESW Tel:+49 821 25851-86 Fax:+49 821 25851-40 peter.hu...@infineon.com VISIT US AT: www.infineon.com * Infineon Technologies AG Vorsitzender des Aufsichtsrats: Wolfgang Mayrhuber Vorstand: Dr. Reinhard Ploss (Vorsitzender), Dominik Asam, Arunjai Mittal Sitz der Gesellschaft: Neubiberg Registergericht: München HRB 126492 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH resend] TPM: Issue TPM_STARTUP at driver load if the TPM has not been started
Hi Jason,
>Great, I'll send an updated version, thanks!
;) You're welcome.
>> >+struct tpm_startup_in {
>> >+ __be16 startup_type;
>> >+} __packed;
>>
>>
>> All the other user
>> __attribute__((packed));
>> Care to change to be consistent?
> I used to __packed to avoid a checkpatch warning, they should probably
> all be changed?
Oh you're right - then sorry about my complaint.
Then I'd prefer submitting it as __packed and write another patch which change
the remaining ones.
Are you creating the patch to change or should I?
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH resend] TPM: Issue TPM_STARTUP at driver load if the TPM has not been started
Hi Jason, Hi Kent,
>
>Discussion on this got a bit sidetracked talking about
>suspend/resume.. To be clear, this fixes a real, serious, problem on
>normal embedded cases where the kernel refuses to attach the TPM driver
>at all.
>
>Key, are you happy with this as-is for the next merge window?
>
>This version is rebased and retested to 3.7-rc6. Tested on Atmel
>and Nuvoton LPC TPMs on PPC32.
Sorry I was tied up at work with other stuff, so I couldn't try out your
initial patch.
Thanks for resubmitting!
I just gave the new version a run on my beagleboard with our Infineon SLB9635
TT 1.2 Soft I2C TPM
and it seems to work as expected. (Tested with and without previous startup).
Tested-by: Peter Huewe
I just have some minor comments - please see below.
>+++ b/drivers/char/tpm/tpm.c
>+#define TPM_ORD_STARTUP cpu_to_be32(153)
>+#define TPM_ST_CLEAR cpu_to_be16(1)
>+#define TPM_ST_STATE cpu_to_be16(2)
>+#define TPM_ST_DEACTIVATED cpu_to_be16(3)
>+static const struct tpm_input_header tpm_startup_header = {
>+ .tag = TPM_TAG_RQU_COMMAND,
>+ .length = cpu_to_be32(12),
>+ .ordinal = TPM_ORD_STARTUP
>+};
>+
> ssize_t tpm_getcap(struct device *dev, __be32 subcap_id, cap_t *cap,
> const char *desc)
> {
Purely cosmetic question, but why did you define this before the tpm_getcap and
not tpm_startup?
All the other definitions are made before they are used - so this should
perhaps better be moved directly before tpm_startup.
(Maybe we should move out these definitions to a common location? Header?)
>@@ -541,11 +560,27 @@ int tpm_get_timeouts(struct tpm_chip *chip)
> tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
> tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
> tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
>+ rc = transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE, 0);
Please use NULL instead of 0, otherwise sparse complains - so
- rc = transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE, 0);
+ rc = transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE, NULL);
>+ if (rc == TPM_ERR_INVALID_POSTINIT) {
> ...
>+ rc = transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE, 0);
Same here
please use NULL instead of 0, otherwise sparse complains - so
- rc = transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE, 0);
+ rc = transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE,
NULL);
>diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> extern ssize_t tpm_show_pubek(struct device *, struct device_attribute *attr,
>@@ -291,6 +292,10 @@ struct tpm_getrandom_in {
> __be32 num_bytes;
> }__attribute__((packed));
>
>+struct tpm_startup_in {
>+ __be16 startup_type;
>+} __packed;
All the other user
__attribute__((packed));
Care to change to be consistent?
Apart from these three minor topics also a
Reviewed-by: Peter Huewe
Thanks,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH resend] TPM: Issue TPM_STARTUP at driver load if the TPM has not been started
Hi Jason, Hi Kent,
Discussion on this got a bit sidetracked talking about
suspend/resume.. To be clear, this fixes a real, serious, problem on
normal embedded cases where the kernel refuses to attach the TPM driver
at all.
Key, are you happy with this as-is for the next merge window?
This version is rebased and retested to 3.7-rc6. Tested on Atmel
and Nuvoton LPC TPMs on PPC32.
Sorry I was tied up at work with other stuff, so I couldn't try out your
initial patch.
Thanks for resubmitting!
I just gave the new version a run on my beagleboard with our Infineon SLB9635
TT 1.2 Soft I2C TPM
and it seems to work as expected. (Tested with and without previous startup).
Tested-by: Peter Huewe peter.hu...@infineon.com
I just have some minor comments - please see below.
+++ b/drivers/char/tpm/tpm.c
+#define TPM_ORD_STARTUP cpu_to_be32(153)
+#define TPM_ST_CLEAR cpu_to_be16(1)
+#define TPM_ST_STATE cpu_to_be16(2)
+#define TPM_ST_DEACTIVATED cpu_to_be16(3)
+static const struct tpm_input_header tpm_startup_header = {
+ .tag = TPM_TAG_RQU_COMMAND,
+ .length = cpu_to_be32(12),
+ .ordinal = TPM_ORD_STARTUP
+};
+
ssize_t tpm_getcap(struct device *dev, __be32 subcap_id, cap_t *cap,
const char *desc)
{
Purely cosmetic question, but why did you define this before the tpm_getcap and
not tpm_startup?
All the other definitions are made before they are used - so this should
perhaps better be moved directly before tpm_startup.
(Maybe we should move out these definitions to a common location? Header?)
@@ -541,11 +560,27 @@ int tpm_get_timeouts(struct tpm_chip *chip)
tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
+ rc = transmit_cmd(chip, tpm_cmd, TPM_INTERNAL_RESULT_SIZE, 0);
Please use NULL instead of 0, otherwise sparse complains - so
- rc = transmit_cmd(chip, tpm_cmd, TPM_INTERNAL_RESULT_SIZE, 0);
+ rc = transmit_cmd(chip, tpm_cmd, TPM_INTERNAL_RESULT_SIZE, NULL);
+ if (rc == TPM_ERR_INVALID_POSTINIT) {
...
+ rc = transmit_cmd(chip, tpm_cmd, TPM_INTERNAL_RESULT_SIZE, 0);
Same here
please use NULL instead of 0, otherwise sparse complains - so
- rc = transmit_cmd(chip, tpm_cmd, TPM_INTERNAL_RESULT_SIZE, 0);
+ rc = transmit_cmd(chip, tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
NULL);
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
extern ssize_t tpm_show_pubek(struct device *, struct device_attribute *attr,
@@ -291,6 +292,10 @@ struct tpm_getrandom_in {
__be32 num_bytes;
}__attribute__((packed));
+struct tpm_startup_in {
+ __be16 startup_type;
+} __packed;
All the other user
__attribute__((packed));
Care to change to be consistent?
Apart from these three minor topics also a
Reviewed-by: Peter Huewe peter.hu...@infineon.com
Thanks,
Peter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH resend] TPM: Issue TPM_STARTUP at driver load if the TPM has not been started
Hi Jason,
Great, I'll send an updated version, thanks!
;) You're welcome.
+struct tpm_startup_in {
+ __be16 startup_type;
+} __packed;
All the other user
__attribute__((packed));
Care to change to be consistent?
I used to __packed to avoid a checkpatch warning, they should probably
all be changed?
Oh you're right - then sorry about my complaint.
Then I'd prefer submitting it as __packed and write another patch which change
the remaining ones.
Are you creating the patch to change or should I?
Peter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] tpm: add documentation for sysfs interfaces
Hi Kent, > > > +What:/sys/class/misc/tpmX/device/active > > > +Date:April 2006 > > > +KernelVersion: 2.6.17 > > > +Contact: tpmdd-de...@lists.sf.net > > > +Description: The "active" property prints a '1' if the TPM chip is > > > accepting > > > + commands. An inactive TPM chip still contains all the state of > > > + an active chip (Storage Root Key, NVRAM, etc), and can be > > > + visible to the OS, but will not accept commands. > > > > Hmm, I know this is a tricky one (enabled/activated). > > maybe this would be better as: > > - visible to the OS, but will not accept commands. > > + visible to the OS, but will only accept a restricted set of > > commands. > > + See TCG specification(...) for more information. > > Yeah that's more accurate. I'm just inclined to point to the design > principles and structures spec here unless you have a better idea. Both > have enabled/activated info scattered throughout them. Sigh. :) > Maybe refer to TPM Main - Part 2 TPM Structures_v1.2_rev116 - Section 17 The table of ordinals there has a special column named 'Avail Disabled' and 'Avail Deactivated' which describes quite good which commands can be used and which not. Thanks, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] tpm: add documentation for sysfs interfaces
Hi Kent, thanks a lot for this effort! I really appreciate it. > +What:/sys/class/misc/tpmX/device/active > +Date:April 2006 > +KernelVersion: 2.6.17 > +Contact: tpmdd-de...@lists.sf.net > +Description: The "active" property prints a '1' if the TPM chip is accepting > + commands. An inactive TPM chip still contains all the state of > + an active chip (Storage Root Key, NVRAM, etc), and can be > + visible to the OS, but will not accept commands. Hmm, I know this is a tricky one (enabled/activated). maybe this would be better as: - visible to the OS, but will not accept commands. + visible to the OS, but will only accept a restricted set of commands. + See TCG specification(...) for more information. > +What:/sys/class/misc/tpmX/device/cancel > +Date:June 2005 > +KernelVersion: 2.6.13 > +Contact: tpmdd-de...@lists.sf.net > +Description: The "cancel" property allows you to cancel the currently > + pending TPM command. Echoing any value to cancel will call the > + TPM vendor specific cancel operation. I'd go for writing instead of echoing but this might only be bike-shedding. - pending TPM command. Echoing any value to cancel will call the + pending TPM command. Writing any value to cancel will call the The rest is great. Reviewed-by: Peter Huewe Signed-off-by: Peter Huewe Thanks, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] tpm: add documentation for sysfs interfaces
Hi Kent, thanks a lot for this effort! I really appreciate it. +What:/sys/class/misc/tpmX/device/active +Date:April 2006 +KernelVersion: 2.6.17 +Contact: tpmdd-de...@lists.sf.net +Description: The active property prints a '1' if the TPM chip is accepting + commands. An inactive TPM chip still contains all the state of + an active chip (Storage Root Key, NVRAM, etc), and can be + visible to the OS, but will not accept commands. Hmm, I know this is a tricky one (enabled/activated). maybe this would be better as: - visible to the OS, but will not accept commands. + visible to the OS, but will only accept a restricted set of commands. + See TCG specification(...) for more information. +What:/sys/class/misc/tpmX/device/cancel +Date:June 2005 +KernelVersion: 2.6.13 +Contact: tpmdd-de...@lists.sf.net +Description: The cancel property allows you to cancel the currently + pending TPM command. Echoing any value to cancel will call the + TPM vendor specific cancel operation. I'd go for writing instead of echoing but this might only be bike-shedding. - pending TPM command. Echoing any value to cancel will call the + pending TPM command. Writing any value to cancel will call the The rest is great. Reviewed-by: Peter Huewe peter.hu...@infineon.com Signed-off-by: Peter Huewe peter.hu...@infineon.com Thanks, Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] tpm: add documentation for sysfs interfaces
Hi Kent, +What:/sys/class/misc/tpmX/device/active +Date:April 2006 +KernelVersion: 2.6.17 +Contact: tpmdd-de...@lists.sf.net +Description: The active property prints a '1' if the TPM chip is accepting + commands. An inactive TPM chip still contains all the state of + an active chip (Storage Root Key, NVRAM, etc), and can be + visible to the OS, but will not accept commands. Hmm, I know this is a tricky one (enabled/activated). maybe this would be better as: - visible to the OS, but will not accept commands. + visible to the OS, but will only accept a restricted set of commands. + See TCG specification(...) for more information. Yeah that's more accurate. I'm just inclined to point to the design principles and structures spec here unless you have a better idea. Both have enabled/activated info scattered throughout them. Sigh. :) Maybe refer to TPM Main - Part 2 TPM Structures_v1.2_rev116 - Section 17 The table of ordinals there has a special column named 'Avail Disabled' and 'Avail Deactivated' which describes quite good which commands can be used and which not. Thanks, Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] TPM: Let the tpm char device be openable multiple times
-Original Message- > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > Using open/close is an interesting idea, but it wouldn't work. open() > is coded to return EBUSY if another process has it open, rather than > block, and spinning on open would be unacceptable. Hmm, maybe write a small pass through program which opens /dev/tpm once and accepts its data via a socket or pipe? Thanks, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] TPM: Let the tpm char device be openable multiple times
-Original Message- From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] Using open/close is an interesting idea, but it wouldn't work. open() is coded to return EBUSY if another process has it open, rather than block, and spinning on open would be unacceptable. Hmm, maybe write a small pass through program which opens /dev/tpm once and accepts its data via a socket or pipe? Thanks, Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] TPM: Issue TPM_STARTUP at driver load if the TPM has not been started
Hi Kent, > Peter, you mentioned you have some embedded setups, would you be able > to test? I could probably test it on the beagleboard c4 with our Infineon SLB9635 TT1.2 I2C TPM, but I'm currently not sure if I have the suspend/resume thing currently running correctly. Apart from that I also have some 'ancient' x86 systems without TPM bios integration here (so the BIOS doesn't even know anything about a tpm), there I could test our LPC based tpms (SLB9635 / SLB9655). Unfortunately it'll take some time, due to other priorities. Please tell me when the patch is ready for testing. Thanks, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] TPM: Issue TPM_STARTUP at driver load if the TPM has not been started
Hi Kent, Peter, you mentioned you have some embedded setups, would you be able to test? I could probably test it on the beagleboard c4 with our Infineon SLB9635 TT1.2 I2C TPM, but I'm currently not sure if I have the suspend/resume thing currently running correctly. Apart from that I also have some 'ancient' x86 systems without TPM bios integration here (so the BIOS doesn't even know anything about a tpm), there I could test our LPC based tpms (SLB9635 / SLB9655). Unfortunately it'll take some time, due to other priorities. Please tell me when the patch is ready for testing. Thanks, Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] TPM: Issue TPM_STARTUP at driver load if the TPM has not been started
>I welcome such functionality. Thanks for your efforts. Me too ;) Peter Huewe Infineon Technologies AG CCS TI SWT SW ESW Tel:+49 821 25851-86 Fax:+49 821 25851-40 peter.hu...@infineon.com VISIT US AT: www.infineon.com * Infineon Technologies AG Vorsitzender des Aufsichtsrats: Wolfgang Mayrhuber Vorstand: Peter Bauer (Vorsitzender), Dominik Asam, Arunjai Mittal, Dr. Reinhard Ploss Sitz der Gesellschaft: Neubiberg Registergericht: München HRB 126492 Thanks, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] TPM: Issue TPM_STARTUP at driver load if the TPM has not been started
Hi Jason,
> The TPM will respond to TPM_GET_CAP with TPM_ERR_INVALID_POSTINIT if
> TPM_STARTUP has not been issued. This will result in the TPM driver
> failing to load and no way to recover. Detect this and automatically
> issue TPM_STARTUP.
> This is for embedded applications where the kernel is the first thing
> to touch the TPM.
Thanks for working on this.
I also thought about this scenario quite often.
Shouldn't we then also add a TpmStartup(ST_STATE) in case of a resume?
rc=GetCapability()
if(rc==INVALID_POSTINIT)
tpm_transmit ("TPM_STARTUP(ST_STATE)")...
Thanks,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] TPM: Let the tpm char device be openable multiple times
Hi Jason, one quick question: - TPM_BUFSIZE = 4096, [...] + u8 data_bufferx[2048]; Why do you half the buffer size? Thanks, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] TPM: Let the tpm char device be openable multiple times
Hi Jason, one quick question: - TPM_BUFSIZE = 4096, [...] + u8 data_bufferx[2048]; Why do you half the buffer size? Thanks, Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] TPM: Issue TPM_STARTUP at driver load if the TPM has not been started
Hi Jason, The TPM will respond to TPM_GET_CAP with TPM_ERR_INVALID_POSTINIT if TPM_STARTUP has not been issued. This will result in the TPM driver failing to load and no way to recover. Detect this and automatically issue TPM_STARTUP. This is for embedded applications where the kernel is the first thing to touch the TPM. Thanks for working on this. I also thought about this scenario quite often. Shouldn't we then also add a TpmStartup(ST_STATE) in case of a resume? rc=GetCapability() if(rc==INVALID_POSTINIT) tpm_transmit (TPM_STARTUP(ST_STATE))... Thanks, Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH] TPM: Issue TPM_STARTUP at driver load if the TPM has not been started
I welcome such functionality. Thanks for your efforts. Me too ;) Peter Huewe Infineon Technologies AG CCS TI SWT SW ESW Tel:+49 821 25851-86 Fax:+49 821 25851-40 peter.hu...@infineon.com VISIT US AT: www.infineon.com * Infineon Technologies AG Vorsitzender des Aufsichtsrats: Wolfgang Mayrhuber Vorstand: Peter Bauer (Vorsitzender), Dominik Asam, Arunjai Mittal, Dr. Reinhard Ploss Sitz der Gesellschaft: Neubiberg Registergericht: München HRB 126492 Thanks, Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [GIT PULL] tpmdd: TPM drivers, tpm-rng and fixes
>> > Build using make -> no error. >> I can't reproduce this either, James, can you send out your .config? > See attached. Hi James, even with you config, I can't reproduce it here with 3.6-rc3 + mypatch. Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [GIT PULL] tpmdd: TPM drivers, tpm-rng and fixes
Build using make - no error. I can't reproduce this either, James, can you send out your .config? See attached. Hi James, even with you config, I can't reproduce it here with 3.6-rc3 + mypatch. Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [GIT PULL] tpmdd: TPM drivers, tpm-rng and fixes
>> From: James Morris [mailto:jmor...@namei.org] >> I'm getting this error when building i2c as a module >> WARNING: "__i2c_transfer" [drivers/char/tpm/tpm_i2c_infineon.ko] undefined! > This is unconditionally (except I2C) available in Linus' master tree. > And was introduced by b37d2a3a75cb in June by Jean Delvare. > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b37d2a3a75cb0e72e18c29336cb2095b63dabfc8 > It was tested here against Linus' tree at time of submission. Did double check it against v3.6-rc3. $ make ARCH=arm omap2plus_defconfig $ make ARCH=arm menuconfig -> deselected OMAP2_TYPICAL, which enables I2C to be builded as a module. -> selected I2C as Module. Build using make -> no error. Thanks, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [GIT PULL] tpmdd: TPM drivers, tpm-rng and fixes
> From: James Morris [mailto:jmor...@namei.org] > I'm getting this error when building i2c as a module > WARNING: "__i2c_transfer" [drivers/char/tpm/tpm_i2c_infineon.ko] undefined! This is unconditionally (except I2C) available in Linus' master tree. And was introduced by b37d2a3a75cb in June by Jean Delvare. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b37d2a3a75cb0e72e18c29336cb2095b63dabfc8 It was tested here against Linus' tree at time of submission. Thanks, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [GIT PULL] tpmdd: TPM drivers, tpm-rng and fixes
From: James Morris [mailto:jmor...@namei.org] I'm getting this error when building i2c as a module WARNING: __i2c_transfer [drivers/char/tpm/tpm_i2c_infineon.ko] undefined! This is unconditionally (except I2C) available in Linus' master tree. And was introduced by b37d2a3a75cb in June by Jean Delvare. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b37d2a3a75cb0e72e18c29336cb2095b63dabfc8 It was tested here against Linus' tree at time of submission. Thanks, Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [GIT PULL] tpmdd: TPM drivers, tpm-rng and fixes
From: James Morris [mailto:jmor...@namei.org] I'm getting this error when building i2c as a module WARNING: __i2c_transfer [drivers/char/tpm/tpm_i2c_infineon.ko] undefined! This is unconditionally (except I2C) available in Linus' master tree. And was introduced by b37d2a3a75cb in June by Jean Delvare. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b37d2a3a75cb0e72e18c29336cb2095b63dabfc8 It was tested here against Linus' tree at time of submission. Did double check it against v3.6-rc3. $ make ARCH=arm omap2plus_defconfig $ make ARCH=arm menuconfig - deselected OMAP2_TYPICAL, which enables I2C to be builded as a module. - selected I2C as Module. Build using make - no error. Thanks, Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] char/tpm: Use struct dev_pm_ops for power management.
Hi Kent, > Thanks Peter. One more request - can you roll this fix into the driver > patch itself and just add a note in the change log? Sorry I didn't > mention this before. Yes I'll do that. And while at it I'll also replace our i2c_transfer_nolock with the new (in 3.6rc-1) __i2c_transfer function and integrate Bryans Patch directly into the driver. Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] char/tpm: Use struct dev_pm_ops for power management.
Hi Kent, Thanks Peter. One more request - can you roll this fix into the driver patch itself and just add a note in the change log? Sorry I didn't mention this before. Yes I'll do that. And while at it I'll also replace our i2c_transfer_nolock with the new (in 3.6rc-1) __i2c_transfer function and integrate Bryans Patch directly into the driver. Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: New TPM driver, hwrng driver and fixes (2)
Hi James, >Reverted: > CC [M] drivers/char/tpm/tpm_i2c_infineon.o >drivers/char/tpm/tpm_i2c_infineon.c:740: error: lvalue required as unary & >operand >make[1]: *** [drivers/char/tpm/tpm_i2c_infineon.o] Error 1 >Was this code tested? Yes - quite extensively and also reviewed quite extensively. I'll have a look at this - probably the case if CONFIG_PM is not set is causing this. Sorry for the inconvenience, I'll create a patch. Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: New TPM driver, hwrng driver and fixes (2)
Hi James, Reverted: CC [M] drivers/char/tpm/tpm_i2c_infineon.o drivers/char/tpm/tpm_i2c_infineon.c:740: error: lvalue required as unary operand make[1]: *** [drivers/char/tpm/tpm_i2c_infineon.o] Error 1 Was this code tested? Yes - quite extensively and also reviewed quite extensively. I'll have a look at this - probably the case if CONFIG_PM is not set is causing this. Sorry for the inconvenience, I'll create a patch. Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH 1/2] char/tpm: Add new driver for Infineon I2C TIS TPM
> I've applied this patch to my tpmdd staging tree [1]. Thanks a lot, Kent. Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH 1/2] char/tpm: Add new driver for Infineon I2C TIS TPM
I've applied this patch to my tpmdd staging tree [1]. Thanks a lot, Kent. Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
