Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1445938ybz; Fri, 1 May 2020 23:42:50 -0700 (PDT) X-Google-Smtp-Source: APiQypLSMBCIGyMYQglei8hoK0g6+tllHiWJQ019tP3gTVIJPpqR/QLFnAghcM2SjRaUan7J9s9U X-Received: by 2002:a50:f1d6:: with SMTP id y22mr6342774edl.298.1588401769929; Fri, 01 May 2020 23:42:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588401769; cv=none; d=google.com; s=arc-20160816; b=QmCyUqOIr4VGWDA+AbEb3tV3/fO7UtCw9K6nkj89gkQ88A3zGbjTA559ffIQDvQc1x ZlCAmuZjykAwSlBrtM7oDtPsofBvt6FB1s5mO6QQ6nk+ZEeplgFOvQAmOBxZKjcpSUAA 5GFNBcEBp/EzX3NwF7wpVffdnMmq7Og10oK3Be5BGacMchRzu2Qdd4Hmc2i11UjnWRKi Qj2vE9YValOBQWoEynNNZINamq0uH3VtJV+I9Tru7nfVQyhzs+Ztze79ZcBXtt2c+hNq Db/XmgKUl12YJLqshYqQ6E50Da05AFa4TFRwrZMd7RoCwt/sMjH30zn5CN5nRyYh3wUT 6sBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=+HacUMp/O9P1TWvBcRkN3Y8OqHAzKhW694gPL3ppX9w=; b=Gdc394L/03Aqqoz5bq7gHfxKEJsefKEiHftRtcMjNsDBtmFGx8oP9//top0Lg7QD50 fKCE4rZpVRdoV/wl1AxENhS8jamOVWXXLM5+PHU0cQYCWHJzcMmgP+Db7ydLI28TFJvX QLxi41GivkZA1laGmthrWKqfoCne6l/4sTqN2edzduO3PTAQuSN2NxeZGBnu7i9d9Fw4 XcDjUiU69u42ZDA0kfVDUcdrgrTtFYyct+AKH7ZIKF91ByIZ3oMzYeDvCdRCFismipW0 Ig7x7ddk9JAE9LvvtF0Wudm8w0i1n7tCWweqAhwAGnMNWncbjRE/S1crhAQyj0/RJwV5 OZGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=hnRu6Cpv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u19si2811272eda.10.2020.05.01.23.42.24; Fri, 01 May 2020 23:42:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=hnRu6Cpv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726787AbgEBGko (ORCPT + 99 others); Sat, 2 May 2020 02:40:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:58086 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726574AbgEBGko (ORCPT ); Sat, 2 May 2020 02:40:44 -0400 Received: from coco.lan (ip5f5ad5c5.dynamic.kabel-deutschland.de [95.90.213.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CC0D9208DB; Sat, 2 May 2020 06:40:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588401643; bh=veIQRujR2PEfdzDRCn259XTGbonPxwJS0bLgO0dYJow=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=hnRu6CpvgMhn0bbEWa/fuaEznaD7Btef4wx+nXWNi23HKCun+vzAKXlt2DEYAjPt0 Z609NbD7xnw4+xNd0SZIB7ZR+GvxFCkQu94nHGtLnS+9OEKnGC70zV1nwl+INl6YGt 8WmmJH5A84NCaJVXNadNZtG1tUBx0gT++5bHyW/E= Date: Sat, 2 May 2020 08:40:38 +0200 From: Mauro Carvalho Chehab To: "Daniel W. S. Almeida" Cc: sean@mess.org, kstewart@linuxfoundation.org, allison@lohutok.net, tglx@linutronix.de, linux-media@vger.kernel.org, skhan@linuxfoundation.org, linux-kernel-mentees@lists.linuxfoundation.org, linux-kernel@vger.kernel.org Subject: Re: [RFC, WIP, v4 06/11] media: vidtv: add wrappers for memcpy and memset Message-ID: <20200502084038.07c38c4b@coco.lan> In-Reply-To: <20200502032216.197977-7-dwlsalmeida@gmail.com> References: <20200502032216.197977-1-dwlsalmeida@gmail.com> <20200502032216.197977-7-dwlsalmeida@gmail.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Sat, 2 May 2020 00:22:11 -0300 "Daniel W. S. Almeida" escreveu: > From: "Daniel W. S. Almeida" > > A lot of code in this driver is for serializing structures. This is > error prone. > > Therefore, prevent buffer overflows by wrapping memcpy and memset, > comparing the requested length against the buffer size. > > Signed-off-by: Daniel W. S. Almeida > --- > drivers/media/test-drivers/vidtv/Makefile | 3 ++ > .../media/test-drivers/vidtv/vidtv_common.c | 44 +++++++++++++++++++ > .../media/test-drivers/vidtv/vidtv_common.h | 28 ++++++++++++ > 3 files changed, 75 insertions(+) > create mode 100644 drivers/media/test-drivers/vidtv/vidtv_common.c > create mode 100644 drivers/media/test-drivers/vidtv/vidtv_common.h > > diff --git a/drivers/media/test-drivers/vidtv/Makefile b/drivers/media/test-drivers/vidtv/Makefile > index a9f1993dd5443..9ea9485d42189 100644 > --- a/drivers/media/test-drivers/vidtv/Makefile > +++ b/drivers/media/test-drivers/vidtv/Makefile > @@ -1,3 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0 > > +vidtv_demod-objs := vidtv_common.o > +vidtv_bridge-objs := vidtv_common.o > + > obj-$(CONFIG_DVB_VIDTV) += vidtv_tuner.o vidtv_demod.o vidtv_bridge.o > diff --git a/drivers/media/test-drivers/vidtv/vidtv_common.c b/drivers/media/test-drivers/vidtv/vidtv_common.c > new file mode 100644 > index 0000000000000..28f10630499a9 > --- /dev/null > +++ b/drivers/media/test-drivers/vidtv/vidtv_common.c > @@ -0,0 +1,44 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * The Virtual DVB test driver serves as a reference DVB driver and helps > + * validate the existing APIs in the media subsystem. It can also aid > + * developers working on userspace applications. > + * > + * Written by Daniel W. S. Almeida > + */ > + > +#include > +#include > +#include > + > +u32 vidtv_memcpy(void *to, > + const void *from, > + size_t len, > + u32 offset, > + u32 buf_sz) > +{ > + if (buf_sz && offset + len > buf_sz) { > + pr_err("%s: overflow detected, skipping. Try increasing the buffer size", > + __func__); > + return 0; shouldn't it return an error? > + } > + > + memcpy(to, from, len); > + return len; > +} > + > +u32 vidtv_memset(void *to, > + int c, > + size_t len, > + u32 offset, > + u32 buf_sz) > +{ > + if (buf_sz && offset + len > buf_sz) { > + pr_err("%s: overflow detected, skipping. Try increasing the buffer size", > + __func__); > + return 0; > + } > + > + memset(to, c, len); > + return len; > +} > diff --git a/drivers/media/test-drivers/vidtv/vidtv_common.h b/drivers/media/test-drivers/vidtv/vidtv_common.h > new file mode 100644 > index 0000000000000..64072c010dc66 > --- /dev/null > +++ b/drivers/media/test-drivers/vidtv/vidtv_common.h > @@ -0,0 +1,28 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * The Virtual DVB test driver serves as a reference DVB driver and helps > + * validate the existing APIs in the media subsystem. It can also aid > + * developers working on userspace applications. > + * > + * Written by Daniel W. S. Almeida > + */ > + > +#ifndef VIDTV_COMMON_H > +#define VIDTV_COMMON_H > + > +#include > +#include > + > +u32 vidtv_memcpy(void *to, > + const void *from, > + size_t len, > + u32 offset, > + u32 buf_sz); > + > +u32 vidtv_memset(void *to, > + int c, > + size_t len, > + u32 offset, > + u32 buf_sz); > + > +#endif // VIDTV_COMMON_H On a generic note, I don't like seeing functions or macros like those re-defining existing Kernel functions like memcpy(), memset(), etc. This is actually a very common pattern when vendors try to submit new drivers upstream: several of them have a generic code, and use an OS-specific abstraction layer, with lots of defines, inline functions and re-definitions for Kernel functions. Before upstreaming a driver (or removing one from staging), the driver should get rid of those. On **this very specific case**, I see the value of having it there, as you're not doing it as a normal Digital TV driver, but, instead, using those in order to emulate an MPEG-TS encoding. Yet, as this driver is meant to be a sort of "tutorial" for ones implementing such features, please add a WARNING at both the header and at the source code, saying that normal drivers should not do that, explaining why, in this specific case (where you're simulating a MPEG-TS in software) it makes sense to have such functions. Thanks, Mauro