linux-kernel - RFC: inlining device register accesses

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>] [day] [month] [year] [list]

Message-ID: <af2d96b9-cc07-3bd0-abe2-585638096b9d@metux.net>
Date:   Fri, 29 Jun 2018 16:51:04 +0200
From:   Enrico Weigelt <lkml@...ux.net>
To:     LKML <linux-kernel@...r.kernel.org>
Subject: RFC: inlining device register accesses

Hi folks,

I've got a weird idea, that I'd like to hear your oppinion about:

In drivers we have lots of cases, where things like register accesses
sometimes (on specific boards+cpus) *could* be done by direct memory
access, while many times we need more complex operations, like talking
to an I2C controller. Certainly, we dont wanna have lots of different
bus-specific code pathes in the drivers - same issue as why regmap
has been invented.

Maybe we could declare the actual register access in a more abstract
way (macros ? dsl ?), so under the hood different code pathes can be
generated and picked dynamically via kprobes-alike approach. If the
device happens to be directly cpu-accessible, ops for direct memory
access are inserted, otherwise appropriate function calls. Or maybe
the bpf jit somehow could be abused for that ?

--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287