RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 921122 - tcsd.service is not starting with default configuration
Summary: tcsd.service is not starting with default configuration
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: trousers
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Steve Grubb
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 744225
TreeView+ depends on / blocked
 
Reported: 2013-03-13 14:03 UTC by Petr Sklenar
Modified: 2019-07-29 04:00 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-18 12:36:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 95783 0 None None None 2019-03-07 20:45:27 UTC

Description Petr Sklenar 2013-03-13 14:03:19 UTC
Description of problem:
tcsd.service is not starting with default configuration.
Its possible to start it on rhel6, not with rhel7.

Version-Release number of selected component (if applicable):
trousers-0.3.10-1.el7.x86_64

How reproducible:
always

Steps to Reproduce:
base rhel7 install:
1.systemctl start  tcsd.service
2.
3.
  
Actual results:
[root@pes-guest-92 ~]# /sbin/tcsd -c /etc/tcsd.conf -e
[root@pes-guest-92 ~]# echo $?
137
[root@pes-guest-92 ~]# service tcsd start
Redirecting to /bin/systemctl start  tcsd.service
Job for tcsd.service failed. See 'systemctl status tcsd.service' and 'journalctl -xn' for details.
[root@pes-guest-92 ~]# service tcsd status
Redirecting to /bin/systemctl status  tcsd.service
tcsd.service - TCG Core Services Daemon
	  Loaded: loaded (/usr/lib/systemd/system/tcsd.service; disabled)
	  Active: failed (Result: exit-code) since Wed 2013-03-13 14:58:09 EDT; 2s ago
	 Process: 13458 ExecStart=/sbin/tcsd (code=exited, status=137)

Mar 13 14:58:09 pes-guest-92.lab.eng.brq.redhat.com systemd[1]: tcsd.service: control process exited, code=exited status=137
Mar 13 14:58:09 pes-guest-92.lab.eng.brq.redhat.com systemd[1]: Failed to start TCG Core Services Daemon.
Mar 13 14:58:09 pes-guest-92.lab.eng.brq.redhat.com systemd[1]: Unit tcsd.service entered failed state
[root@pes-guest-92 ~]# rpm -qf /sbin/tcsd
trousers-0.3.10-1.el7.x86_64


Expected results:
it starts or it writes any message about initial configuration(if its really needed) into log.

Additional info:

Comment 2 Steve Grubb 2013-07-09 17:19:28 UTC
This seems to be the relevant part of a run:

open("/etc/tcsd.conf", O_RDONLY)        = 3
read(3, "\n#\n# This is the configuration f"..., 4096) = 4096
read(3, " TCS/TPM for its capabilities\n#\t"..., 4096) = 2315
read(3, "", 4096)                       = 0
close(3)                                = 0
open("/dev/tpm0", O_RDWR)               = -1 EBUSY (Device or resource busy)
open("/udev/tpm0", O_RDWR)              = -1 ENOENT (No such file or directory)
open("/dev/tpm", O_RDWR)                = -1 ENOENT (No such file or directory)
write(2, "TCSD TDDL ERROR: Could not find "..., 50TCSD TDDL ERROR: Could not find a device to open!
) = 50
exit_group(4233)

My guess is that rngd is using the tpm.

Comment 3 George C. Wilson 2013-07-11 20:08:35 UTC
I'll work on getting this bug reverse mirrored to IBM.

Comment 4 IBM Bug Proxy 2013-07-11 22:31:11 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=921122

Comment 5 Steve Grubb 2013-07-14 15:56:33 UTC
I am curious if your system has rngd enabled? If rngd has run at all, it seems to leave the TPM in a state where tcsd cannot connect to it. I don't know if they can share the device or not. I can only start tcsd in the default config when rngd has been disabled or removed from the system.

Comment 6 IBM Bug Proxy 2013-07-15 17:21:06 UTC
Yes, I see the same thing.  And it appears to work vice versa as well.  Richard Costa has been assigned this bug on our side and reports that this is also happening on Fedora.
To clarify, "work" in the last comments means "the bug works."  It looks like the TPM device access is mutually exclusive.  The tcsd starts after rngd has shutdown.  However, it always seems to report:

Jul 15 12:17:00 dhcp-9-41-105-128 TCSD TDDL[13046]: TrouSerS ioctl: (25) Inappropriate ioctl for device
Jul 15 12:17:00 dhcp-9-41-105-128 TCSD TDDL[13046]: TrouSerS Falling back to Read/Write device support.
Jul 15 12:17:00 dhcp-9-41-105-128 TCSD[13047]: TrouSerS trousers 0.3.10: TCSD up and running.

Comment 8 IBM Bug Proxy 2013-07-18 00:40:42 UTC
As mentioned here by Steve Grubb and George Wilson, this problem arises from the fact that rngd grabs the tpm device (usually in /dev/tpm0) before tcsd. Since the tpm driver only allows a single process to open the tpm device, the tcsd receives an error code when it executes the open call.

Note that the TSS specification (used as a basis for the tcsd) assumes that only code belonging to the TSS stack (in this case, the tcsd), access the TPM device through its device driver, so the driver is doing what its suppose to do. The text that mentions it can be found at the latest TSS document, at page 7, last paragraph.

After talking to George Wilson about it, I've found that there was a recent modification in the rngd code to allow it to increase the entropy of the number generator by accessing the random number generator inside the TPM chip.

Based on the evidence above, from now on, I'm gonna work on the rngd to fix this issue.

Comment 9 IBM Bug Proxy 2013-07-19 22:00:39 UTC
This appears to be an rngd issue.  At some point, TPM support was added to rngd.  The TPM device driver enforces exclusive access so rngd access conflicts with tcsd.  Kent Yoder's change to the TPM device driver contributes entropy via a /dev/hwrng device.  So recommended changes are:

(1) rngd's default command line should be modified to add --no-tpm=1
(2) The tpm-rng device driver needs to be loaded if rngd is to harvest entropy from the TPM

Unsure if you want (2) to happen by default (or on demand) or if loading it should be an explicit end user decision.

Comment 10 IBM Bug Proxy 2014-03-04 19:02:46 UTC
Tested on RHEL7.0 Snapshot 6, following the procedure below and everything ran fine.

However, when I tried to load in the reverse order (first tcsd, then rngd), I've got an access error from rngd. It couldn't access the TPM hardware on /dev/tpm0, because TrouSerS was already using it.

My concern here is that rngd will try to access the /dev/tpm0 device on demand (open it when needed), but it will fail because the device is already in use, thus generating another bug.

For this specific bug, though, I'll mark it as rejected, since another solution was applied (i.e. changed the rngd behavior).

Comment 11 RHEL Program Management 2014-03-22 06:58:23 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 12 azazelahh 2014-05-20 00:11:09 UTC
Can someone help me out and tell me how to do this?

"rngd's default command line should be modified to add --no-tpm=1"

What command should I execute to perform that step or what file do I need to edit?

Thanks.

Comment 13 IBM Bug Proxy 2014-09-18 12:43:49 UTC
------- Comment From gcwilson.com 2013-07-11 20:23 EDT-------

------- Comment From gcwilson.com 2013-07-15 17:14 EDT-------

------- Comment From gcwilson.com 2013-07-15 17:18 EDT-------

------- Comment From richardm.com 2013-07-18 00:35 EDT-------

------- Comment From gcwilson.com 2013-07-19 21:59 EDT-------

------- Comment From richardm.com 2014-03-04 18:52 EDT-------


Note You need to log in before you can comment on or make changes to this bug.