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
| ||
|
Message-ID: <CAB=NE6Wy=V17uwc3GNMYaWk4cOx1a1TtHBgMYii-M5FDuPn_Gw@mail.gmail.com> Date: Tue, 24 May 2016 16:36:42 -0700 From: "Luis R. Rodriguez" <mcgrof@...nel.org> To: Dan Williams <dan.j.williams@...el.com>, Toshi Kani <toshi.kani@...com> Cc: Paul McKenney <paulmck@...ux.vnet.ibm.com>, Will Deacon <will.deacon@....com>, Christoph Hellwig <hch@...radead.org>, X86 ML <x86@...nel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, linux-arch <linux-arch@...r.kernel.org>, Julia Lawall <julia.lawall@...6.fr>, Benjamin Herrenschmidt <benh@...nel.crashing.org>, Borislav Petkov <bp@...en8.de> Subject: Enhancing semantics with memremap() - aliasing with memremap() Dan, Toshi, Christoph, I recall a while ago while memremap() was being introduced we discussed making stronger semantics for memremap() a desirable future goal [0], along with removal cleanups of ioremap_cache(). This was when only 2 types were being considered, WB and WT. I see we now have WC as well for the memremap() family. Among one of the semantic topics, on the x86 side of things we seem to have at least concluded we want to at the very least start by completely discouraging and warning alias uses for different conflicting types. A recent patch by Toshi helps to find these at run time, however it may be possible to do this proactively semantically with Coccinelle as well, but we first need an example test driver with all known invalid uses cases to write up some grammar rules for the hunt. A much much longer term goal would be properly identify only those valid uses for aliasing, and have a special API for them. This will take time for the above reaons. During the memremap() review we seemed to have agreed that making stronger semantics for memremap() was also desirable, more aimed towards addressing this as a future goal. Is it a good time for that now? I would hope identifying proper aliasing uses for memremap() might be a bit easier now than for ioremap() given its not used as widely. It may be an easier target to also write some grammar rules for it as well. [0] http://lkml.kernel.org/r/CAPcyv4g0-CcFRCWPBdKB7h0zZEO5qzT-N9YLYJw9sb=_HYnXiA@mail.gmail.com> Luis
Powered by blists - more mailing lists