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 17:15:45 +0100
From:   Max Staudt <mstaudt@...e.de>
To:     Daniel Vetter <daniel@...ll.ch>
Cc:     Neil Armstrong <narmstrong@...libre.com>,
        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 04:11 PM, Daniel Vetter wrote:
> So fundamentally I don't think an in-kernel bootsplash is a bad idea.
> But most likely you want this on a highly embedded system, which
> probably is compiled for your exact hw, with pretty much everything
> built in. Also, no fbcon, maybe even no vt subsystem at all.
> Definitely not your general purpose distro.

If an embedded distro can use it, then so can a general purpose distro that doesn't want to use Plymouth.

It's useful in many cases.

> Your proposal to work on top of fbcon doesn't fix that niche.

It does fix it very well - it's just that it also requires fbcon.
And I'm glad to fix this if you have a good idea for a cleaner alternative.

> Now for your problem, which seems to be to have a working bootsplash
> for a general purpose distro, specifically for the bug where plymouth
> prevents the real drm driver from loading: Adding an in-kernel
> bootsplash doesn't make any sense, at least not to me. Instead I think
> the right action is to fix the problem, both in the kernel and in
> userspace.

So we SIGBUS any process using the framebuffer just because we're loading an alternative driver, which uses a hack to kick out the old driver?

It's loading the new driver that should fail because the hardware resource is busy serving the old driver!
Not existing applications being killed. This is horribly broken semantics.

Just like unloading a driver that's still in use MUST fail. Not kill the processes using it!

And if it fails to load with -EBUSY, as it should, then the bug still stands.

> All the problems below have fairly simple solutions, but there's imo
> no point in talking technical solutions for specific problems when
> we're trying to fix the wrong problem.

The problem is that a splash in userspace brings horrible hacks and workarounds into the room. We're already discussing killing processes!

No, just no. Processes aren't ours to kill willy-nilly.

Max