On 2/24/25 14:07, Geert Uytterhoeven wrote:
Hi Ayush,
On Sat, 22 Feb 2025 at 21:14, Ayush Singh <ayush@xxxxxxxxxxxxxxx> 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.
Would it be enough to use `aliases` to specify the nodes where an
overlay can be applied as I have described here [0]. To further lock
down things, it might be possible to allow introducing indirection or
scoping nodes of sort. Here is an example:
\ {
aliases {
export_node0 = &spi0_scoped;
};
};
&spi0 {
spi0_scoped {};
// Stuff already connected internally
};
Any children of `spi0_scoped` should be treated as devices directly
connected to `spi0` but should provided isolation for any changes that
userspace overlays can make.
## Memory Leaks
Currently, updating/removing properties leaks memory. Was it one of the
reasons for the rejection of previous proposals?
IMO this is a minor issue. I am sure this can be improved upon. We just
need some way to keep track of which properties are part of the initial
FDT (and thus can't be freed), and which were allocated dynamically.
[0]:
https://lore.kernel.org/all/1417605808-23327-1-git-send-email-pantelis.antoniou@xxxxxxxxxxxx/#t
FTR, I do keep this up to date:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/log/?h=topic/overlays
Thanks, will check the patches.
Is there a list or mailing thread documenting what would be needed to
move this effort forward. I would love to help in any way possible.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[0]:
https://lore.kernel.org/all/d5bed265-1dbd-44d1-8287-8ca993624b79@xxxxxxxxxxxxxxx/
Best Regards,
Ayush Singh
