On Wed, Jun 27, 2018 at 04:08:09PM +0100, Ramana Radhakrishnan wrote:
On 27/06/2018 16:05, Andrey Konovalov wrote:
On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas catalin.marinas@arm.com wrote:
On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov andreyknvl@google.com wrote:
arm64 has a feature called Top Byte Ignore, which allows to embed pointer tags into the top byte of each pointer. Userspace programs (such as HWASan, a memory debugging tool [1]) might use this feature and pass tagged user pointers to the kernel through syscalls or other interfaces.
This patch makes a few of the kernel interfaces accept tagged user pointers. The kernel is already able to handle user faults with tagged pointers and has the untagged_addr macro, which this patchset reuses.
We're not trying to cover all possible ways the kernel accepts user pointers in one patchset, so this one should be considered as a start.
Thanks!
[1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
Is there anything I should do to move forward with this?
I've received zero replies to this patch set (v3 and v4) over the last month.
The patches in this series look fine but my concern is that they are not sufficient and we don't have (yet?) a way to identify where such annotations are required. You even say in patch 6 that this is "some initial work for supporting non-zero address tags passed to the kernel". Unfortunately, merging (or relaxing) an ABI without a clear picture is not really feasible.
While I support this work, as a maintainer I'd like to understand whether we'd be in a continuous chase of ABI breaks with every kernel release or we have a better way to identify potential issues. Is there any way to statically analyse conversions from __user ptr to long for example? Or, could we get the compiler to do this for us?
OK, got it, I'll try to figure out a way to find these conversions.
This sounds like the kind of thing we should be able to get sparse to do already, no ? It's been many years since I last looked at it but I thought sparse was the tool of choice in the kernel to do this kind of checking.
sparse is indeed an option. The current implementation doesn't warn on an explicit cast from (void __user *) to (unsigned long) since that's a valid thing in the kernel. I couldn't figure out if there's any other __attribute__ that could be used to warn of such conversion.