From mboxrd@z Thu Jan 1 00:00:00 1970 From: ryabinin.a.a@gmail.com (Andrey Ryabinin) Date: Mon, 24 Aug 2015 19:00:19 +0300 Subject: [PATCH v2 5/5] arm64: add KASan support In-Reply-To: <55DB3BD3.7030202@arm.com> References: <1431698344-28054-1-git-send-email-a.ryabinin@samsung.com> <1431698344-28054-6-git-send-email-a.ryabinin@samsung.com> <55AE56DB.4040607@samsung.com> <20150824131557.GB7557@n2100.arm.linux.org.uk> <55DB3BD3.7030202@arm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 2015-08-24 18:44 GMT+03:00 Vladimir Murzin : > > Another option would be having "sparse" shadow memory based on page > extension. I did play with that some time ago based on ideas from > original v1 KASan support for x86/arm - it is how 614be38 "irqchip: > gic-v3: Fix out of bounds access to cpu_logical_map" was caught. > It doesn't require any VA reservations, only some contiguous memory for > the page_ext itself, which serves as indirection level for the 0-order > shadow pages. We won't be able to use inline instrumentation (I could live with that), and most importantly, we won't be able to use stack instrumentation. GCC needs to know shadow address for inline and/or stack instrumentation to generate correct code. > In theory such design can be reused by others 32-bit arches and, I > think, nommu too. Additionally, the shadow pages might be movable with > help of driver-page migration patch series [1]. > The cost is obvious - performance drop, although I didn't bother > measuring it. > > [1] https://lwn.net/Articles/650917/ > > Cheers > Vladimir >