Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754663AbbHXPog (ORCPT ); Mon, 24 Aug 2015 11:44:36 -0400 Received: from eu-smtp-delivery-143.mimecast.com ([146.101.78.143]:64799 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751061AbbHXPof convert rfc822-to-8bit (ORCPT ); Mon, 24 Aug 2015 11:44:35 -0400 Message-ID: <55DB3BD3.7030202@arm.com> Date: Mon, 24 Aug 2015 16:44:19 +0100 From: Vladimir Murzin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Andrey Ryabinin , Linus Walleij CC: Russell King - ARM Linux , Arnd Bergmann , "linux-mm@kvack.org" , Catalin Marinas , Will Deacon , "linux-kernel@vger.kernel.org" , David Keitel , Alexander Potapenko , "linux-arm-kernel@lists.infradead.org" , Andrew Morton , Dmitry Vyukov Subject: Re: [PATCH v2 5/5] arm64: add KASan support 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> In-Reply-To: X-OriginalArrivalTime: 24 Aug 2015 15:44:29.0593 (UTC) FILETIME=[C3826890:01D0DE83] X-MC-Unique: draguRyWRpmed_TGPjTfcQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4268 Lines: 97 On 24/08/15 15:15, Andrey Ryabinin wrote: > 2015-08-24 16:45 GMT+03:00 Linus Walleij : >> On Mon, Aug 24, 2015 at 3:15 PM, Russell King - ARM Linux >> wrote: >>> On Tue, Jul 21, 2015 at 11:27:56PM +0200, Linus Walleij wrote: >>>> On Tue, Jul 21, 2015 at 4:27 PM, Andrey Ryabinin wrote: >>>> >>>>> I used vexpress. Anyway, it doesn't matter now, since I have an update >>>>> with a lot of stuff fixed, and it works on hardware. >>>>> I still need to do some work on it and tomorrow, probably, I will share. >>>> >>>> Ah awesome. I have a stash of ARM boards so I can test it on a >>>> range of hardware once you feel it's ready. >>>> >>>> Sorry for pulling stuff out of your hands, people are excited about >>>> KASan ARM32 as it turns out. >>> >>> People may be excited about it because it's a new feature, but we really >>> need to consider whether gobbling up 512MB of userspace for it is a good >>> idea or not. There are programs around which like to map large amounts >>> of memory into their process space, and the more we steal from them, the >>> more likely these programs are to fail. >> >> I looked at some different approaches over the last weeks for this >> when playing around with KASan. >> >> It seems since KASan was developed on 64bit systems, this was >> not much of an issue for them as they could take their shadow >> memory from the vmalloc space. >> >> I think it is possible to actually just steal as much memory as is >> needed to cover the kernel, and not 1/8 of the entire addressable >> 32bit space. So instead of covering all from 0x0-0xffffffff >> at least just MODULES_VADDR thru 0xffffffff should be enough. >> So if that is 0xbf000000-0xffffffff in most cases, 0x41000000 >> bytes, then 1/8 of that, 0x8200000, 130MB should be enough. >> (Andrey need to say if this is possible.) >> > > Yes, ~130Mb (3G/1G split) should work. 512Mb shadow is optional. > The only advantage of 512Mb shadow is better handling of user memory > accesses bugs > (access to user memory without copy_from_user/copy_to_user/strlen_user etc API). > In case of 512Mb shadow we could to not map anything in shadow for > user addresses, so such bug will > guarantee to crash the kernel. > In case of 130Mb, the behavior will depend on memory layout of the > current process. > So, I think it's fine to keep shadow only for kernel addresses. 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. 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 > >> That will probably miss some usecases I'm not familiar with, where >> the kernel is actually executing something below 0xbf000000... >> >> I looked at taking memory from vmalloc instead, but ran into >> problems since this is subject to the highmem split and KASan >> need to have it's address offset at compile time. On >> Ux500 I managed to remove all the static maps and steal memory >> from the top of the vmalloc area instead of the beginning, but >> that is probably not generally feasible. >> >> I suspect you have better ideas than what I can come up >> with though. >> >> Yours, >> Linus Walleij > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/