[GIT PULL] TPM updates for v4.14

[GIT PULL] TPM updates for v4.14

[James Morris]

Here are the TPM updates from Jarkko for v4.14, which I've placed in their 
own branch (next-tpm).  I ended up cherry-picking them as other changes 
had been made in Jarkko's branch after he sent me his original pull 
request.

I plan on maintaining a separate branch for TPM (and other security 
subsystems) from now on.

>From Jarkko: "Not much this time except a few fixes." 

Please pull.

---

The following changes since commit 53a2ebaaabc1eb8458796fec3bc1e0e80746b642:

  sync to Linus v4.13-rc2 for subsystem developers to work against (2017-07-25 10:44:18 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-tpm

for you to fetch changes up to fb154e0e0a95249459df054241a9e8f4cca56062:

  tpm: ibmvtpm: simplify crq initialization and document crq format (2017-09-23 21:51:38 -0700)

----------------------------------------------------------------
Arvind Yadav (2):
      tpm: vtpm: constify vio_device_id
      tpm: tpm_crb: constify acpi_device_id.

Enric Balletbo i Serra (1):
      Documentation: tpm: add powered-while-suspended binding documentation

Hamza Attak (1):
      tpm: replace msleep() with  usleep_range() in TPM 1.2/2.0 generic drivers

Michal Suchanek (1):
      tpm: ibmvtpm: simplify crq initialization and document crq format

 .../devicetree/bindings/security/tpm/tpm-i2c.txt   |  6 ++
 drivers/char/tpm/tpm-interface.c                   | 10 +--
 drivers/char/tpm/tpm.h                             |  9 +-
 drivers/char/tpm/tpm2-cmd.c                        |  2 +-
 drivers/char/tpm/tpm_crb.c                         |  2 +-
 drivers/char/tpm/tpm_ibmvtpm.c                     | 98 ++++++++++++++--------
 drivers/char/tpm/tpm_infineon.c                    |  6 +-
 drivers/char/tpm/tpm_tis_core.c                    |  8 +-
 8 files changed, 89 insertions(+), 52 deletions(-)

--
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

Security updates for v4.15 and beyond

[Casey Schaufler]

On 9/23/2017 10:00 PM, James Morris wrote:
> <snip>
>
> I plan on maintaining a separate branch for TPM (and other security 
> subsystems) from now on.

Can you tell us how you expect this to work? I know
there was discussion about this at the Security Summit.
We need to get whatever needs doing lined up if we're
going to make 4.15 happen smoothly.

Thank you


.
--
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

Security updates for v4.15 and beyond

[James Morris]

On Sun, 24 Sep 2017, Casey Schaufler wrote:

> On 9/23/2017 10:00 PM, James Morris wrote:
> > <snip>
> >
> > I plan on maintaining a separate branch for TPM (and other security 
> > subsystems) from now on.
> 
> Can you tell us how you expect this to work? I know
> there was discussion about this at the Security Summit.
> We need to get whatever needs doing lined up if we're
> going to make 4.15 happen smoothly.

I'll post a more detailed and general update in a few days when I'm back 
in Sydney, but briefly, send me a pull request against my next-general 
branch, which replaces the 'next' branch.  I'll sync that to -rc2 after 
this email.

I'll fetch your branch into my next-smack branch, which will track 
next-general.

All of these subsystem branches and next-general will be merged into 
next-testing, for use by Stephen Rothwell for linux-next, and any other 
general testing which may be done.

When the merge window opens, I'll merge the subsystem branches into 
next-for-linus for him to pull.  If all is going well, this will be the 
same as next-testing.  If there are problems in any of the branches, they 
can be left out of next-for-linus until they're resolved.

Linus can then pull from that to get everything at once, or pull individual 
branches as he sees fit.

In summary: track my next-general branch instead of 'next', and your 
workflow is otherwise unchanged.

How does that sound?


-- 
James Morris
<jmorris@namei.org>

--
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

Security updates for v4.15 and beyond

[Paul Moore]

On Mon, Sep 25, 2017 at 12:59 AM, James Morris <jmorris@namei.org> wrote:
> On Sun, 24 Sep 2017, Casey Schaufler wrote:
>> On 9/23/2017 10:00 PM, James Morris wrote:
>> > <snip>
>> >
>> > I plan on maintaining a separate branch for TPM (and other security
>> > subsystems) from now on.
>>
>> Can you tell us how you expect this to work? I know
>> there was discussion about this at the Security Summit.
>> We need to get whatever needs doing lined up if we're
>> going to make 4.15 happen smoothly.
>
> I'll post a more detailed and general update in a few days when I'm back
> in Sydney, but briefly, send me a pull request against my next-general
> branch, which replaces the 'next' branch.  I'll sync that to -rc2 after
> this email.
>
> I'll fetch your branch into my next-smack branch, which will track
> next-general.
>
> All of these subsystem branches and next-general will be merged into
> next-testing, for use by Stephen Rothwell for linux-next, and any other
> general testing which may be done.
>
> When the merge window opens, I'll merge the subsystem branches into
> next-for-linus for him to pull.  If all is going well, this will be the
> same as next-testing.  If there are problems in any of the branches, they
> can be left out of next-for-linus until they're resolved.
>
> Linus can then pull from that to get everything at once, or pull individual
> branches as he sees fit.
>
> In summary: track my next-general branch instead of 'next', and your
> workflow is otherwise unchanged.
>
> How does that sound?

Considering Linus' comments about him preferring individual branches,
I'm questioning the value in going through the linux-security tree; at
least for the larger, frequently updated LSMs; there is likely still
value in terms of convenience for the smaller, more static pieces
(e.g. capabilities, Yama, etc.).  I know there is the argument about
cross-LSM changes, but I can speak from experience (the SELinux next
branch feeds directly into the linux-next tree) that this tends not to
be a large problem.  I worry more about breakage caused by failed
interactions with the network stack than I do with other LSMs.  Yes,
there is the stacking work, and that will definitely have an impact,
but I think we can all agree that changes like this are going to be
rather rare, and I think we can also agree that the stacking work is
going to require a good deal of cross-LSM coordination regardless of
how the trees are organized.

>From what Linus has said, and done, during the last merge window, I
suspect the "next-for-linus" branch is a waste of time, he would
prefer to pull from the individual branches and if he is pulling from
the individual subsystem branches, why not just pull from the
individual subsystem trees?  Help me understand the value, because
right now all I can see is an extra hop and another place where things
could fail.  As for linux-next, last time I spoke to them about it
(which was admittedly many years ago) they preferred to pull directly
from the subsystem trees; I know SELinux feeds directly into
linux-next, and I believe a few other LSMs do the same.

-- 
paul moore
www.paul-moore.com
--
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

Security updates for v4.15 and beyond

[John Johansen]

On 09/25/2017 06:32 AM, Paul Moore wrote:
> On Mon, Sep 25, 2017 at 12:59 AM, James Morris <jmorris@namei.org> wrote:
>> On Sun, 24 Sep 2017, Casey Schaufler wrote:
>>> On 9/23/2017 10:00 PM, James Morris wrote:
>>>> <snip>
>>>>
>>>> I plan on maintaining a separate branch for TPM (and other security
>>>> subsystems) from now on.
>>>
>>> Can you tell us how you expect this to work? I know
>>> there was discussion about this at the Security Summit.
>>> We need to get whatever needs doing lined up if we're
>>> going to make 4.15 happen smoothly.
>>
>> I'll post a more detailed and general update in a few days when I'm back
>> in Sydney, but briefly, send me a pull request against my next-general
>> branch, which replaces the 'next' branch.  I'll sync that to -rc2 after
>> this email.
>>
>> I'll fetch your branch into my next-smack branch, which will track
>> next-general.
>>
>> All of these subsystem branches and next-general will be merged into
>> next-testing, for use by Stephen Rothwell for linux-next, and any other
>> general testing which may be done.
>>
>> When the merge window opens, I'll merge the subsystem branches into
>> next-for-linus for him to pull.  If all is going well, this will be the
>> same as next-testing.  If there are problems in any of the branches, they
>> can be left out of next-for-linus until they're resolved.
>>
>> Linus can then pull from that to get everything at once, or pull individual
>> branches as he sees fit.
>>
>> In summary: track my next-general branch instead of 'next', and your
>> workflow is otherwise unchanged.
>>
>> How does that sound?
> 
> Considering Linus' comments about him preferring individual branches,
> I'm questioning the value in going through the linux-security tree; at
> least for the larger, frequently updated LSMs; there is likely still
> value in terms of convenience for the smaller, more static pieces
> (e.g. capabilities, Yama, etc.).  I know there is the argument about
> cross-LSM changes, but I can speak from experience (the SELinux next
> branch feeds directly into the linux-next tree) that this tends not to
> be a large problem.  I worry more about breakage caused by failed
> interactions with the network stack than I do with other LSMs.  Yes,
> there is the stacking work, and that will definitely have an impact,
> but I think we can all agree that changes like this are going to be
> rather rare, and I think we can also agree that the stacking work is
> going to require a good deal of cross-LSM coordination regardless of
> how the trees are organized.
> 
>>From what Linus has said, and done, during the last merge window, I
> suspect the "next-for-linus" branch is a waste of time, he would
> prefer to pull from the individual branches and if he is pulling from
> the individual subsystem branches, why not just pull from the
> individual subsystem trees?  Help me understand the value, because
> right now all I can see is an extra hop and another place where things
> could fail.  As for linux-next, last time I spoke to them about it
> (which was admittedly many years ago) they preferred to pull directly
> from the subsystem trees; I know SELinux feeds directly into
> linux-next, and I believe a few other LSMs do the same.
> 

I have to agree with Paul here, unless there are infrastructure
changes this feels like an extra hop. With next directly pulling
security (for infrastructure) and LSM changes merge conflicts will
show up there. At which point we are going to need to coordinate,
but these should be rare.

--
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

Security updates for v4.15 and beyond

[James Morris]

On Tue, 26 Sep 2017, John Johansen wrote:

> I have to agree with Paul here, unless there are infrastructure
> changes this feels like an extra hop. With next directly pulling
> security (for infrastructure) and LSM changes merge conflicts will
> show up there. At which point we are going to need to coordinate,
> but these should be rare.

Ok, it seems a consensus is emerging to go with Paul's idea of having 
larger, frequently updated LSMs merge directly to Linus.  If Linus is okay 
with that (I'm assuing he will be), then that's how we'll do thing from 
now.

Of course, any LSM or other security mechanism is still welcome to be 
merged via my tree.



-- 
James Morris
<jmorris@namei.org>

--
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

Security updates for v4.15 and beyond

[Casey Schaufler]

On 9/26/2017 5:03 PM, James Morris wrote:
> On Tue, 26 Sep 2017, John Johansen wrote:
>
>> I have to agree with Paul here, unless there are infrastructure
>> changes this feels like an extra hop. With next directly pulling
>> security (for infrastructure) and LSM changes merge conflicts will
>> show up there. At which point we are going to need to coordinate,
>> but these should be rare.
> Ok, it seems a consensus is emerging to go with Paul's idea of having 
> larger, frequently updated LSMs merge directly to Linus.  If Linus is okay 
> with that (I'm assuing he will be), then that's how we'll do thing from 
> now.
>
> Of course, any LSM or other security mechanism is still welcome to be 
> merged via my tree.

Smack will stick with the security tree for the time being.
The amount of change is small (due to simplicity! :) ) and I
seriously doubt Linus wants to deal with the onesy-twosy patch
volume.

I will stick with the security tree for the stacking work as well.
Having SELinux and AppArmor going off on their own is a royal pain
for that, but there's already audit and networking to worry about
so it's hard to argue that life is going to be that much harder.

Oh well. I knew the job was dangerous when I took it.

--
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