[PATCH 0/29] arm meltdown fix backporting review for lts 4.9

[Ard Biesheuvel]

On 13 March 2018 at 10:38, Greg KH <greg at kroah.com> wrote:
> On Tue, Mar 13, 2018 at 10:13:26AM +0000, Ard Biesheuvel wrote:
>> On 13 March 2018 at 10:04, Greg KH <greg at kroah.com> wrote:
>> > On Wed, Mar 07, 2018 at 06:24:09PM +0000, Ard Biesheuvel wrote:
>> >> On 2 March 2018 at 16:54, Greg KH <greg at kroah.com> wrote:
...
>> >> > Please test on the hardware that is affected, otherwise you do not know
>> >> > if your patches do anything or not.
>> >> >
>> >>
>> >> I don't think it is feasible to test these backports by confirming
>> >> that they make the fundamental issue go away. We simply don't have the
>> >> code to reproduce all the variants, and we have to rely on the
>> >> information provided by ARM Ltd. regarding which cores are affected
>> >> and which aren't.
>> >
>> > You really don't have the reproducers?  Please work with ARM to resolve
>> > that, this should not be a non-tested set of patches.  That's really
>> > worse than no patches at all, as if they were applied, that would
>> > provide a false-sense of "all is fixed".
>> >
>>
>> I know that on x86, the line between architecture and platform is
>> blurry. That is not the case on ARM, though.
>>
>> Unlike platform firmware, the OS is built on top of an abstracted
>> platform which is described by ARM's Architecture Reference Manual. If
>> ARM Ltd. issues recommendations regarding what firmware PSCI methods
>> to call when doing a context switch, or which barrier instruction to
>> issue in certain circumstances, they do so because a certain class of
>> hardware may require it in some cases. It is really not up to me to go
>> find some exploit code on GitHub, run it before and after applying the
>> patch and conclude that the problem is fixed. Instead, what I should
>> do is confirm that the changes result in the recommended actions to be
>> taken at the appropriate times.
>
> To _not_ take that exploit code and run it to _verify_ that your patches
> work, would be foolish, right?
>

Oh, absolutely. But that presupposes access to both the affected
hardware and the exploit code.

> I can't believe we are having the argument of "Test that your patches
> actually work"...
>
> Ugh, these series are all now dropped from my patch queue until you all
> get your act together and get someone to verify the changes actually
> work.
>

Fair enough. If anyone needs these patches for their systems, they can
respond with a Tested-by: