Re: [RFC 0/2] add integrity and security to TPM2 transactions

On Fri, Mar 02, 2018 at 10:04:54PM -0800, James Bottomley wrote: > By now, everybody knows we have a problem with the TPM2_RS_PW easy > button on TPM2 in that transactions on the TPM bus can be intercepted > and altered.  The way to fix this is to use real sessions for HMAC > capabilities to

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

On Thu, Nov 09, 2017 at 09:49:33PM +0530, PrasannaKumar Muralidharan wrote: > Hi Jason, > > On 7 November 2017 at 21:34, Jason Gunthorpe <j...@ziepe.ca> wrote: > > On Tue, Nov 07, 2017 at 08:50:44AM +0530, PrasannaKumar Muralidharan wrote: > > > >>

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

On Tue, Nov 07, 2017 at 08:50:44AM +0530, PrasannaKumar Muralidharan wrote: > I am assuming you are talking about the following patches - using > struct tpm_chip instead of chip number and this patch. yes > I won't be able to test if struct tpm_chip usage as I don't have > multiple tpm hw in

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

On Sun, Nov 05, 2017 at 01:05:06PM +0200, Jarkko Sakkinen wrote: > I asked to create a series for a reason. Now this doesn't apply because I > don't have an ancestor in my git history. It would be unusual for me to put your patch into a series unless I am also adopting it. eg what happens if

[PATCH v2] tpm: Move Linux RNG connection to hwrng

Muralidharan <prasannatsmku...@gmail.com> Signed-off-by: Jason Gunthorpe <jguntho...@obsidianresearch.com> --- drivers/char/hw_random/Kconfig | 13 --- drivers/char/hw_random/Makefile | 1 - drivers/char/hw_random/tpm-rng.c | 50 drivers/char

Re: [PATCH v3] tpm: use struct tpm_chip for tpm_chip_find_get()

ay that instead a struct tpm_chip > instance is given and NULL means the default chip. In addition, this > commit refines the documentation to be up to date with the > implementation. > > Suggested-by: Jason Gunthorpe <jguntho...@obsidianresearch.com> (@chip_num -> &g

Re: [PATCH v3] tpm: use struct tpm_chip for tpm_chip_find_get()

On Thu, Oct 26, 2017 at 09:57:12PM +0530, PrasannaKumar Muralidharan wrote: > I do not what value my rb tag provides as I have not contributed code > to it before. Is it encouraged by kernel community? Yes. People will judge the quality of your rb tag based on other reviews they have seen you

Re: [PATCH v2] tpm: use struct tpm_chip for tpm_chip_find_get()

On Wed, Oct 25, 2017 at 10:07:46PM +0200, Jarkko Sakkinen wrote: > The id has a nice feature that it is unique for one boot cycle you can > even try to get a chip that has been deleted. It has the most stable > properties in the long run. It isn't unique, we can re-use ids them via idr_alloc().

Re: [PATCH] tpm: Move Linux RNG connection to hwrng

On Wed, Oct 25, 2017 at 10:00:30PM +0200, Jarkko Sakkinen wrote: > A minor tidbit: could the tpm_ prefix removed from those fields? Yes, in v2 I will send v2 when you land your rework patch as this will depend on it. Jason

Re: [PATCH v2] tpm: use struct tpm_chip for tpm_chip_find_get()

> struct tpm_chip *tpm_chip_find_get(u64 id) > { > struct tpm_chup *chip; > struct tpm_chip *res = NULL; > int chip_num = 0; > int chip_prev; > > mutex_lock(_lock); > > do { > chip_prev = chip_num; > > chip =

Re: [PATCH] tpm: Move Linux RNG connection to hwrng

On Wed, Oct 25, 2017 at 08:58:17PM +0200, Jarkko Sakkinen wrote: > On Wed, Oct 25, 2017 at 08:15:09PM +0530, PrasannaKumar Muralidharan wrote: > > > + if (!IS_ENABLED(CONFIG_HW_RANDOM_TPM)) > > > + return 0; > > > > Can #ifndef CONFIG_HW_RANDOM_TPM be used instead? That way an

Re: [PATCH v2] tpm: use struct tpm_chip for tpm_chip_find_get()

ay that instead a struct tpm_chip > instance is given and NULL means the default chip. In addition, this > commit refines the documentation to be up to date with the > implementation. > > Suggested-by: Jason Gunthorpe <jguntho...@obsidianresearch.com> (@chip_num -> &g

Re: [PATCH] tpm: Move Linux RNG connection to hwrng

On Wed, Oct 25, 2017 at 08:15:09PM +0530, PrasannaKumar Muralidharan wrote: > > +static int tpm_add_hwrng(struct tpm_chip *chip) > > +{ > > + if (!IS_ENABLED(CONFIG_HW_RANDOM_TPM)) > > + return 0; > > Can #ifndef CONFIG_HW_RANDOM_TPM be used instead? That way an if >

Re: [PATCH] tpm: Move Linux RNG connection to hwrng

On Tue, Oct 24, 2017 at 12:42:35PM -0600, Jason Gunthorpe wrote: > This is compile tested only. 0day says the kconfig has a problem when randomized, here is the fix I will roll into a v2 in a few days: diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig index a95725fa777

Re: [PATCH] tpm: remove chip_num parameter from in-kernel API

On Mon, Oct 23, 2017 at 02:38:14PM +0200, Jarkko Sakkinen wrote: > The reasoning is simple and obvious. Since every call site passes the > value TPM_ANY_NUM (0x) the parameter does not have right to exist. > Refined the documentation of the corresponding functions. I like this patch, but how

[PATCH] tpm: Move Linux RNG connection to hwrng

Muralidharan <prasannatsmku...@gmail.com> Signed-off-by: Jason Gunthorpe <jguntho...@obsidianresearch.com> Reviewed-by: Jason Gunthorpe <jguntho...@obsidianresearch.com> --- drivers/char/hw_random/Kconfig | 13 --- drivers/char/hw_random/Makefile | 1 - drivers/char/hw_ran

Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from in-kernel API

On Tue, Oct 24, 2017 at 09:44:30PM +0530, PrasannaKumar Muralidharan wrote: > I am wondering why it is wrong. Isn't the chip id valid till it is > unregistered? If so the rfc is correct. Please explain, may be I am > missing something. The lifetime is a bit complicated, but the general rule in

Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from in-kernel API

On Tue, Oct 24, 2017 at 10:02:00AM -0700, Dmitry Torokhov wrote: > tpm-rng is abomination that should be kicked out as soon as possible. > It wrecks havoc with the power management (TPM chip drivers may go > into suspend state, but tpm_rng does not do any power management and > happily forwards

Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from in-kernel API

On Tue, Oct 24, 2017 at 09:37:33PM +0530, PrasannaKumar Muralidharan wrote: > Hi Jason, > > On 24 October 2017 at 21:25, Jason Gunthorpe > <jguntho...@obsidianresearch.com> wrote: > > On Tue, Oct 24, 2017 at 09:21:15PM +0530, PrasannaKumar Muralidharan wrote: > >

Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from in-kernel API

On Tue, Oct 24, 2017 at 09:21:15PM +0530, PrasannaKumar Muralidharan wrote: > Please check the RFC [1]. It does use chip id. The rfc has issues and > has to be fixed but still there could be users of the API. > > 1. https://www.spinics.net/lists/linux-crypto/msg28282.html That patch isn't safe

Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from in-kernel API

On Mon, Oct 23, 2017 at 10:07:31AM -0400, Stefan Berger wrote: > >-int tpm_pcr_extend(u32 chip_num, int pcr_idx, const u8 *hash) > >+int tpm_pcr_extend(int pcr_idx, const u8 *hash) > > { > > > I think every kernel internal TPM driver API should be called with the > tpm_chip as a parameter.

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On Thu, Apr 27, 2017 at 05:03:45PM -0600, Logan Gunthorpe wrote: > > > On 27/04/17 04:11 PM, Jason Gunthorpe wrote: > > On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote: > > Well, that is in the current form, with more users it would make sense > > to o

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote: > On 27/04/17 02:53 PM, Jason Gunthorpe wrote: > > blkfront is one of the drivers I looked at, and it appears to only be > > memcpying with the bvec_data pointer, so I wonder why it does not use > > sg_

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On Thu, Apr 27, 2017 at 02:19:24PM -0600, Logan Gunthorpe wrote: > > > On 26/04/17 01:37 AM, Roger Pau Monné wrote: > > On Tue, Apr 25, 2017 at 12:21:02PM -0600, Logan Gunthorpe wrote: > >> Straightforward conversion to the new helper, except due to the lack > >> of error path, we have to use

Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On Thu, Apr 27, 2017 at 08:53:38AM +0200, Christoph Hellwig wrote: > > The main difficulty we > > have now is that neither of those functions are expected to fail and we > > need them to be able to in cases where the page doesn't map to system > > RAM. This patch series is trying to address it

Re: [PATCH] hwrng: meson: Fix module autoload for OF registration

On Mon, Oct 17, 2016 at 04:40:14PM -0300, Javier Martinez Canillas wrote: > Signed-off-by: Javier Martinez Canillas > > drivers/char/hw_random/meson-rng.c | 1 + > drivers/char/tpm/Kconfig | 2 +- Looks like this patch should not have tpm in it. Jason -- To

Re: [PATCH v1.2 3/4] keys: add new trusted key-type

On Mon, Nov 08, 2010 at 10:30:45AM -0500, Mimi Zohar wrote: pcrlock=nextends the designated PCR 'n' with a random value, so that a key sealed to that PCR may not be unsealed again until after a reboot. Nice, but this seems very strange to me, since it has nothing

Re: [PATCH v1.2 3/4] keys: add new trusted key-type

On Mon, Nov 08, 2010 at 01:18:33PM -0500, David Safford wrote: This is strictly for convenience in initramfs, so that the trusted key can be loaded and locked in a single command, with no need for an additional application to extend a PCR. As the the TPM driver already has support for