Re: [Question] Status of user-space dynamic overlays API

[Ayush Singh <ayush@beagleboard.org>]

On 3/5/25 10:01, David Gibson wrote:

> On Mon, Feb 24, 2025 at 03:39:41PM +0530, Ayush Singh wrote:
>> On 2/24/25 14:07, Geert Uytterhoeven wrote:
>>
>>> Hi Ayush,
>>>
>>> On Sat, 22 Feb 2025 at 21:14, Ayush Singh <ayush@beagleboard.org> wrote:
>>>> # Challenges
>>>>
>>>> ## Security
>>>>
>>>> The concerns regarding security seemed to show up in the other
>>>> proposals. There was a proposal to have a devicetree property to
>>>> allow/deny the application of overlays in some nodes, with default being
>>>> deny. Was it insufficient?
>>> This is the most important issue: using DT overlays, you can change
>>> about anything.  There is no protection yet to limit this to e.g. the
>>> expansion connectors on your board.
>>> This is what the various WIP "connector" abstractions are trying
>>> to solve.
>> Thanks for clarifying. However, as I mentioned above, there are usecases for
>> dynamic overlays outside of connectors. Specifically, for the usecase of
>> connecting random sensors to board pins. I do agree that any fairly well
>> specified connector should probably have it's own drivers rather than using
>> a generic userspace API.
> I'm not sure that's just due to an insuffuciently broad conception of
> what a "connector" might be.  Note that to justify a dynamic overlay
> interface specifically you need to have *both*
>    1) a need to update *anywhere* in the device tree and
>    2) to do so at runtime, under userspace control
>
> It's kind of hard to see why you'd need (2) in cases that don't at
> some physical level involve a "connector".. in which case (1) is hard
> to justify.
>
> How are these sensors being connected to random board pins?  If it's
> because those pins are exposed on some header, then it seems like it
> ought to fall within the definition of a connector.  If someone is
> just soldering onto them, it seems like an semi-permanent change that
> would be better handled at boot time.


I see. It seems my perception of connector was a bit too narrow. 
Certainly, treating the whole board header as a connector would 
certainly be a better solution, since it will also allow great control 
using a dedicated driver. Thanks for the insight.


Ayush Singh