From mboxrd@z Thu Jan 1 00:00:00 1970 From: vladimir.murzin@arm.com (Vladimir Murzin) Date: Mon, 24 Aug 2015 17:16:50 +0100 Subject: [PATCH v2 5/5] arm64: add KASan support In-Reply-To: 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: <55DB4372.5010406@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 24/08/15 17:00, Andrey Ryabinin wrote: > 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. It's definitely a trade-off ;) Just for my understanding does that stack instrumentation is controlled via -asan-stack? Thanks Vladimir > >> 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 >> >