linux-kernel - Re: [RFC/PATCH 1/5] mtd: ubi: Read disturb infrastructure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 02 Oct 2014 15:24:19 +0200
From:	Richard Weinberger <richard@....at>
To:	Tanya Brokhman <tlinder@...eaurora.org>, dedeking1@...il.com
CC:	Artem Bityutskiy <dedekind1@...il.com>,
	linux-arm-msm@...r.kernel.org,
	open list <linux-kernel@...r.kernel.org>,
	linux-mtd@...ts.infradead.org,
	Brian Norris <computersforpeace@...il.com>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [RFC/PATCH 1/5] mtd: ubi: Read disturb infrastructure

Am 02.10.2014 14:50, schrieb Tanya Brokhman:
>> Consider the case where you have a board with a fastmap enabled bootloader and a Linux OS.
>> The bootloader does a fastmap attach and boots the kernel from UBI and the kernel it self has the rootfs
>> on UBI too. If you install a new kernel with your changes applied it will write the fastmap in a different
>> format and the bootloader will fail badly. In worst case the board bricks, in best case the bootloader can fall back
>> to scanning mode but it will be slow and the customer unhappy.
>>
> 
> Ok, I understand the problem now. I wanted to discuss a possible solution before implementing it:
> We have a "fastmap version" in fm_sb. At the moment UBI_FM_FMT_VERSION = 1 and any other is not supported. We can use that; Add another fm version (UBI_FM_FMT_VERSION_RD = 2) and
> then decide according to it. Meaning, if during attach process we find fm superblock we check it's version, if it's != UBI_FM_FMT_VERSION_RD, we fall back to full scan. The next
> fastmap will be written with the new layout (and new version number) so second boot will attach from fastmap without any issues.

Yes, if we change the fastmap on-disk layout we need to change UBI_FM_FMT_VERSION.
Then other fastmap implementations will notice the change and can hopefully recover.
Implementations which do not evaluate UBI_FM_FMT_VERSION deserve breaking. ;-)

That said, I'll not block a layout change but we have to be sure that it is *really* needed.
I'm currently heavily working on fastmap and my local queue with fastmap fixes keeps growing.
If I find a horror bug which needs a fastmap layout change I want to change the layout only once,
not twice.

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/