From: Jason Gunthorpe <jgg@ziepe.ca>
To: Ken Goldman <kgold@linux.vnet.ibm.com>
Cc: linux-integrity@vger.kernel.org
Subject: Re: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation fails
Date: Fri, 8 Dec 2017 13:18:35 -0700 [thread overview]
Message-ID: <20171208201835.GA10362@ziepe.ca> (raw)
In-Reply-To: <44ff3d81-809c-b8ea-ae27-42725ee0a9fc@linux.vnet.ibm.com>
On Fri, Dec 08, 2017 at 03:03:34PM -0500, Ken Goldman wrote:
> Do you really want to build in an every expanding list of commands that the
> kernel has to screen for? I don't think so.
We have to, it is required for securing unpriv access.
> Remember that there are new commands, optional commands, and vendor
> proprietary commands. What's the rationale for only looking at the command
> code and not rest of the parameters?
The TPM arch already split the commands in a way where you don't need
to look at params in most cases. I think we might, or should, look at
params in some of the 'get cap' cases ?
Jason
next prev parent reply other threads:[~2017-12-08 20:18 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-17 10:07 [RFC PATCH] tpm: don't return -EINVAL if TPM command validation fails Javier Martinez Canillas
2017-11-17 16:57 ` Jason Gunthorpe
2017-11-17 17:56 ` Javier Martinez Canillas
2017-11-17 17:58 ` Jason Gunthorpe
2017-11-17 18:10 ` Javier Martinez Canillas
2017-11-17 18:17 ` Jason Gunthorpe
2017-11-17 18:34 ` Javier Martinez Canillas
2017-11-17 19:14 ` Roberts, William C
2017-11-17 23:55 ` Jason Gunthorpe
2017-11-18 0:53 ` Javier Martinez Canillas
2017-11-19 15:27 ` Jason Gunthorpe
2017-11-20 9:26 ` Javier Martinez Canillas
2017-11-20 16:14 ` Roberts, William C
2017-11-20 18:02 ` Jason Gunthorpe
2017-11-20 18:04 ` Jason Gunthorpe
2017-12-08 20:03 ` Ken Goldman
2017-12-08 20:18 ` Jason Gunthorpe [this message]
2017-12-08 19:58 ` Ken Goldman
2017-11-20 23:15 ` Jarkko Sakkinen
2017-11-21 9:07 ` Javier Martinez Canillas
2017-11-21 9:27 ` Javier Martinez Canillas
2017-11-21 12:30 ` Jarkko Sakkinen
2017-11-21 12:49 ` Javier Martinez Canillas
[not found] ` <DB638850A6A2434A93ECADDA0BC838905F09D5D9@ORSMSX103.amr.corp.intel.com>
2017-11-22 17:16 ` FW: " flihp
2017-11-22 19:25 ` Javier Martinez Canillas
2017-11-26 14:21 ` Jarkko Sakkinen
2017-11-29 11:26 ` Javier Martinez Canillas
2017-11-22 20:13 ` Jason Gunthorpe
2017-12-08 20:16 ` Ken Goldman
2017-12-08 20:20 ` Jason Gunthorpe
2017-11-26 14:18 ` Jarkko Sakkinen
2017-11-26 23:23 ` Javier Martinez Canillas
2017-11-26 14:14 ` Jarkko Sakkinen
2017-11-21 20:29 ` Roberts, William C
2017-11-22 9:26 ` Javier Martinez Canillas
2017-11-26 14:12 ` Jarkko Sakkinen
2017-11-26 23:19 ` Javier Martinez Canillas
2017-12-08 20:11 ` Ken Goldman
2017-11-26 14:06 ` Jarkko Sakkinen
2017-12-08 20:20 ` Ken Goldman
2017-12-08 21:34 ` Javier Martinez Canillas
2017-12-17 16:47 ` Jarkko Sakkinen
2017-12-17 18:18 ` Javier Martinez Canillas
2017-12-22 17:38 ` Ken Goldman
2017-12-14 13:11 ` Jarkko Sakkinen
2017-12-08 19:51 ` Ken Goldman
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=20171208201835.GA10362@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=kgold@linux.vnet.ibm.com \
--cc=linux-integrity@vger.kernel.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox