linux-kernel - Re: [PATCH] drm/bochs: switch fb_ops over to use drm_fb_helper

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: <dfbb5a6d-ede3-3907-4d01-1bcf2f3569f6@ilande.co.uk>
Date:   Mon, 3 Jul 2017 09:33:51 +0100
From:   Mark Cave-Ayland <mark.cave-ayland@...nde.co.uk>
To:     dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        kraxel@...hat.com
Subject: Re: [PATCH] drm/bochs: switch fb_ops over to use drm_fb_helper_cfb
 helpers

On 03/07/17 09:11, Daniel Vetter wrote:

> On Sun, Jul 02, 2017 at 10:52:43PM +0100, Mark Cave-Ayland wrote:
>> The current drm_fb_helper_sys helpers referenced in fb_ops assume that the
>> video memory is in system RAM. This is not the case for sparc which uses direct
>> physical memory accesses for IO memory and causes the bochs_drm module to panic
>> immediately upon startup as it tries to initialise the framebuffer.
>>
>> Switching fb_ops over to use the drm_fb_helper_cfb helpers ensures that the
>> correct accesses are used on sparc, fixing the panic and allowing the
>> bochs_drm module to function under qemu-system-sparc64.
>>
>> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@...nde.co.uk>
> 
> So is this generally true for bochs, or is this now going to broken
> platforms where the bochs framebuffer is in system memory?
> 
> I'm not entirely clear on that from your commit message ...

Here's my original analysis on the problem:
http://lkml.iu.edu/hypermail/linux/kernel/1706.3/04745.html where you
can see the issue is that on sparc you can't just assume that address
returned from ioremap() is a virtual address.

Most of the context for this change comes from commit 68648ed which has
this initial paragraph:

<quote>
fbdev: add drawing functions for framebuffers in system RAM

The generic drawing functions (cfbimgblt, cfbcopyarea, cfbfillrect)
assume that the framebuffer is in IO memory.  However, we have 3 drivers
(hecubafb, arcfb, and vfb) where the framebuffer is allocated from
system RAM (via vmalloc). Using _raw_read/write and family for these
drivers (as used in the cfb* functions) is illegal, especially in other
platforms.
</quote>

Given that bochs_drm is a PCI device which supports both memory and IO
accesses then I would think that the above comment about using
_raw_read/write isn't relevant here and this is the correct fix (for
reference I do see that nouveau/radeon/i915 which are also PCI-based are
already using the cfb helper functions).

Hopefully Gerd has experience using bochs_drm with other non-x86 systems
and can comment further.

ATB,

Mark.