linux-kernel - Re: [RFC PATCH v2 00/13] Kernel based bootsplash

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:   Wed, 20 Dec 2017 15:10:54 +0100
From:   Max Staudt <mstaudt@...e.de>
To:     Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
        michal@...kovi.net, sndirsch@...e.com,
        Oliver Neukum <oneukum@...e.com>,
        Takashi Iwai <tiwai@...e.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Bero Rosenkränzer 
        <bernhard.rosenkranzer@...aro.org>, philm@...jaro.org
Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/20/2017 10:43 AM, Daniel Vetter wrote:
> On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote:
>> On 12/19/2017 06:26 PM, Daniel Vetter wrote:
>>> So essentially you're telling me that on a current general purpose
>>> distro the gfx driver loading is a dumpster fire, and we're fixing
>>> this by ignoring it an adding a hole new layer on top. That doesn't
>>> sound like any kind of good idea to me.
>>
>> Yes. It is a vast improvement over the status quo, and people are asking
>> for it. And the bootsplash layer can be moved elsewhere, just change the
>> hooks and keep the loading/rendering.
>>
>> Also, gfx driver loading isn't a dumpster fire, it mostly just works. It
>> just mustn't be done 100% carelessly.
> 
> You've talked about using sleep and stuff to paper over races. That
> doesn't sound good at all.

Sorry, I was unclear.

It's Plymouth's ShowDelay that, unintentionally, papers over this bug.

The driver loading bug will happen with any user based splash - it's not limited to Plymouth.

On the other hand, if you don't start a graphical application before having loaded the final graphics driver, everything is good and there is no race.

So, module loading works as intended ;)


>>> So if just using drm for everything isn't possible (since drm drivers
>>> can at least in theory be hotunplugged), can we at least fix the
>>> existing fbdev kernel bugs? Not being able to unplug a drm driver when
>>> it's still open sounds like a rather serious issues that probably
>>> should be fixed anyway ... so we're better able to hotunplug an fbdev
>>> driver when it's in use.
>>
>> I don't see it as a bug. The fbdev driver gets unloaded as much as
>> possible, but as long as a userspace application keeps the address_space
>> mmap()ed, there's nothing we can do, short of forcibly removing it and
>> segfaulting the process the next time it tries to render something. Am I
>> missing something?
> 
> I guess you could remap that too ... But yeah SIGBUS ftw. Wrap rendering
> in a sighandler and abort if you hit that. In drm we try to be a bit
> better and keep things around until userspace has gone.

Hmm. Are you sure it's okay to SIG these processes just because someone else has decided to unload a driver? That is counter to everything else that I've seen so far.

Also, is it even feasible, implementation wise?


>>> Or we get simpledrm merged (for efifb and vesafb support) and someone
>>> types the xendrm driver (there is floating around, it's just old) and
>>> we could forget about any real fbdev drivers except the drm based
>>> ones.
>>
>> And drmcon, unless we come up with a better idea than hooking into the *con driver.
> 
> If we have everything as drm drivers, you can just use plymouth (with no
> fbdev backend ofc) and everyone is happy. Including the efifb folks (it's
> simply going to be called efidrmfb or something like that). So no idea why
> you need a *con.

Hmm, that still makes us wait until userspace has appeared...

And the reason I built it into *con is because the logic for appearing/disappearing is basically the same, and in this chain it makes sense for the bootsplash show/hide logic to be chained behind *con.


>> Sure, that'd help a lot. But what do we do until then?
> 
> Make it happen? Twiddling thumbs is an option too ofc, but it tends to not
> result in results :-)

I'm afraid I don't have the time to write an in-kernel terminal emulator, thus the wish to build upon the existing one...