Linux Framebuffer Layer development
 help / color / mirror / Atom feed
* Indirect call in vesafb driver
@ 2019-03-13 14:54 Alexander Pateenok
  2019-03-19 16:46 ` Alan Cox
  0 siblings, 1 reply; 3+ messages in thread
From: Alexander Pateenok @ 2019-03-13 14:54 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz, dri-devel, linux-fbdev, linux-kernel

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 ?

Thanks, Alex

^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: Indirect call in vesafb driver
  2019-03-13 14:54 Indirect call in vesafb driver Alexander Pateenok
@ 2019-03-19 16:46 ` Alan Cox
  2019-03-20  8:26   ` Gerd Hoffmann
  0 siblings, 1 reply; 3+ messages in thread
From: Alan Cox @ 2019-03-19 16:46 UTC (permalink / raw)
  To: Alexander Pateenok
  Cc: Bartlomiej Zolnierkiewicz, dri-devel, linux-fbdev, linux-kernel

On Wed, 13 Mar 2019 17:54:18 +0300
Alexander Pateenok <pateenoc@gmail.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

Alan

^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: Indirect call in vesafb driver
  2019-03-19 16:46 ` Alan Cox
@ 2019-03-20  8:26   ` Gerd Hoffmann
  0 siblings, 0 replies; 3+ messages in thread
From: Gerd Hoffmann @ 2019-03-20  8:26 UTC (permalink / raw)
  To: Alan Cox
  Cc: Alexander Pateenok, linux-fbdev, linux-kernel, dri-devel,
	Bartlomiej Zolnierkiewicz

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@gmail.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

^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-03-20  8:26 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-03-13 14:54 Indirect call in vesafb driver Alexander Pateenok
2019-03-19 16:46 ` Alan Cox
2019-03-20  8:26   ` Gerd Hoffmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox