Re: [Xen-devel] XSA-254 SP2 for ARM (was Re: [PATCH 1/5] xen/arm: Introduce enable callback to enable a capabilities on each online CPU)

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi,

On 24/01/18 22:43, Stefano Stabellini wrote:
> On Wed, 24 Jan 2018, Julien Grall wrote:
> > Hi Stefano,
> >
> > On 24 January 2018 at 22:14, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> > > On Thu, 18 Jan 2018, Julien Grall wrote:
> > > > (+ Security team)
> > > >
> > > > Hi Stefano,
> > > >
> > > > On 17/01/18 21:47, Stefano Stabellini wrote:
> > > > > On Wed, 17 Jan 2018, Stefano Stabellini wrote:
> > > > > > On Wed, 17 Jan 2018, Lars Kurth wrote:
> > > > > > >         Regarding README.source, this is covering file and contain the
> > > > > > > same mention as in the commit message. As this is a single function.
> > > > > > > Isn't the commit message
> > > > > > >         enough?
> > > > > > >
> > > > > > >
> > > > > > >   From a legal viewpoint it is enough.
> > > > > > If that is enough from a legal viewpoint, then it is enough for me.
> > > > > >
> > > > > > However, from a legal viewpoint, I thought we needed to explicitly
> > > > > > mention all the original signed-off-bys because Julien is not actually
> > > > > > the copyright holder for that function, hence, we need to add the
> > > > > > signed-off-bys of all the missing copyright holders.
> > > > > Actually, reading again the Developer’s Certificate of Origin, it
> > > > > states:
> > > > >
> > > > > "The contribution is based upon previous work that, to the best of my
> > > > > knowledge, is covered under an appropriate open source license and I have
> > > > > the right under that license to submit that work with modifications, whether
> > > > > created in whole or in part by me, under the same open source license
> > > > > (unless I am permitted to submit under a different license), as indicated in
> > > > > the file"
> > > > >
> > > > > so I think Lars is right. In that case, there is no need to resubmit
> > > > > this series, I'll commit to staging as is. If tests go well, I'll
> > > > > backport it to the stable trees.
> > > > Thank you! I have created branches with patches backported up to Xen 4.8. With
> > > > minor changes:
> > > >
> > > >     - Xen 4.10: No changes
> > > >     - Xen 4.9:
> > > >        * minor conflict in some files
> > > >        * compilation failure in cpuerrata.c (__virt_to_mfn does not exist)
> > > >     - Xen 4.8:
> > > >        * conflict in some files (one medium as the number of "features" is
> > > > different)
> > > >        * compilation failure in cpuerrata.c (__virt_to_mfn does not exist)
> > > >
> > > > The branches can be found on xenbits [1] : xsa-254-sp2-X.XX where X.XX is the
> > > > version of Xen.
> > > >
> > > > Xen 4.7 and earlier does not have cpufeature/cpuerrata infrastructure and will
> > > > require backport. The only difficulty here should be finding the list of
> > > > commits required.
> > > >
> > > > Also, we probably want to update the XSA pointing to the patches. So if
> > > > someone wants to backport to Xen 4.7 (or earlier) they can. Any opinions?
> > > These are the commits for the XSA 254 mitigation for the arm64
> > > architecture:
> > >
> > > staging-4.10
> > > b829d42829c1ff626a02756acae4dd482fc20c9a
> > > 0f7a4faafb2d79920cc63457cfca3e03990af4cc
> > > d1f4283a1d8405a480b4121e1efcfaec8bbdbffa
> > > cae6e1572f39a1906be0fc3bdaf49fe514c6a9c0
> > > 928112900e5b4a92ccebb2eea11665fd76aa0f0d
> > > 728fadb586a2a14a244dabd70463bcc1654ecc85
> > >
> > > staging-4.9
> > > 2ec7ccbffc6b788f65e55498e4347c1ee3a44b01
> > > 50450c1f33dc72f2138a671d738934f796be3318
> > > 3790833ef16b95653424ec9b145e460ec1a56d16
> > > fba48eff18c02d716c95b92df804a755620be82e
> > > 9f79e8d846e8413c828f5fc7cc6ac733728dff00
> > > a2567d6b54b7b187ecc0165021b6dd07dafaf06a
> > >
> > > staging-4.8
> > > 946dd2eefae2faeecbeb9662e66935c8070f64f5
> > > 85990bf53addcdb0ce8e458a3d8fad199710ac59
> > > cf0b584c8c5030588bc47a3614ad860af7482c53
> > > 44139fed7c794eb4e47a9bb93061e325bd57fe8c
> > > 6f6786ef0d7f7025860d360f6b1267193ffd1b27
> > Something looks quite odd. The commit message have two cherry-pick commit ID.
> >
> > Why didn't you just merged the branches I provided?
> Basically I did the backports on my own, then I double-checked that they
> matched your own version of the backports. I did it for safety: this way
> we can be quite sure that the backports are good, or both of us did
> exactly the same mistakes :-)
> It was very helpful to have branches to compare against, thank you for
> that.
I also double checked it yesterday because I wasn't sure what you did :).

> > > For staging-4.7, I made the backports and tested them as well. They look
> > > correct. However, given that it was more complex than initially though,
> > > I would appreciate if you could give it a look as well (I haven't pushed
> > > it staging-4.7 yet):
> > >
> > >    git://xenbits.xen.org/people/sstabellini/xen-unstable.git staging-4.7-xsa254
> > I will have a look.
> Thanks again!
This looks good to me. Thank you for backporting them to 4.7.

Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel