linux-kernel - Re: Stateless Encoding uAPI Discussion and Proposal

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: <87cfcdfadee89984496c3f52d01b4f1e10c12cae.camel@collabora.com>
Date:   Wed, 26 Jul 2023 15:53:58 -0400
From:   Nicolas Dufresne <nicolas.dufresne@...labora.com>
To:     Hsia-Jun Li <Randy.Li@...aptics.com>,
        Paul Kocialkowski <paul.kocialkowski@...tlin.com>
Cc:     linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
        Hans Verkuil <hverkuil@...all.nl>,
        Sakari Ailus <sakari.ailus@....fi>,
        Andrzej Pietrasiewicz <andrzej.p@...labora.com>,
        Michael Tretter <m.tretter@...gutronix.de>,
        Jernej Škrabec <jernej.skrabec@...il.com>,
        Chen-Yu Tsai <wens@...e.org>,
        Samuel Holland <samuel@...lland.org>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: Stateless Encoding uAPI Discussion and Proposal

Hi,

Le mercredi 26 juillet 2023 à 10:49 +0800, Hsia-Jun Li a écrit :
> > I am strongly against this approach, instead I think we need to keep all
> > vendor-specific parts in the kernel driver and provide a clean unified userspace
> > API.
> > 
> We are driving away vendor participation. Besides, the current design is 
> a performance bottleneck.

I know you have been hammering this argument for many many years. But in
concrete situation, we have conducted tests, and we out perform vendors stacks
that directly hit into hardware register with stateless CODEC. Also, Paul's
proposal, is that fine grain / highly close to metal tuning of the encoding
process should endup in the Linux kernel, so that it can benefit from the
natural hard real-time advantage of a hard IRQ. Just like anything else, we will
find a lot of common methods and shareable code which will benefit in security
and quality, which is very unlike what we normally get from per vendor BSP. The
strategy is the same as everything else in Linux, vendor will adpot it if there
is a clear benefit. And better quality, ease of use, good collection of mature
userspace software is what makes the difference. It does takes time of course.

regards,
Nicolas