On Thu, Jun 28, 2018 at 08:56:41PM +0200, Andrey Konovalov wrote: > On Thu, Jun 28, 2018 at 12:51 PM, Dave Martin <Dave.Martin@xxxxxxx> wrote: > > On Tue, Jun 26, 2018 at 03:15:10PM +0200, Andrey Konovalov wrote: > >> 1. By using the Top Byte Ignore arm64 CPU feature, we can store pointer > >> tags in the top byte of each kernel pointer. > > > > [...] > > > > This is a change from the current situation, so the kernel may be > > making implicit assumptions about the top byte of kernel addresses. > > > > Randomising the top bits may cause things like address conversions and > > pointer arithmetic to break. > > > > For example, (q - p) will not produce the expected result if q and p > > have different tags. > > If q and p have different tags, that means they come from different > allocations. I don't think it would make sense to calculate pointer > difference in this case. Well, there is a lot of pointer comparison in the kernel which means pointer difference. Take is_vmalloc_addr() for example, even if your patchset does not cover (IIUC) vmalloc() at the moment, this function may be called with slab addresses. Presumably they would all fail the check with a non-0xff tag but it's something needs understood. If you later add support for vmalloc(), this test would fail (as would the rb tree search in find_vmap_area(). Kmemleak would probably break as well as it makes heavy use of rb tree. Basically you need to be very clear about kernel pointer usage (with an associated tag or type) vs address range it refers to and in most cases converted to an unsigned long. See the other discussion on sparse, it could potentially be useful if we can detect the places where a pointer is converted to ulong and maybe hide such conversion behind a macro with the arm64 implementation also clearing the tag. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
