From patchwork Sun Feb 6 17:39:09 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Artem Bityutskiy X-Patchwork-Id: 82059 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 777EAB6EE8 for ; Mon, 7 Feb 2011 04:38:42 +1100 (EST) Received: from canuck.infradead.org ([2001:4978:20e::1]) by bombadil.infradead.org with esmtps (Exim 4.72 #1 (Red Hat Linux)) id 1Pm8Xx-0003Us-EV; Sun, 06 Feb 2011 17:37:13 +0000 Received: from localhost ([127.0.0.1] helo=canuck.infradead.org) by canuck.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1Pm8Xw-000201-1Z; Sun, 06 Feb 2011 17:37:12 +0000 Received: from smtp.nokia.com ([147.243.1.48] helo=mgw-sa02.nokia.com) by canuck.infradead.org with esmtps (Exim 4.72 #1 (Red Hat Linux)) id 1Pm8Xb-0001xN-OZ for linux-mtd@lists.infradead.org; Sun, 06 Feb 2011 17:36:54 +0000 Received: from eru.research.nokia.com (esdhcp034110.research.nokia.com [172.21.34.110]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p16Han89014624 for ; Sun, 6 Feb 2011 19:36:49 +0200 From: Artem Bityutskiy To: "linux-mtd@lists.infradead.org" Subject: [PATCH 1/5] UBI: try to reveal buggy MTD drivers Date: Sun, 6 Feb 2011 19:39:09 +0200 Message-Id: <1297013953-28886-2-git-send-email-dedekind1@gmail.com> X-Mailer: git-send-email 1.7.2.3 In-Reply-To: <1297013953-28886-1-git-send-email-dedekind1@gmail.com> References: <1297013953-28886-1-git-send-email-dedekind1@gmail.com> X-Nokia-AV: Clean X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.7.6 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20110206_123652_328813_F57FC303 X-CRM114-Status: GOOD ( 15.06 ) X-Spam-Score: 3.4 (+++) X-Spam-Report: SpamAssassin version 3.3.1 on canuck.infradead.org summary: Content analysis details: (3.4 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is freemail (dedekind1[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED 2.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (dedekind1[at]gmail.com) 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org From: Artem Bityutskiy When reading data from the flash, corrupt the buffer we are about to read to. The idea is to fix the following possible situation: 1. The buffer contains data from previous operation, e.g., read from another PEB previously. The data looks like expected, e.g., if we just do not read anything and return - the caller would not notice this. E.g., if we are reading a VID header, the buffer may contain a valid VID header from another PEB. 2. The driver is buggy and returns use success or -EBADMSG or -EUCLEAN, but it does not actually put any data to the buffer. This may confuse UBI or upper layers - they may think the buffer contains valid data while in fact it is just old data. Thus, try to reveal such buggy MTD drivers with simple debugging code which fills the read buffer with 0x12 constant. Signed-off-by: Artem Bityutskiy --- drivers/mtd/ubi/io.c | 22 ++++++++++++++++++++++ 1 files changed, 22 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c index 65915a6..339a74f 100644 --- a/drivers/mtd/ubi/io.c +++ b/drivers/mtd/ubi/io.c @@ -146,6 +146,28 @@ int ubi_io_read(const struct ubi_device *ubi, void *buf, int pnum, int offset, if (err) return err; + /* + * Deliberately corrupt the buffer to improve robustness. Indeed, if we + * do not do this, the following may happen: + * 1. The buffer contains data from previous operation, e.g., read from + * another PEB previously. The data looks like expected, e.g., if we + * just do not read anything and return - the caller would not + * notice this. E.g., if we are reading a VID header, the buffer may + * contain a valid VID header from another PEB. + * 2. The driver is buggy and returns us success or -EBADMSG or + * -EUCLEAN, but it does not actually put any data to the buffer. + * + * This may confuse UBI or upper layers - they may think the buffer + * contains valid data while in fact it is just old data. This is + * especially possible because UBI (and UBIFS) relies on CRC, and + * treats data as correct even in case of ECC errors if the CRC is + * correct. + * + * Try to prevent this situation by changing the first byte of the + * buffer. + */ + *((uint8_t *)buf) ^= 0xFF; + addr = (loff_t)pnum * ubi->peb_size + offset; retry: err = ubi->mtd->read(ubi->mtd, addr, len, &read, buf);