[U-Boot] Patches for this merge window

[U-Boot] Patches for this merge window

[Simon Glass]

[take 2, sorry]

Hi Tom,

I see quite a lot of non-x86 patches in my todo list - does that mean
that I should pick them up if I am happy with them, or just assign
them back to you once I've taken a look?

I'm keen to get the sandbox fs and memory stuff in fairly early if
possible, since I fear breakages and the longer people have to test
the better. No one has screamed about map_sysmem() but I'm not sure if
anyone noticed. So I could pull these in, build and send a pull if
that suits? Perhaps one series at a time.... Also if Mike is having a
break should I pull in the SPI ones assigned to me?

There is also buildman, and I'm not sure what to do about that. It
would be nice to have some feedback if people have tried it - I have
had a few private emails only. I think it's a great help, but it still
has some rough edges.

Anyway, please let me know your expectations with the above. Re x86, I
am going to start applying things this week once the board removable
patch is sorted out.

Generic board is also a big change, but since it is sort-of parallel
to existing code and only turned on on a board-by-board basis the risk
is lower - it just need some weeks of review time IMO.

Regards,
Simon

[U-Boot] Patches for this merge window

[Tom Rini]

[take 2 for me, gmail defaults to reply not reply-all]

On Sun, Feb 10, 2013 at 11:48 PM, Simon Glass <sjg@google.com> wrote:

> Hi Tom,
>
> I see quite a lot of non-x86 patches in my todo list - does that mean
> that I should pick them up if I am happy with them, or just assign
> them back to you once I've taken a look?

For stuff you've posted, yes, you can either toss it back to me, toss
it into a branch in u-boot-x86.git or toss it into a patchwork bundle
and hand 'em back to me.

> I'm keen to get the sandbox fs and memory stuff in fairly early if
> possible, since I fear breakages and the longer people have to test
> the better. No one has screamed about map_sysmem() but I'm not sure if
> anyone noticed. So I could pull these in, build and send a pull if
> that suits? Perhaps one series at a time.... Also if Mike is having a
> break should I pull in the SPI ones assigned to me?

In general I've tried to skim patches at least, and will give things
one more read over when it comes back at me to pull in (however that
is).  For trivial SPI stuff (more IDs, etc) yes. For the changes to
writing and output and so forth, keep those in a
separate request if nothing else.

> There is also buildman, and I'm not sure what to do about that. It
> would be nice to have some feedback if people have tried it - I have
> had a few private emails only. I think it's a great help, but it still
> has some rough edges.

I still need to try that myself, sorry.  Has anything changed from the
last series you posted?

> Anyway, please let me know your expectations with the above. Re x86, I
> am going to start applying things this week once the board removable
> patch is sorted out.
>
> Generic board is also a big change, but since it is sort-of parallel
> to existing code and only turned on on a board-by-board basis the risk
> is lower - it just need some weeks of review time IMO.

Sounds good, thanks!

--
Tom

[U-Boot] Patches for this merge window

[Simon Glass]

Hi Tom,

On Mon, Feb 11, 2013 at 12:47 PM, Tom Rini <trini@ti.com> wrote:
> [take 2 for me, gmail defaults to reply not reply-all]
>
> On Sun, Feb 10, 2013 at 11:48 PM, Simon Glass <sjg@google.com> wrote:
>
>> Hi Tom,
>>
>> I see quite a lot of non-x86 patches in my todo list - does that mean
>> that I should pick them up if I am happy with them, or just assign
>> them back to you once I've taken a look?
>
> For stuff you've posted, yes, you can either toss it back to me, toss
> it into a branch in u-boot-x86.git or toss it into a patchwork bundle
> and hand 'em back to me.

OK will do.

>
>> I'm keen to get the sandbox fs and memory stuff in fairly early if
>> possible, since I fear breakages and the longer people have to test
>> the better. No one has screamed about map_sysmem() but I'm not sure if
>> anyone noticed. So I could pull these in, build and send a pull if
>> that suits? Perhaps one series at a time.... Also if Mike is having a
>> break should I pull in the SPI ones assigned to me?
>
> In general I've tried to skim patches at least, and will give things
> one more read over when it comes back at me to pull in (however that
> is).  For trivial SPI stuff (more IDs, etc) yes. For the changes to
> writing and output and so forth, keep those in a
> separate request if nothing else.

OK, will try that.

>
>> There is also buildman, and I'm not sure what to do about that. It
>> would be nice to have some feedback if people have tried it - I have
>> had a few private emails only. I think it's a great help, but it still
>> has some rough edges.
>
> I still need to try that myself, sorry.  Has anything changed from the
> last series you posted?

Not really, it is in the same stage.

>
>> Anyway, please let me know your expectations with the above. Re x86, I
>> am going to start applying things this week once the board removable
>> patch is sorted out.
>>
>> Generic board is also a big change, but since it is sort-of parallel
>> to existing code and only turned on on a board-by-board basis the risk
>> is lower - it just need some weeks of review time IMO.
>
> Sounds good, thanks!
>
> --
> Tom

Regards,
Simon

[U-Boot] Patches for this merge window

[Tom Rini]

On Sun, Feb 10, 2013 at 09:09:29PM -0800, Simon Glass wrote:

> [take 2, sorry]
> 
> Hi Tom,
> 
> I see quite a lot of non-x86 patches in my todo list - does that mean
> that I should pick them up if I am happy with them, or just assign
> them back to you once I've taken a look?
> 
> I'm keen to get the sandbox fs and memory stuff in fairly early if
> possible, since I fear breakages and the longer people have to test
> the better. No one has screamed about map_sysmem() but I'm not sure if
> anyone noticed. So I could pull these in, build and send a pull if
> that suits? Perhaps one series at a time.... Also if Mike is having a
> break should I pull in the SPI ones assigned to me?
> 
> There is also buildman, and I'm not sure what to do about that. It
> would be nice to have some feedback if people have tried it - I have
> had a few private emails only. I think it's a great help, but it still
> has some rough edges.

Looking back at this, I think only buildman is left.  Did all of the
other patman related changes get submitted cleanly?  I think the answer
is we'll take in buildman now so it's easier to get folks to try it in
their workflows and see where it takes us.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130320/f32cfe09/attachment.pgp>

[U-Boot] Patches for this merge window

[Simon Glass]

Hi Tom,

[sorry I wrote this yesterday and didn't send]

On Mon, Feb 11, 2013 at 12:47 PM, Tom Rini <trini@ti.com> wrote:
> [take 2 for me, gmail defaults to reply not reply-all]
>
> On Sun, Feb 10, 2013 at 11:48 PM, Simon Glass <sjg@google.com> wrote:
>
>> Hi Tom,
>>
>> I see quite a lot of non-x86 patches in my todo list - does that mean
>> that I should pick them up if I am happy with them, or just assign
>> them back to you once I've taken a look?
>
> For stuff you've posted, yes, you can either toss it back to me, toss
> it into a branch in u-boot-x86.git or toss it into a patchwork bundle
> and hand 'em back to me.
>
>> I'm keen to get the sandbox fs and memory stuff in fairly early if
>> possible, since I fear breakages and the longer people have to test
>> the better. No one has screamed about map_sysmem() but I'm not sure if
>> anyone noticed. So I could pull these in, build and send a pull if
>> that suits? Perhaps one series at a time.... Also if Mike is having a
>> break should I pull in the SPI ones assigned to me?

Well sandbox fs and memory stuff are in thank you. So far I haven't
heard of any breakages, but it is early days.

>
> In general I've tried to skim patches at least, and will give things
> one more read over when it comes back at me to pull in (however that
> is).  For trivial SPI stuff (more IDs, etc) yes. For the changes to
> writing and output and so forth, keep those in a
> separate request if nothing else.

I will bring in the SPI stuff into a separate branch in the x86 and
send you a pull. I will have to rebase and run a full build first
though.

>
>> There is also buildman, and I'm not sure what to do about that. It
>> would be nice to have some feedback if people have tried it - I have
>> had a few private emails only. I think it's a great help, but it still
>> has some rough edges.
>
> I still need to try that myself, sorry.  Has anything changed from the
> last series you posted?

I have a few tweaks so I could send an updated patch.

[..]
>> Generic board is also a big change, but since it is sort-of parallel
>> to existing code and only turned on on a board-by-board basis the risk
>> is lower - it just need some weeks of review time IMO.
>
> Sounds good, thanks!

And generic board is in also now, which is a big step. Thanks for all
your effort on that.

I am about to rev the verified boot series, and FIT image series base
on feedback.

Also, what is happening on the TPM side? I think we have all the
pieces for making the TPM work properly in U-Boot, as previously
discussed. Along with verified boot we have a pretty solid
implementation now.

Regards,
Simon

>
> --
> Tom

[U-Boot] Patches for this merge window

[Tom Rini]

On Wed, Mar 20, 2013 at 12:53:06PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> [sorry I wrote this yesterday and didn't send]
> 
> On Mon, Feb 11, 2013 at 12:47 PM, Tom Rini <trini@ti.com> wrote:
> > [take 2 for me, gmail defaults to reply not reply-all]
> >
> > On Sun, Feb 10, 2013 at 11:48 PM, Simon Glass <sjg@google.com> wrote:
> [..]
> >> Generic board is also a big change, but since it is sort-of parallel
> >> to existing code and only turned on on a board-by-board basis the risk
> >> is lower - it just need some weeks of review time IMO.
> >
> > Sounds good, thanks!
> 
> And generic board is in also now, which is a big step. Thanks for all
> your effort on that.
> 
> I am about to rev the verified boot series, and FIT image series base
> on feedback.
> 
> Also, what is happening on the TPM side? I think we have all the
> pieces for making the TPM work properly in U-Boot, as previously
> discussed. Along with verified boot we have a pretty solid
> implementation now.

So, I really want Wolfgang to weigh in on the verified boot side of
things (and I need to review it harder and think myself).  On a related
note, have you seen
http://prosauce.org/blog/2013/2/11/embedded-trust-p2-u-boot-secured-boot.html
yet?  It almost looks like easy enough that I could get that wired up
here but is also another real life case we should take into account and
make easy enough to handle and support in mainline.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130320/4494da2d/attachment.pgp>

[U-Boot] Patches for this merge window

[Simon Glass]

Hi Tom,

On Wed, Mar 20, 2013 at 12:28 PM, Tom Rini <trini@ti.com> wrote:
> On Sun, Feb 10, 2013 at 09:09:29PM -0800, Simon Glass wrote:
>
>> [take 2, sorry]
>>
>> Hi Tom,
>>
>> I see quite a lot of non-x86 patches in my todo list - does that mean
>> that I should pick them up if I am happy with them, or just assign
>> them back to you once I've taken a look?
>>
>> I'm keen to get the sandbox fs and memory stuff in fairly early if
>> possible, since I fear breakages and the longer people have to test
>> the better. No one has screamed about map_sysmem() but I'm not sure if
>> anyone noticed. So I could pull these in, build and send a pull if
>> that suits? Perhaps one series at a time.... Also if Mike is having a
>> break should I pull in the SPI ones assigned to me?
>>
>> There is also buildman, and I'm not sure what to do about that. It
>> would be nice to have some feedback if people have tried it - I have
>> had a few private emails only. I think it's a great help, but it still
>> has some rough edges.
>
> Looking back at this, I think only buildman is left.  Did all of the
> other patman related changes get submitted cleanly?  I think the answer
> is we'll take in buildman now so it's easier to get folks to try it in
> their workflows and see where it takes us.

Yes that's right. I can set up a bundle, along with the patman
additions, but actually I have found some problems with patman in the
latest mainline - checkpatch has changed. There are quite a few things
collected now that need fixing - e.g. Doug's fix to stop removing
Reviewed-by: tags.

I will start by getting some patches out and we can take a look. Until
then is it OK to hold off on buildman?

Regards,
Simon

>
> --
> Tom

[U-Boot] Patches for this merge window

[Tom Rini]

On Wed, Mar 20, 2013 at 07:27:24PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, Mar 20, 2013 at 12:28 PM, Tom Rini <trini@ti.com> wrote:
> > On Sun, Feb 10, 2013 at 09:09:29PM -0800, Simon Glass wrote:
> >
> >> [take 2, sorry]
> >>
> >> Hi Tom,
> >>
> >> I see quite a lot of non-x86 patches in my todo list - does that mean
> >> that I should pick them up if I am happy with them, or just assign
> >> them back to you once I've taken a look?
> >>
> >> I'm keen to get the sandbox fs and memory stuff in fairly early if
> >> possible, since I fear breakages and the longer people have to test
> >> the better. No one has screamed about map_sysmem() but I'm not sure if
> >> anyone noticed. So I could pull these in, build and send a pull if
> >> that suits? Perhaps one series at a time.... Also if Mike is having a
> >> break should I pull in the SPI ones assigned to me?
> >>
> >> There is also buildman, and I'm not sure what to do about that. It
> >> would be nice to have some feedback if people have tried it - I have
> >> had a few private emails only. I think it's a great help, but it still
> >> has some rough edges.
> >
> > Looking back at this, I think only buildman is left.  Did all of the
> > other patman related changes get submitted cleanly?  I think the answer
> > is we'll take in buildman now so it's easier to get folks to try it in
> > their workflows and see where it takes us.
> 
> Yes that's right. I can set up a bundle, along with the patman
> additions, but actually I have found some problems with patman in the
> latest mainline - checkpatch has changed. There are quite a few things
> collected now that need fixing - e.g. Doug's fix to stop removing
> Reviewed-by: tags.
> 
> I will start by getting some patches out and we can take a look. Until
> then is it OK to hold off on buildman?

Sounds good to me, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130321/b490ca4e/attachment.pgp>

[U-Boot] Patches for this merge window

[Simon Glass]

Hi Tom,

On Wed, Mar 20, 2013 at 1:07 PM, Tom Rini <trini@ti.com> wrote:

> On Wed, Mar 20, 2013 at 12:53:06PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > [sorry I wrote this yesterday and didn't send]
> >
> > On Mon, Feb 11, 2013 at 12:47 PM, Tom Rini <trini@ti.com> wrote:
> > > [take 2 for me, gmail defaults to reply not reply-all]
> > >
> > > On Sun, Feb 10, 2013 at 11:48 PM, Simon Glass <sjg@google.com> wrote:
> > [..]
> > >> Generic board is also a big change, but since it is sort-of parallel
> > >> to existing code and only turned on on a board-by-board basis the risk
> > >> is lower - it just need some weeks of review time IMO.
> > >
> > > Sounds good, thanks!
> >
> > And generic board is in also now, which is a big step. Thanks for all
> > your effort on that.
> >
> > I am about to rev the verified boot series, and FIT image series base
> > on feedback.
> >
> > Also, what is happening on the TPM side? I think we have all the
> > pieces for making the TPM work properly in U-Boot, as previously
> > discussed. Along with verified boot we have a pretty solid
> > implementation now.
>
> So, I really want Wolfgang to weigh in on the verified boot side of
> things (and I need to review it harder and think myself).  On a related
> note, have you seen
>
> http://prosauce.org/blog/2013/2/11/embedded-trust-p2-u-boot-secured-boot.html
> yet?  It almost looks like easy enough that I could get that wired up
> here but is also another real life case we should take into account and
> make easy enough to handle and support in mainline.


Yes it would be good to get Wolfgang's feedback. I will also update the
follow-on 'image' series.

I had a good look through this, after doing a rough rebase to master.

The main parts are:

- RSA
- A move comprehensive TPM library
- Plumbing to call tpm_extend when there is user data loaded (environment,
kernel, ramdisk, command line...)

It brings in some additional code from the Chromium tree, which we have
been upstreaming.

The first two (RSA and TPM library) are mostly covered by my vboot series
and Che-Liang's TPM work. I suggest that the TPM additions in sboot could
be done by adding the missing features on top of Che-Liang's work. For the
third part (the plumbing), this could become a CONFIG option I think.

The two verified boot implementations use similar infrastructure, but are
somewhat different. My one works around FIT images, assuming a read-only
root of trust, and is intended to use the TPM for rollback protection only
so far. Images within the FIT are verified with a public key, and image
verification can be chained.

The sboot implementation also requires some trusted read-only code, but
then uses tpm_extend on each new chunk of user data/code loaded. It
requires the chain of tpm_extends to be played back and stored in the TPM,
then the TPM is locked and future boots must replay with the same code. So
it is not quite as easy to upgrade images (e.g. move to a new kernel)
although I'm sure this problem could be solved using a suitable mechanism.

It would be possible to support much of the functionality of the sboot
implementation within FIT, and certainly the fact that both need similar
infrastructure means that I think the FIT-based verified boot is a good
basis for upstreaming the sboot implementation when this is ready.

If you are interested I pushed my rebased branch to the x86 tree (branch is
try-sboot) - this is missing some code since I didn't do a proper rebase,
but if is much easier to diff against master.

Regards,
Simon