linux-kernel - Re: [PATCH 0/29] arm meltdown fix backporting review for lts 4.9

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKv+Gu8ratRYnGzNm5qppUetEFt4Dief_3_Dj6yaW==DJemeHQ@mail.gmail.com>
Date:   Tue, 13 Mar 2018 13:01:43 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Greg KH <greg@...ah.com>
Cc:     Alex Shi <alex.shi@...aro.org>,
        Marc Zyngier <marc.zyngier@....com>,
        Will Deacon <will.deacon@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        stable@...r.kernel.org,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/29] arm meltdown fix backporting review for lts 4.9

On 13 March 2018 at 10:38, Greg KH <greg@...ah.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@...ah.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@...ah.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: