[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190320082616.twns6kjvgapdg4lq@sirius.home.kraxel.org>
Date: Wed, 20 Mar 2019 09:26:16 +0100
From: Gerd Hoffmann <kraxel@...hat.com>
To: Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc: Alexander Pateenok <pateenoc@...il.com>,
linux-fbdev@...r.kernel.org, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Subject: Re: Indirect call in vesafb driver
On Tue, Mar 19, 2019 at 04:46:51PM +0000, Alan Cox wrote:
> On Wed, 13 Mar 2019 17:54:18 +0300
> Alexander Pateenok <pateenoc@...il.com> wrote:
>
> > Hi,
> >
> > There're several indirect calls in inline assembly in vesafb driver
> > (drivers/video/fbdev/vesafb.c), and these calls cannot be automatically
> > changed to retpolines. It's in vesafb_pan_display():
> >
> > 73 __asm__ __volatile__(
> > 74 "call *(%%edi)"
> >
> > and in vesa_setpalette():
> >
> > 113 __asm__ __volatile__(
> > 114 "call *(%%esi)"
> >
> > Is there need to use CALL_NOSPEC ?
>
> Vesafb is from the time on the dinosaurs but yes any vesa bios code will
> not be speculatively hardened. I'd also doubt anyone is actually using
> vesafb in the first place but it should use nospec
Note that even when using vesafb the display panning is disabled by
default, and vesa_setpalette() is only used with 8bit depth (256 color
mode).
Also note that only 32bit builds will try to call vesa bios code ...
cheers,
Gerd
Powered by blists - more mailing lists