Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <b8546932-109f-a2d8-66cf-37512afd3927@huawei.com>
Date:   Tue, 12 Jul 2022 15:46:58 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: [PATCH] arm64/crypto: poly1305 fix a read out-of-bound
Content-Language: en-US
To:     Eric Biggers <ebiggers@kernel.org>
CC:     <linux-crypto@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>,
        <herbert@gondor.apana.org.au>, <davem@davemloft.net>,
        <catalin.marinas@arm.com>, <will@kernel.org>
References: <20220712033215.45960-1-guozihua@huawei.com>
 <Ys0d9KPadnltgwae@sol.localdomain> <Ys0ip6SdCfWmbA1V@sol.localdomain>
From:   "Guozihua (Scott)" <guozihua@huawei.com>
In-Reply-To: <Ys0ip6SdCfWmbA1V@sol.localdomain>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2022/7/12 15:28, Eric Biggers wrote:
> On Tue, Jul 12, 2022 at 12:08:36AM -0700, Eric Biggers wrote:
>>
>> Is the special reproducer really needed?  I'd expect this to be reproduced by
>> the existing crypto self-tests just by booting a kernel built with both
>> CONFIG_KASAN=y and CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y.
>>
> 
> Ah, probably the self-tests don't find this because with poly1305 the key is
> actually read from the "data", and for the self-tests the data addresses happens
> to always be in the kernel direct map, so KASAN doesn't work for it (I think).
> Ideally the self-tests would test with kmalloc'ed data buffers too, or a buffer
> in vmalloc'ed memory that's directly followed by a guard page.
> 
> - Eric
> .

Hi Eric,

I just tried and it seems that the extra self-test won't find this bug 
so I will just keep the reproducer in place.

-- 
Best
GUO Zihua