linux-kernel - Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

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]

Message-ID: <20180424184843.GX4043@hirez.programming.kicks-ass.net>
Date:   Tue, 24 Apr 2018 20:48:43 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Mauro Carvalho Chehab <mchehab@...nel.org>
Cc:     Dan Carpenter <dan.carpenter@...cle.com>,
        "Gustavo A. R. Silva" <gustavo@...eddedor.com>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

On Tue, Apr 24, 2018 at 02:47:55PM -0300, Mauro Carvalho Chehab wrote:
> So, I'm wondering if are there any way to mitigate it inside the 
> core itself, instead of doing it on every driver, e. g. changing
> v4l_enum_fmt() implementation at v4l2-ioctl.
> 
> Ok, a "poor man" approach would be to pass the array directly to
> the core and let the implementation there to implement the array
> fetch logic, calling array_index_nospec() there, but I wonder if
> are there any other way that won't require too much code churn.

Sadly no; the whole crux is the array bound check itself. You could
maybe pass around the array size to the core code and then do something
like:

	if (f->index >= f->array_size)
		return -EINVAL;

	f->index = nospec_array_index(f->index, f->array_size);

in generic code, and have all the drivers use f->index as usual, but
even that would be quite a bit of code churn I guess.