Re: [tpmdd-devel] [PATCH v2 6/7] tpm: expose spaces via a device link /dev/tpms

On Fri, Feb 24, 2017 at 06:43:27PM -0500, James Bottomley wrote: > > It just seems confusing to call something a namespace that isn't also > > a CLONE_NEW* option.. > > Well, there's namespace behaviour and then there's how you enter them. > We have namespace behaviour with the /dev/tpms but

Re: [tpmdd-devel] [PATCH v2 6/7] tpm: expose spaces via a device link /dev/tpms

On Fri, 2017-02-24 at 16:23 -0700, Jason Gunthorpe wrote: > On Fri, Feb 24, 2017 at 06:01:00PM -0500, James Bottomley wrote: > > > Well, as a glib answer, I'd say the TPM is a device, so the thing > > which restricts device access to containers is the device cgroup > > ... that's what we should

Re: [tpmdd-devel] [PATCH v2 6/7] tpm: expose spaces via a device link /dev/tpms

On Fri, Feb 24, 2017 at 06:01:00PM -0500, James Bottomley wrote: > Well, as a glib answer, I'd say the TPM is a device, so the thing which > restricts device access to containers is the device cgroup ... that's > what we should be plugging into. I'd have to look, but I suspect the > device

Re: [tpmdd-devel] [PATCH v2 6/7] tpm: expose spaces via a device link /dev/tpms

On Fri, 2017-02-24 at 13:52 -0700, Jason Gunthorpe wrote: > On Fri, Feb 24, 2017 at 03:29:15PM -0500, James Bottomley wrote: > > On Fri, 2017-02-24 at 11:11 -0700, Jason Gunthorpe wrote: > > > On Fri, Feb 24, 2017 at 07:39:22PM +0200, Jarkko Sakkinen wrote: > > > > > > > > I think therefore that

Re: [tpmdd-devel] [PATCH] tpm crb: Work around BIOS's that report the wrong ACPI region size

> On 24 Feb 2017, at 1:02 pm, Jarkko Sakkinen > wrote: > > On Tue, Feb 21, 2017 at 02:14:24PM -0700, Jason Gunthorpe wrote: >> The expectation is that the if the CRB cmd/rsp buffer falls within the >> ACPI region that the entire buffer will be within the

Re: [tpmdd-devel] [PATCH] tpm: Use the right clean up after cdev_add completes

On Fri, Feb 24, 2017 at 10:59:50PM +0200, Jarkko Sakkinen wrote: > On Fri, Feb 24, 2017 at 07:43:54PM +0200, Jarkko Sakkinen wrote: > > On Thu, Feb 23, 2017 at 02:19:14PM -0700, Jason Gunthorpe wrote: > > > Once cdev_add is done the device node is visible to user space and > > > could have been

Re: [tpmdd-devel] [PATCH] tpm: Use the right clean up after cdev_add completes

On Fri, Feb 24, 2017 at 07:43:54PM +0200, Jarkko Sakkinen wrote: > On Thu, Feb 23, 2017 at 02:19:14PM -0700, Jason Gunthorpe wrote: > > Once cdev_add is done the device node is visible to user space and > > could have been opened. Thus we have to go through the locking > > process in

Re: [tpmdd-devel] [PATCH v2 6/7] tpm: expose spaces via a device link /dev/tpms

On Fri, Feb 24, 2017 at 03:29:15PM -0500, James Bottomley wrote: > On Fri, 2017-02-24 at 11:11 -0700, Jason Gunthorpe wrote: > > On Fri, Feb 24, 2017 at 07:39:22PM +0200, Jarkko Sakkinen wrote: > > > > > > I think therefore that tpmns for TPM Namespace would be very > > > > appropriate. > > > >

Re: [tpmdd-devel] [PATCH v2 6/7] tpm: expose spaces via a device link /dev/tpms

On Fri, 2017-02-24 at 11:11 -0700, Jason Gunthorpe wrote: > On Fri, Feb 24, 2017 at 07:39:22PM +0200, Jarkko Sakkinen wrote: > > > > I think therefore that tpmns for TPM Namespace would be very > > > appropriate. > > > > Makes sense. We can go with tpmns. > > When we have talked about TPM

[tpmdd-devel] [RFT PATCH] tpm: ibmvtpm: simplify crq initialization and document crq format

The crq is passed in registers and is the same on BE and LE hosts. However, current implementation allocates a structure on-stack to represent the crq, initializes the members swapping them to BE, and loads the structure swapping it from BE. This is pointless and causes GCC warnings about

Re: [tpmdd-devel] [PATCH v2 6/7] tpm: expose spaces via a device link /dev/tpms

On Fri, Feb 24, 2017 at 07:39:22PM +0200, Jarkko Sakkinen wrote: > > I think therefore that tpmns for TPM Namespace would be very > > appropriate. > > Makes sense. We can go with tpmns. When we have talked about TPM namespaces in the past it has been around the idea of restricting which TPMs

Re: [tpmdd-devel] [PATCH] tpm: Use the right clean up after cdev_add completes

On Thu, Feb 23, 2017 at 02:19:14PM -0700, Jason Gunthorpe wrote: > Once cdev_add is done the device node is visible to user space and > could have been opened. Thus we have to go through the locking > process in tpm_del_char_device if device_add fails. > > Fixes: 2c91ce8523a ("tpm: fix the

Re: [tpmdd-devel] [PATCH] tpm crb: Work around BIOS's that report the wrong ACPI region size

On Tue, Feb 21, 2017 at 02:14:24PM -0700, Jason Gunthorpe wrote: > The expectation is that the if the CRB cmd/rsp buffer falls within the > ACPI region that the entire buffer will be within the reason. Otherwise > resource reservation will fail when it crosses regions. > > Work around this BIOS

Re: [tpmdd-devel] [PATCH] tpm_tis_core: Choose appropriate timeout for reading burstcount

On Thu, Feb 16, 2017 at 03:33:36PM +, Peter Huewe wrote: > From: Alexander Steffen > > TIS v1.3 for TPM 1.2 and PTP for TPM 2.0 disagree about which timeout > value applies to reading a valid burstcount. It is TIMEOUT_D according to > TIS, but TIMEOUT_A

Re: [tpmdd-devel] [PATCH v2 4/7] tpm: infrastructure for TPM spaces

On Fri, Feb 24, 2017 at 07:53:22AM -0500, James Bottomley wrote: > On Thu, 2017-02-16 at 21:25 +0200, Jarkko Sakkinen wrote: > > Added an ability to virtualize TPM commands into an isolated context > > that we call a TPM space because the word context is already heavily > > used in the TPM

Re: [tpmdd-devel] [RFC PATCH] tpm: msleep() delays - replace with usleep_range() in i2c nuvoton driver

On Thu, Feb 23, 2017 at 06:46:18PM -0500, Mimi Zohar wrote: > Commit 500462a9de65 "timers: Switch to a non-cascading wheel" replaced > the 'classic' timer wheel, which aimed for near 'exact' expiry of the > timers. Their analysis was that the vast majority of timeout timers > are used as

Re: [tpmdd-devel] [PATCH] tpm crb: Work around BIOS's that report the wrong ACPI region size

On Tue, Feb 21, 2017 at 02:14:24PM -0700, Jason Gunthorpe wrote: > The expectation is that the if the CRB cmd/rsp buffer falls within the > ACPI region that the entire buffer will be within the reason. Otherwise > resource reservation will fail when it crosses regions. > > Work around this BIOS

Re: [tpmdd-devel] [PATCH v2 6/7] tpm: expose spaces via a device link /dev/tpms

On Thu, 2017-02-23 at 11:09 +0200, Jarkko Sakkinen wrote: > On Thu, Feb 16, 2017 at 09:25:19PM +0200, Jarkko Sakkinen wrote: > > From: James Bottomley > > > > Currently the tpm spaces are not exposed to userspace. Make this > > exposure via a separate

Re: [tpmdd-devel] [PATCH 4/5] tpm_tis_spi: Remove limitation of transfers to MAX_SPI_FRAMESIZE bytes

On Thu, Feb 16, 2017 at 04:08:25PM +, Peter Huewe wrote: > Limiting transfers to MAX_SPI_FRAMESIZE was not expected by the upper > layers, as tpm_tis has no such limitation. Add a loop to hide that > limitation. > > Cc: > Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add

Re: [tpmdd-devel] [PATCH 3/5] tpm_tis_spi: Check correct byte for wait state indicator

On Thu, Feb 16, 2017 at 04:08:24PM +, Peter Huewe wrote: > Wait states are signaled in the last byte received from the TPM in > response to the header, not the first byte. Check rx_buf[3] instead of > rx_buf[0]. > > Cc: > Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add

Re: [tpmdd-devel] [PATCH 2/5] tpm_tis_spi: Abort transfer when too many wait states are signaled

On Thu, Feb 16, 2017 at 04:08:23PM +, Peter Huewe wrote: > Abort the transfer with ETIMEDOUT when the TPM signals more than > TPM_RETRY wait states. Continuing with the transfer in this state > will only lead to arbitrary failures in other parts of the code. > > Cc: >

Re: [tpmdd-devel] [PATCH 1/5] tpm_tis_spi: Use single function to transfer data

On Thu, Feb 16, 2017 at 04:08:22PM +, Peter Huewe wrote: > The algorithm for sending data to the TPM is mostly identical to the > algorithm for receiving data from the TPM, so a single function is > sufficient to handle both cases. > > This is a prequisite for all the other fixes, so we don't

Re: [tpmdd-devel] [PATCH v2 6/7] tpm: expose spaces via a device link /dev/tpms

On Fri, 2017-02-24 at 12:29 +0530, Nayna wrote: > > On 02/17/2017 12:55 AM, Jarkko Sakkinen wrote: > > From: James Bottomley > > > > Currently the tpm spaces are not exposed to userspace. Make this > > exposure via a separate device, which can now be

Re: [tpmdd-devel] [PATCH 4/5] tpm_tis_spi: Remove limitation of transfers to MAX_SPI_FRAMESIZE bytes

On Thu, Feb 16, 2017 at 04:08:25PM +, Peter Huewe wrote: > Limiting transfers to MAX_SPI_FRAMESIZE was not expected by the upper > layers, as tpm_tis has no such limitation. Add a loop to hide that > limitation. > > Cc: > Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add