Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2206942pxp; Mon, 7 Mar 2022 10:22:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJwEWDO9Y9iuDiSJow55ZEaYL2AFibUPqp7QVmG4FGfwBv53yvj4uB0/pBMuqZpBy1XPSpzw X-Received: by 2002:a17:907:9606:b0:6da:68e4:d880 with SMTP id gb6-20020a170907960600b006da68e4d880mr9739865ejc.405.1646677368909; Mon, 07 Mar 2022 10:22:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646677368; cv=none; d=google.com; s=arc-20160816; b=c32pOkl+TUNo5pUCuzrxofD3T8WmqKnPT+WFzB1IhzJ3uMcuCbDbxLQuz2VJqnbST7 rXph5b8UNWSQbM8gEIFOhoD+bP8ttjWwubzSRHpgdYRUOaqEGY+8NYAoKQPBbI2dcmIk FZN7f1fYQxUCGEKsWeDzH1dbd2ijoZ+BZFx6m0zjNVqkOkaMdiwf+q2DoSf/MuS9wQ3Z GzdwfAmCuWTkljBhmdVIBfESTBQ4BVHLxmqInnXjUnw+76hAAmb/V/YlqZge70Dcurx6 MVrIK1j57wiqbvJfB2VStROgcBMZn+XYeuRocdQKZ0BehhkdAsqXie7HvSbXT4GNm6bR n4fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=eFuv1CZ1FCJvRh23WLfkSzv/heaOZIC7c/13FaNc3Wo=; b=f79E0MgOO3hrubxd7mOO+rcUbnIm7Q89XqJd//MKhYl1SRhoDtta/s+uL6xOeuW0p1 nAPKe4qOuL45f/ag30j1yVBv/2OW0V9wQZdEh9jaDXg0ulyeff9twZgqCth7FRiFE9sB 2tyIAJ9W4eHnDGl6RP+EJ2JQKBjAX6Fq4POxwMsTFrXcpgte7lep304O82xofDMujDEK me17DsgU/GUCUYVIg2F8fxbPlYTpqVPVZC700FG/F3ERq7q29i3CXRr3OPqQ4mLAytZ2 26dEBWZtrzNLWgT5r8eiQnOpMPzP5TzHkXzAnWpt9FrKvp69U9KBG3M3FavvUuTo1I8m YKbw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@benyossef-com.20210112.gappssmtp.com header.s=20210112 header.b=2TAsd6PK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qb35-20020a1709077ea300b006b51bc8230fsi9623846ejc.671.2022.03.07.10.22.25; Mon, 07 Mar 2022 10:22:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@benyossef-com.20210112.gappssmtp.com header.s=20210112 header.b=2TAsd6PK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241912AbiCGMsg (ORCPT + 99 others); Mon, 7 Mar 2022 07:48:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34014 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242511AbiCGMsd (ORCPT ); Mon, 7 Mar 2022 07:48:33 -0500 Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 984CB6246 for ; Mon, 7 Mar 2022 04:47:35 -0800 (PST) Received: by mail-yb1-xb34.google.com with SMTP id h126so30700968ybc.1 for ; Mon, 07 Mar 2022 04:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=benyossef-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eFuv1CZ1FCJvRh23WLfkSzv/heaOZIC7c/13FaNc3Wo=; b=2TAsd6PKCXUlgIYEC6sOsRFGGOkyw4qtPi3sHqqzwqVeNt8xoIqr4ya+hu98UH+oZp 9nStNtbMrEplhF7ylmE7V8+iGZ0D/g8UktjAXaXEK5Ef7u7l0BW6wUluEX6bcH44IB5a QSA8dd5KHnfphZ2xnrUU3qmNHWJDYfdUagRgyUc7WT+Y9+Dl7r6hG+jh5cWBlKcg6VOi 3zv9gy5eEFkjVnHXKBudMe8eA6JKj7hcc86GrBfVsOIT3NBM94YOoYPRTeLflTLhOIA/ XAerpQxZdma6VuD/ALzQzgvqOzgEDApXsGzBsxOOXG345TY7QqTC4kNJMdYK69quy70W kYCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eFuv1CZ1FCJvRh23WLfkSzv/heaOZIC7c/13FaNc3Wo=; b=18+R6uT/9nNUHgtj5cNVPGMK9pGQ65rOWTG/J4ar8ybTG2Dees508tCuaCd3mZVPA4 zrJuy4zp/IgJnZxFoHWOT2FrGuaf2nsv8jNC0O6GwiotLkkDBazVHqz/KMwuvqx/egvD IjjYXGdqLMQjCpNpM2EW7IVYgB9JjxZw5pqw/XlIHl+89Ss7QNlByRyrspmP/WSn2vFn cXUUa6lLg2bUbpRVHuAvDmglR7lZu/ZAEcElnTfaM/j2IR0jey7nKTYcwEXfKH+mSmll 0a1npdhPd83+PZDQpto3QW8qjZygOt+j18ApBnnQh93pSv5a6yKYolRG698ER68xN8Ao FEwA== X-Gm-Message-State: AOAM5303fjaAZVvW27bWvI2lgFe5zz6FyEnCTK9iXBut/3qMheBLMDfT zMUW+Nkb9BrUVXkYQCQkv0LAtT2N5RqWvR2xIfTo2Q== X-Received: by 2002:a25:5509:0:b0:622:1c12:4230 with SMTP id j9-20020a255509000000b006221c124230mr7750645ybb.416.1646657253810; Mon, 07 Mar 2022 04:47:33 -0800 (PST) MIME-Version: 1.0 References: <6cf91f43-df23-3ac9-e9b5-958d99d37422@arm.com> In-Reply-To: <6cf91f43-df23-3ac9-e9b5-958d99d37422@arm.com> From: Gilad Ben-Yossef Date: Mon, 7 Mar 2022 14:47:23 +0200 Message-ID: Subject: Re: [BUG] crypto: ccree: driver does not handle case where cryptlen = authsize =0 To: Robin Murphy Cc: Corentin Labbe , Christoph Hellwig , m.szyprowski@samsung.com, Herbert Xu , Linux Crypto Mailing List , Linux kernel mailing list , iommu@lists.linux-foundation.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 7, 2022 at 2:36 PM Robin Murphy wrote: > > On 2022-03-07 12:17, Gilad Ben-Yossef wrote: > > On Mon, Mar 7, 2022 at 1:14 PM Robin Murphy wrot= e: > > > >> The "overlap" is in the sense of having more than one mapping within t= he > >> same cacheline: > >> > >> [ 142.458120] DMA-API: add_dma_entry start P=3Dba79f200 N=3Dba79f > >> D=3Dba79f200 L=3D10 DMA_FROM_DEVICE attrs=3D0 > >> [ 142.458156] DMA-API: add_dma_entry start P=3D445dc010 N=3D445dc > >> D=3D445dc010 L=3D10 DMA_TO_DEVICE attrs=3D0 > >> [ 142.458178] sun8i-ss 1c15000.crypto: SRC 0/1/1 445dc000 len=3D16 bi= =3D0 > >> [ 142.458215] sun8i-ss 1c15000.crypto: DST 0/1/1 ba79f200 len=3D16 bi= =3D0 > >> [ 142.458234] DMA-API: add_dma_entry start P=3Dba79f210 N=3Dba79f > >> D=3Dba79f210 L=3D10 DMA_FROM_DEVICE attrs=3D0 > >> > >> This actually illustrates exactly the reason why this is unsupportable= . > >> ba79f200 is mapped for DMA_FROM_DEVICE, therefore subsequently mapping > >> ba79f210 for DMA_TO_DEVICE may cause the cacheline covering the range > >> ba79f200-ba79f23f to be written back over the top of data that the > >> device has already started to write to memory. Hello data corruption. > >> > >> Separate DMA mappings should be from separate memory allocations, > >> respecting ARCH_DMA_MINALIGN. > > > > hmm... I know I'm missing something here, but how does this align with > > the following from active_cacheline_insert() in kernel/dma/debug.c ? > > > > /* If the device is not writing memory then we don't have any > > * concerns about the cpu consuming stale data. This mitigate= s > > * legitimate usages of overlapping mappings. > > */ > > if (entry->direction =3D=3D DMA_TO_DEVICE) > > return 0; > > It's OK to have multiple mappings that are *all* DMA_TO_DEVICE, which > looks to be the case that this check was intended to allow. However I > think you're right that it should still actually check for conflicting > directions between the new entry and any existing ones, otherwise it > ends up a bit too lenient. > > Cheers, > Robin. I understand what you are saying about why checking for conflicting directions may be a good thing, but given that the code is as it is right now, how are we seeing the warning for two mapping that one of them is DMA_TO_DEVICE? Gilad --=20 Gilad Ben-Yossef Chief Coffee Drinker values of =CE=B2 will give rise to dom!