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;
Date:   Tue, 12 Jul 2022 00:28:39 -0700
From:   Eric Biggers <ebiggers@kernel.org>
To:     GUO Zihua <guozihua@huawei.com>
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
Subject: Re: [PATCH] arm64/crypto: poly1305 fix a read out-of-bound
Message-ID: <Ys0ip6SdCfWmbA1V@sol.localdomain>
References: <20220712033215.45960-1-guozihua@huawei.com>
 <Ys0d9KPadnltgwae@sol.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Ys0d9KPadnltgwae@sol.localdomain>
Precedence: bulk

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