On Thu, Oct 03, 2019 at 11:24:21AM -0400, Mimi Zohar wrote:
> On Thu, 2019-10-03 at 14:33 +0300, Jarkko Sakkinen wrote:
>
> > > > Will this delay the TPM initialization, causing IMA to go into "TPM
> > > > bypass mode"?
> > >
> > > Of course it will delay the init.
> > >
> > > As I've stated bef
On Thu, Oct 03, 2019 at 08:39:10AM -0400, Mimi Zohar wrote:
> On Thu, 2019-10-03 at 14:32 +0300, Jarkko Sakkinen wrote:
> > On Wed, Oct 02, 2019 at 08:40:24AM -0400, Mimi Zohar wrote:
> > > On Thu, 2019-09-26 at 16:12 +0300, Jarkko Sakkinen wrote:
> > > > On Thu, Sep 26, 2019 at 03:46:35PM +0300, J
On Thu, Oct 03, 2019 at 08:50:54AM -0400, Mimi Zohar wrote:
> On Thu, 2019-10-03 at 14:35 +0300, Jarkko Sakkinen wrote:
> > On Wed, Oct 02, 2019 at 08:41:45AM -0400, Mimi Zohar wrote:
> > > On Fri, 2019-09-27 at 16:06 +0300, Jarkko Sakkinen wrote:
> > > > On Wed, Sep 25, 2019 at 10:03:46AM -0400, J
On Thu, 2019-10-03 at 14:33 +0300, Jarkko Sakkinen wrote:
> > > Will this delay the TPM initialization, causing IMA to go into "TPM
> > > bypass mode"?
> >
> > Of course it will delay the init.
> >
> > As I've stated before the real fix for the bypass issue would be
> > to make TPM as part of th
On Thu, 2019-10-03 at 14:35 +0300, Jarkko Sakkinen wrote:
> On Wed, Oct 02, 2019 at 08:41:45AM -0400, Mimi Zohar wrote:
> > On Fri, 2019-09-27 at 16:06 +0300, Jarkko Sakkinen wrote:
> > > On Wed, Sep 25, 2019 at 10:03:46AM -0400, James Bottomley wrote:
> > > > On Wed, 2019-09-25 at 16:48 +0300, Jar
On Thu, 2019-10-03 at 14:32 +0300, Jarkko Sakkinen wrote:
> On Wed, Oct 02, 2019 at 08:40:24AM -0400, Mimi Zohar wrote:
> > On Thu, 2019-09-26 at 16:12 +0300, Jarkko Sakkinen wrote:
> > > On Thu, Sep 26, 2019 at 03:46:35PM +0300, Jarkko Sakkinen wrote:
> > > > On Wed, Sep 25, 2019 at 04:48:41PM +03
On Wed, Oct 02, 2019 at 08:41:45AM -0400, Mimi Zohar wrote:
> On Fri, 2019-09-27 at 16:06 +0300, Jarkko Sakkinen wrote:
> > On Wed, Sep 25, 2019 at 10:03:46AM -0400, James Bottomley wrote:
> > > On Wed, 2019-09-25 at 16:48 +0300, Jarkko Sakkinen wrote:
> > > [...]
> > > > + data_page = alloc_
On Thu, Oct 03, 2019 at 02:32:11PM +0300, Jarkko Sakkinen wrote:
> On Wed, Oct 02, 2019 at 08:40:24AM -0400, Mimi Zohar wrote:
> > On Thu, 2019-09-26 at 16:12 +0300, Jarkko Sakkinen wrote:
> > > On Thu, Sep 26, 2019 at 03:46:35PM +0300, Jarkko Sakkinen wrote:
> > > > On Wed, Sep 25, 2019 at 04:48:4
On Wed, Oct 02, 2019 at 08:40:24AM -0400, Mimi Zohar wrote:
> On Thu, 2019-09-26 at 16:12 +0300, Jarkko Sakkinen wrote:
> > On Thu, Sep 26, 2019 at 03:46:35PM +0300, Jarkko Sakkinen wrote:
> > > On Wed, Sep 25, 2019 at 04:48:41PM +0300, Jarkko Sakkinen wrote:
> > > > - tpm_buf_reset(&
On Fri, 2019-09-27 at 16:06 +0300, Jarkko Sakkinen wrote:
> On Wed, Sep 25, 2019 at 10:03:46AM -0400, James Bottomley wrote:
> > On Wed, 2019-09-25 at 16:48 +0300, Jarkko Sakkinen wrote:
> > [...]
> > > + data_page = alloc_page(GFP_HIGHUSER);
> > > + if (!data_page)
> > > + return -ENOMEM;
On Thu, 2019-09-26 at 16:12 +0300, Jarkko Sakkinen wrote:
> On Thu, Sep 26, 2019 at 03:46:35PM +0300, Jarkko Sakkinen wrote:
> > On Wed, Sep 25, 2019 at 04:48:41PM +0300, Jarkko Sakkinen wrote:
> > > - tpm_buf_reset(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_GET_RANDOM);
> > > + tpm_buf_res
On Sat, Sep 28, 2019 at 12:58:13AM -0700, Jerry Snitselaar wrote:
> TPM2_CC_GET_RANDOM
Ugh, I somehow sent v1 2nd time also in terms of contents (was fixed in
v2).
I think it would be a great idea to add call to tpm_get_random() to the
chip startup as an additional test.
> Would this work here?
On Thu Sep 26 19, Jarkko Sakkinen wrote:
As has been seen recently, binding the buffer allocation and tpm_buf
together is sometimes far from optimal. The buffer might come from the
caller namely when tpm_send() is used by another subsystem. In addition we
can stability in call sites w/o rollback
On Thu, Sep 26, 2019 at 08:23:24PM +0300, Jarkko Sakkinen wrote:
> As has been seen recently, binding the buffer allocation and tpm_buf
> together is sometimes far from optimal. The buffer might come from the
> caller namely when tpm_send() is used by another subsystem. In addition we
> can stabili
On Wed, Sep 25, 2019 at 10:03:46AM -0400, James Bottomley wrote:
> On Wed, 2019-09-25 at 16:48 +0300, Jarkko Sakkinen wrote:
> [...]
> > + data_page = alloc_page(GFP_HIGHUSER);
> > + if (!data_page)
> > + return -ENOMEM;
> > +
> > + data_ptr = kmap(data_page);
>
> I don't think thi
As has been seen recently, binding the buffer allocation and tpm_buf
together is sometimes far from optimal. The buffer might come from the
caller namely when tpm_send() is used by another subsystem. In addition we
can stability in call sites w/o rollback (e.g. power events)>
Take allocation out o
On Thu, Sep 26, 2019 at 03:46:35PM +0300, Jarkko Sakkinen wrote:
> On Wed, Sep 25, 2019 at 04:48:41PM +0300, Jarkko Sakkinen wrote:
> > - tpm_buf_reset(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_GET_RANDOM);
> > + tpm_buf_reset(&buf, data_ptr, PAGE_SIZE,
> > + TP
On Wed, Sep 25, 2019 at 04:48:41PM +0300, Jarkko Sakkinen wrote:
> - tpm_buf_reset(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_GET_RANDOM);
> + tpm_buf_reset(&buf, data_ptr, PAGE_SIZE,
> + TPM2_ST_NO_SESSIONS, TPM2_CC_PCR_EXTEND);
Oops.
/Jarkko
On Wed, 2019-09-25 at 16:48 +0300, Jarkko Sakkinen wrote:
[...]
> + data_page = alloc_page(GFP_HIGHUSER);
> + if (!data_page)
> + return -ENOMEM;
> +
> + data_ptr = kmap(data_page);
I don't think this is such a good idea. On 64 bit it's no different
from GFP_KERNEL and on
As has been seen recently, binding the buffer allocation and tpm_buf
together is sometimes far from optimal. The buffer might come from the
caller namely when tpm_send() is used by another subsystem. In addition we
can stability in call sites w/o rollback (e.g. power events)>
Take allocation out o
20 matches
Mail list logo
