Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1642679pxb; Wed, 2 Feb 2022 09:15:19 -0800 (PST) X-Google-Smtp-Source: ABdhPJzwEs194b9S8RWEdZYNAVenzFcfJmMKBlwd7BMpXg3A1UjncJpf3Hz/TS0p0J0f3xuvqxtT X-Received: by 2002:a05:6402:17cf:: with SMTP id s15mr9581312edy.433.1643822119128; Wed, 02 Feb 2022 09:15:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643822119; cv=none; d=google.com; s=arc-20160816; b=X8TWypSXvbkqQnfjjnOXBupmx4JvsZOcXkBVXIGPx/dAs8K65b3ScS5Go37Ne4mf5T gR+V/cqoDe8T2IQ1Ly69nhGymLm+Rb3aDIrPZZqRqWMiEDrj3BM38xztfUAEIBm6Hakt 7n1O+bFnBilWV8Xmftu1CRmQUccpo9XUIGisNa79fWYh7KVTHueqKhK0V5JnwVHkD0Ab F3banRvpaJY1D+/4Yk/hTfTj0Pr9asxHIOuIkp+AEm3instG7tb4cRgbxVJ9mgKvgshV zBmkJfdEuZN44wXkNFN3zPC8axu+cA3sKvDPlAGNmD1tkP4HIHnebOxTwoZ+1Q3j0nR5 MTGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Aee/u77ubOE0vyCuYGfT7vvh+kz0CcyyjunwqH/rJt0=; b=pZq301ljcqqCLjOjewZ6tXl/i2cq60HN8LkxyCHy9sZKuunXRb36TkuujHkmxO6tdu RXvBzk21R7MjnQvjQyUB0Dn1dGtUO3jUbt+JmzsM3JjtjtNNt5dlrptHFe2JLTZ6h8h6 tBsNDtWQhwWJ5oxGgJzdYOocwIRzi0wp70RUfX3BWroK3YV1bk+6VZ1NJFvZ6v9Uvs8P gIo3aA2XgohnCXN7uogL7h8R9RTGDyB7ze60p/e8yNqEGGCh//kstSQ3BaMwHeStFF7i GUqIfCWboi/sEyhOwh070NkYeUPqF6Nu7nG7vimJJ3xO66Ry8y7f31jHNSdNieUazzbI iGNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=pXwOBe42; 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; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hs41si12950442ejc.255.2022.02.02.09.14.53; Wed, 02 Feb 2022 09:15:19 -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=@ti.com header.s=ti-com-17Q1 header.b=pXwOBe42; 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; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235004AbiBAICQ (ORCPT + 99 others); Tue, 1 Feb 2022 03:02:16 -0500 Received: from lelv0142.ext.ti.com ([198.47.23.249]:45342 "EHLO lelv0142.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230104AbiBAICP (ORCPT ); Tue, 1 Feb 2022 03:02:15 -0500 Received: from fllv0034.itg.ti.com ([10.64.40.246]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 211828La078868; Tue, 1 Feb 2022 02:02:08 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1643702528; bh=Aee/u77ubOE0vyCuYGfT7vvh+kz0CcyyjunwqH/rJt0=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=pXwOBe42PkEfc0ds2HXv4oGOc+XGWbu6OqHo0PuCjHuW2Y5opM3ii983StFkDwr7l f4BRGeDC44bD7ZiNAvEm3vPD6KJcc++6XfQA0QQl2OGQnqk4rPnpoOEMSmNWmunqCg opCqDpeBJ6/P8rs3W48JTdwPYHacMomd8GhD4hAg= Received: from DFLE115.ent.ti.com (dfle115.ent.ti.com [10.64.6.36]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 211828cH037703 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 1 Feb 2022 02:02:08 -0600 Received: from DFLE103.ent.ti.com (10.64.6.24) by DFLE115.ent.ti.com (10.64.6.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14; Tue, 1 Feb 2022 02:02:08 -0600 Received: from fllv0039.itg.ti.com (10.64.41.19) by DFLE103.ent.ti.com (10.64.6.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14 via Frontend Transport; Tue, 1 Feb 2022 02:02:08 -0600 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0039.itg.ti.com (8.15.2/8.15.2) with ESMTP id 2118275l116286; Tue, 1 Feb 2022 02:02:08 -0600 Date: Tue, 1 Feb 2022 13:32:07 +0530 From: Pratyush Yadav To: CC: , , , , , Subject: Re: [PATCH] spi: spi-mem: check if data buffers are on stack Message-ID: <20220201080207.bvqpzemldlvvykga@ti.com> References: <20220131114508.1028306-1-p.yadav@ti.com> <366bad2d-ebb3-a2a5-330d-ff9019d18733@microchip.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <366bad2d-ebb3-a2a5-330d-ff9019d18733@microchip.com> X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/02/22 07:44AM, Tudor.Ambarus@microchip.com wrote: > On 1/31/22 13:45, Pratyush Yadav wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > > > The buffers passed in the data phase must be DMA-able. Programmers often > > don't realise this requirement and pass in buffers that reside on the > > stack. This can be hard to spot when reviewing code. Reject ops if their > > data buffer is on the stack to avoid this. > > > > Signed-off-by: Pratyush Yadav > > --- > > drivers/spi/spi-mem.c | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c > > index 37f4443ce9a0..b3793a2979ee 100644 > > --- a/drivers/spi/spi-mem.c > > +++ b/drivers/spi/spi-mem.c > > @@ -207,6 +207,15 @@ static int spi_mem_check_op(const struct spi_mem_op *op) > > !spi_mem_buswidth_is_valid(op->data.buswidth)) > > return -EINVAL; > > > > + /* Buffers must be DMA-able. */ > > + if (op->data.dir == SPI_MEM_DATA_IN && > > + object_is_on_stack(op->data.buf.in)) > > should we also check if the virt addr is valid? > if (object_is_on_stack(op->data.buf.in) || !virt_addr_valid(op->data.buf.in)) When would virt addr not be valid? When someone passes a bad pointer? I generally have not seen kernel APIs checking for pointer validity (other than NULL). If you pass a bad pointer then expect bad things to happen. Plus a bad pointer might also point to a valid virtual address, and we have no way of catching that. Dunno... -- Regards, Pratyush Yadav Texas Instruments Inc.