From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> To: Stefan Berger <stefanb@linux.vnet.ibm.com> Cc: tpmdd-devel@lists.sourceforge.net, linux-security-module@vger.kernel.org, jarkko.sakkinen@linux.intel.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/3] tpm: vtpm_proxy: Implement new ioctl to get supported flags Date: Thu, 4 May 2017 11:20:42 -0600 [thread overview] Message-ID: <20170504172042.GA19932@obsidianresearch.com> (raw) In-Reply-To: <56703d75-b238-0bad-386a-5b6963e250a1@linux.vnet.ibm.com> On Thu, May 04, 2017 at 01:13:18PM -0400, Stefan Berger wrote: > On 05/04/2017 11:34 AM, Jason Gunthorpe wrote: > >On Thu, May 04, 2017 at 10:56:25AM -0400, Stefan Berger wrote: > >>Implement VTPM_PROXY_IOC_GET_SUPT_FLAGS ioctl to get the bitmask > >>of flags that the vtpm_proxy driver supports in the > >>VTPM_PROXY_IOC_NEW_DEV ioctl. This helps user space in deciding > >>which flags to set in that ioctl. > >you might be better off just having a VTPM_PROXY_IO_ENABLE_FEATURE > >.feature = LOCALITY > > Do you have an example driver that shows how to do this ? Can user space > query that feature? Try and enable the feature, if it fails then there is no feature in the kernel. This is the usual way to add new syscalls.. > >If that fails then the feature is not supported, no real need for the > >query in that case. > > > >Not sure about Jarkko's point on request/release locality.. Is there a > >scenario where the emulator should fail the request locality? > > We could filter localities 5 and higher on the level of the driver (patch > 2/3) since basically there are only 5 localities (0-4) in any TPM interface > today. The typical hardware locality 4 would be filtered by the emulator per > policy passed via command line, but I would allow it on the level of this > driver. An error message would be returned for any command executed in that > locality, unless the 'policy' allows it. Localities 0-3 should just be > selectable. The TPM TIS (in the hardware) implements some complicated scheme > when it comes to allowing the selection of a locality and I would say we > need none of that but just tell the vTPM proxy driver the locality (patch > 2/3) in which the next command will be executed. Well, if TIS hardware has some scheme I feel like the emulator uAPI should have enough fidelity to ecompass existing hardware, even if your current emulator does not need it. So allowing request_locality to fail from userspace seems reasonable. Jason
WARNING: multiple messages have this Message-ID (diff)
From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe) To: linux-security-module@vger.kernel.org Subject: [PATCH v3 1/3] tpm: vtpm_proxy: Implement new ioctl to get supported flags Date: Thu, 4 May 2017 11:20:42 -0600 [thread overview] Message-ID: <20170504172042.GA19932@obsidianresearch.com> (raw) In-Reply-To: <56703d75-b238-0bad-386a-5b6963e250a1@linux.vnet.ibm.com> On Thu, May 04, 2017 at 01:13:18PM -0400, Stefan Berger wrote: > On 05/04/2017 11:34 AM, Jason Gunthorpe wrote: > >On Thu, May 04, 2017 at 10:56:25AM -0400, Stefan Berger wrote: > >>Implement VTPM_PROXY_IOC_GET_SUPT_FLAGS ioctl to get the bitmask > >>of flags that the vtpm_proxy driver supports in the > >>VTPM_PROXY_IOC_NEW_DEV ioctl. This helps user space in deciding > >>which flags to set in that ioctl. > >you might be better off just having a VTPM_PROXY_IO_ENABLE_FEATURE > >.feature = LOCALITY > > Do you have an example driver that shows how to do this ? Can user space > query that feature? Try and enable the feature, if it fails then there is no feature in the kernel. This is the usual way to add new syscalls.. > >If that fails then the feature is not supported, no real need for the > >query in that case. > > > >Not sure about Jarkko's point on request/release locality.. Is there a > >scenario where the emulator should fail the request locality? > > We could filter localities 5 and higher on the level of the driver (patch > 2/3) since basically there are only 5 localities (0-4) in any TPM interface > today. The typical hardware locality 4 would be filtered by the emulator per > policy passed via command line, but I would allow it on the level of this > driver. An error message would be returned for any command executed in that > locality, unless the 'policy' allows it. Localities 0-3 should just be > selectable. The TPM TIS (in the hardware) implements some complicated scheme > when it comes to allowing the selection of a locality and I would say we > need none of that but just tell the vTPM proxy driver the locality (patch > 2/3) in which the next command will be executed. Well, if TIS hardware has some scheme I feel like the emulator uAPI should have enough fidelity to ecompass existing hardware, even if your current emulator does not need it. So allowing request_locality to fail from userspace seems reasonable. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-05-04 17:20 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-05-04 14:56 [PATCH v3 0/3] Extend the vTPM proxy driver to pass locality Stefan Berger 2017-05-04 14:56 ` Stefan Berger 2017-05-04 14:56 ` [PATCH v3 1/3] tpm: vtpm_proxy: Implement new ioctl to get supported flags Stefan Berger 2017-05-04 14:56 ` Stefan Berger 2017-05-04 14:56 ` Stefan Berger 2017-05-04 15:34 ` Jason Gunthorpe 2017-05-04 15:34 ` Jason Gunthorpe 2017-05-04 15:34 ` Jason Gunthorpe 2017-05-04 17:13 ` Stefan Berger 2017-05-04 17:13 ` Stefan Berger 2017-05-04 17:20 ` Jason Gunthorpe [this message] 2017-05-04 17:20 ` Jason Gunthorpe 2017-05-04 17:28 ` Stefan Berger 2017-05-04 17:28 ` Stefan Berger 2017-05-04 17:31 ` Jason Gunthorpe 2017-05-04 17:31 ` Jason Gunthorpe 2017-05-04 17:33 ` Stefan Berger 2017-05-04 17:33 ` Stefan Berger 2017-05-04 14:56 ` [PATCH v3 2/3] tpm: vtpm_proxy: Implement request_locality function Stefan Berger 2017-05-04 14:56 ` Stefan Berger 2017-05-04 14:56 ` Stefan Berger 2017-05-04 14:56 ` [PATCH v3 3/3] tpm: vtpm_proxy: Add flag for ioctl to request locality prepended to command Stefan Berger 2017-05-04 14:56 ` Stefan Berger
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=20170504172042.GA19932@obsidianresearch.com \ --to=jgunthorpe@obsidianresearch.com \ --cc=jarkko.sakkinen@linux.intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=stefanb@linux.vnet.ibm.com \ --cc=tpmdd-devel@lists.sourceforge.net \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.