linux-kernel - Re: [PATCH 00/17] Add export symbol namespace PL

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: <20220106110558.49dd6f26@coco.lan>
Date:   Thu, 6 Jan 2022 11:05:58 +0100
From:   Mauro Carvalho Chehab <mchehab@...nel.org>
To:     Gwendal Grignou <gwendal@...omium.org>
Cc:     Dmitry Torokhov <dtor@...omium.org>, bleung@...omium.org,
        groeck@...omium.org, myungjoo.ham@...sung.com,
        cw00.choi@...sung.com, benjamin.tissoires@...hat.com,
        jic23@...nel.org, hverkuil-cisco@...all.nl, lee.jones@...aro.org,
        pmalani@...omium.org, sre@...nel.org, thierry.reding@...il.com,
        u.kleine-koenig@...gutronix.de, lgirdwood@...il.com,
        a.zummo@...ertech.it, cychiang@...omium.org, perex@...ex.cz,
        linux-kernel@...r.kernel.org, Jonathan Cameron <jic23@...nel.org>
Subject: Re: [PATCH 00/17] Add export symbol namespace PL_CHROMEOS

Em Wed, 5 Jan 2022 20:26:36 -0800
Gwendal Grignou <gwendal@...omium.org> escreveu:

> On Wed, Jan 5, 2022 at 2:58 PM Dmitry Torokhov <dtor@...omium.org> wrote:
> >
> > Hi Gwendal,
> >
> > On Wed, Jan 5, 2022 at 2:07 PM Gwendal Grignou <gwendal@...omium.org> wrote:  
> > >
> > > Add a symbol namespace for functions exported by the plaform chromeos
> > > subsystem.  
> >
> > It would be great to explain why this is needed/desirable. What are
> > the benefits of introducing this namespace? What problem are you
> > trying to solve?  
> The issue came when reviewing an iio sensor
> (https://www.spinics.net/lists/linux-iio/msg66280.html). I wanted to
> be ahead of the curve (for once).

Patch 01 should clearly document the reason why this is needed.
Yet, see below.

While I see value on using namespaces, we should have extra care when
this is used for kAPIs designed for a product/system. I mean, what
prevents that the affected drivers won't support some day different
non-ChromeOS products? We have a media driver originally written to 
work with the One Laptop Per Children hardware, that used some
product-specific kAPIs, that were extended a couple years later to
cover different types of hardware.

What happens if some day, a driver introduced to be used on a ChromeOS
hardware would also be used by a non-ChromeOS hardware? This could
become messy as times goes by.

Instead, IMO, it would make sense to have per-subsystem namespaces.
So, for instance, placing iio under an IIO-specific namespace
(and the same for other subsystems) makes more sense on my
eyes, as the namespace boundary will be clearer, and an IIO driver
will always be IIO, no matter on what hardware such driver would
be used.

Thanks,
Mauro