From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x225zD88bEaSLkKJAjc3P9ITtsKHGmQJY9ZSWiTyWxfr53n5kbYFiYqex8tJO0qGzKW2PYUkT ARC-Seal: i=1; a=rsa-sha256; t=1516967234; cv=none; d=google.com; s=arc-20160816; b=zUREbZAvpw2KpDQDyK8RAlGepxInxO5LmqoQBTE510NQQriWdKA/Jr8RMNnq3GqtXR osLB9FhLEnNsiI/4HFKANWZLjozJK1GJbwk6x42Hdz9dVek/A6pTOUWgJdlSY3BBtp8a KzBx73lkBlcXUR8ClJKT06t79kksRG1yiJMetcj7UPx6FCFD4VFmmSghrOb7F3wMi2Yi LzsVAc05bHmVMuBTUZ171hgKUqJsPnPDQtFhXJTwReUREusSt8mQYB1+Y2O+JOxxUWJG 4lBYHkBXcKHH7R7Bc0T0OKxVV7Fz+tnGVJepw0cik+HjrEom4E1aq4sRJyAKLl2zbKeY LnLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=subject:content-transfer-encoding:content-language:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :delivered-to:list-id:list-subscribe:list-unsubscribe:list-help :list-post:precedence:mailing-list:arc-authentication-results; bh=mhJBI/5uG5uCTwXcLPQER2oUr5eRzi5atzebcLPciHE=; b=h1FW5u5Bb/Y/ekk2EUgXg/qBlj48ivkKCI24srPRY+jQTEFNKgOejmPAFvmdjsOW6f tJNIJpd9MG61Mtmurr4BRi8nZbPaKGLcb40lnMggSIRBalUlxuxZF/jVIpFCCt5lPKaY n9gLD/PPNfYHdIR1rCbTHEFDUGLUZZSuJlDmW4KkUhrGKfj6MGrmy1qaGhDPqIS3sUzN r+0+x+ISSkrEa46IWoCzXN2S+hWiJkkC9Vn1Kj4RuBVX7L5FPu7Gkyg8zTys8dr4l97U N4EavsYJHVc6qC/LG/V0dou+MA3pFx/twquZPd5N7sYTzcCWN5ol76gBBJdOPBicm6Rs mdjQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11440-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11440-gregkh=linuxfoundation.org@lists.openwall.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11440-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11440-gregkh=linuxfoundation.org@lists.openwall.com Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: To: Matthew Wilcox , Jann Horn CC: , Kees Cook , Michal Hocko , Laura Abbott , Christoph Hellwig , Christoph Lameter , , , kernel list , Kernel Hardening References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <20180126053542.GA30189@bombadil.infradead.org> From: Igor Stoppa Message-ID: <4788245d-c8e1-3587-c1e0-09c18245fe9a@huawei.com> Date: Fri, 26 Jan 2018 13:46:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20180126053542.GA30189@bombadil.infradead.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.122.225.51] X-CFilter-Loop: Reflected Subject: Re: [kernel-hardening] [PATCH 4/6] Protectable Memory X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590497635371449856?= X-GMAIL-MSGID: =?utf-8?q?1590655434692833512?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 26/01/18 07:35, Matthew Wilcox wrote: > On Wed, Jan 24, 2018 at 08:10:53PM +0100, Jann Horn wrote: >> I'm not entirely convinced by the approach of marking small parts of >> kernel memory as readonly for hardening. > > It depends how significant the data stored in there are. For example, > storing function pointers in read-only memory provides significant > hardening. > >> You're allocating with vmalloc(), which, as far as I know, establishes >> a second mapping in the vmalloc area for pages that are already mapped >> as RW through the physmap. AFAICS, later, when you're trying to make >> pages readonly, you're only changing the protections on the second >> mapping in the vmalloc area, therefore leaving the memory writable >> through the physmap. Is that correct? If so, please either document >> the reasoning why this is okay or change it. > > Yes, this is still vulnerable to attacks through the physmap. That's also > true for marking structs as const. We should probably fix that at some > point, but at least they're not vulnerable to heap overruns by small > amounts ... you have to be able to overrun some other array by terabytes. Actually, I think there is something to say in favor of using a vmalloc based approach, precisely because of the physmap :-P If I understood correctly, the physmap is primarily meant to speed up access to physical memory through the TLB. In particular, for kmalloc based allocations. Which means that, to perform a physmap-based attack to a kmalloced allocation, one needs to know: - the address of the target variable in the kmalloc range - the randomized offset of the kernel - the location of the physmap But, for a vmalloc based allocation, there is one extra hoop: since the mapping is really per page, now the attacker has actually to walk the page table, to figure out where to poke in the physmap. One more thought about physmap: does it map also code? Because, if it does, and one wants to use it for an attack, isn't it easier to look for some security test and replace a bne with be or equivalent? > It's worth having a discussion about whether we want the pmalloc API > or whether we want a slab-based API. pmalloc is meant to be useful where the attack surface is made up of lots of small allocations - my first use case was the SE Linux policy DB, where there is a variety of elements being allocated, in large amount. To the point where having ready made caches would be wasteful. Then there is the issue I already mentioned about arm/arm64 which would require to break down large mappings, which seems to be against current policy, as described in my previous mail: http://www.openwall.com/lists/kernel-hardening/2018/01/24/11 I do not know exactly what you have in mind wrt slab, but my impression is that it will most likely gravitate toward the pmalloc implementation. It will need: - "pools" or anyway some means to lock only a certain group of pages, related to a specific kernel user - (mostly) lockless allocation - a way to manage granularity (or order of allocation) Most of this is already provided by genalloc, which is what I ended up almost re-implementing, before being pointed to it :-) I only had to add the tracking of end of allocations, which is what the patch 1/6 does - as side note, is anybody maintaining it? I could not find an entry in MAINTAINERS As I mentioned above, using vmalloc adds even an extra layer of protection. The major downside is the increased TLB use, however this is not so relevant for the volumes of data that I had to deal with so far: only few 4K pages. But you might have in mind something else. I'd be interested to know what and what would be an obstacle in using pmalloc. Maybe it can be solved. -- igor From mboxrd@z Thu Jan 1 00:00:00 1970 From: igor.stoppa@huawei.com (Igor Stoppa) Date: Fri, 26 Jan 2018 13:46:55 +0200 Subject: [kernel-hardening] [PATCH 4/6] Protectable Memory In-Reply-To: <20180126053542.GA30189@bombadil.infradead.org> References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <20180126053542.GA30189@bombadil.infradead.org> Message-ID: <4788245d-c8e1-3587-c1e0-09c18245fe9a@huawei.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On 26/01/18 07:35, Matthew Wilcox wrote: > On Wed, Jan 24, 2018 at 08:10:53PM +0100, Jann Horn wrote: >> I'm not entirely convinced by the approach of marking small parts of >> kernel memory as readonly for hardening. > > It depends how significant the data stored in there are. For example, > storing function pointers in read-only memory provides significant > hardening. > >> You're allocating with vmalloc(), which, as far as I know, establishes >> a second mapping in the vmalloc area for pages that are already mapped >> as RW through the physmap. AFAICS, later, when you're trying to make >> pages readonly, you're only changing the protections on the second >> mapping in the vmalloc area, therefore leaving the memory writable >> through the physmap. Is that correct? If so, please either document >> the reasoning why this is okay or change it. > > Yes, this is still vulnerable to attacks through the physmap. That's also > true for marking structs as const. We should probably fix that at some > point, but at least they're not vulnerable to heap overruns by small > amounts ... you have to be able to overrun some other array by terabytes. Actually, I think there is something to say in favor of using a vmalloc based approach, precisely because of the physmap :-P If I understood correctly, the physmap is primarily meant to speed up access to physical memory through the TLB. In particular, for kmalloc based allocations. Which means that, to perform a physmap-based attack to a kmalloced allocation, one needs to know: - the address of the target variable in the kmalloc range - the randomized offset of the kernel - the location of the physmap But, for a vmalloc based allocation, there is one extra hoop: since the mapping is really per page, now the attacker has actually to walk the page table, to figure out where to poke in the physmap. One more thought about physmap: does it map also code? Because, if it does, and one wants to use it for an attack, isn't it easier to look for some security test and replace a bne with be or equivalent? > It's worth having a discussion about whether we want the pmalloc API > or whether we want a slab-based API. pmalloc is meant to be useful where the attack surface is made up of lots of small allocations - my first use case was the SE Linux policy DB, where there is a variety of elements being allocated, in large amount. To the point where having ready made caches would be wasteful. Then there is the issue I already mentioned about arm/arm64 which would require to break down large mappings, which seems to be against current policy, as described in my previous mail: http://www.openwall.com/lists/kernel-hardening/2018/01/24/11 I do not know exactly what you have in mind wrt slab, but my impression is that it will most likely gravitate toward the pmalloc implementation. It will need: - "pools" or anyway some means to lock only a certain group of pages, related to a specific kernel user - (mostly) lockless allocation - a way to manage granularity (or order of allocation) Most of this is already provided by genalloc, which is what I ended up almost re-implementing, before being pointed to it :-) I only had to add the tracking of end of allocations, which is what the patch 1/6 does - as side note, is anybody maintaining it? I could not find an entry in MAINTAINERS As I mentioned above, using vmalloc adds even an extra layer of protection. The major downside is the increased TLB use, however this is not so relevant for the volumes of data that I had to deal with so far: only few 4K pages. But you might have in mind something else. I'd be interested to know what and what would be an obstacle in using pmalloc. Maybe it can be solved. -- igor -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f72.google.com (mail-wm0-f72.google.com [74.125.82.72]) by kanga.kvack.org (Postfix) with ESMTP id CFA636B000D for ; Fri, 26 Jan 2018 06:46:57 -0500 (EST) Received: by mail-wm0-f72.google.com with SMTP id e195so5635956wmd.9 for ; Fri, 26 Jan 2018 03:46:57 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com. [194.213.3.17]) by mx.google.com with ESMTPS id y33si4073697edy.458.2018.01.26.03.46.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jan 2018 03:46:56 -0800 (PST) Subject: Re: [kernel-hardening] [PATCH 4/6] Protectable Memory References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <20180126053542.GA30189@bombadil.infradead.org> From: Igor Stoppa Message-ID: <4788245d-c8e1-3587-c1e0-09c18245fe9a@huawei.com> Date: Fri, 26 Jan 2018 13:46:55 +0200 MIME-Version: 1.0 In-Reply-To: <20180126053542.GA30189@bombadil.infradead.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Matthew Wilcox , Jann Horn Cc: jglisse@redhat.com, Kees Cook , Michal Hocko , Laura Abbott , Christoph Hellwig , Christoph Lameter , linux-security-module@vger.kernel.org, linux-mm@kvack.org, kernel list , Kernel Hardening On 26/01/18 07:35, Matthew Wilcox wrote: > On Wed, Jan 24, 2018 at 08:10:53PM +0100, Jann Horn wrote: >> I'm not entirely convinced by the approach of marking small parts of >> kernel memory as readonly for hardening. > > It depends how significant the data stored in there are. For example, > storing function pointers in read-only memory provides significant > hardening. > >> You're allocating with vmalloc(), which, as far as I know, establishes >> a second mapping in the vmalloc area for pages that are already mapped >> as RW through the physmap. AFAICS, later, when you're trying to make >> pages readonly, you're only changing the protections on the second >> mapping in the vmalloc area, therefore leaving the memory writable >> through the physmap. Is that correct? If so, please either document >> the reasoning why this is okay or change it. > > Yes, this is still vulnerable to attacks through the physmap. That's also > true for marking structs as const. We should probably fix that at some > point, but at least they're not vulnerable to heap overruns by small > amounts ... you have to be able to overrun some other array by terabytes. Actually, I think there is something to say in favor of using a vmalloc based approach, precisely because of the physmap :-P If I understood correctly, the physmap is primarily meant to speed up access to physical memory through the TLB. In particular, for kmalloc based allocations. Which means that, to perform a physmap-based attack to a kmalloced allocation, one needs to know: - the address of the target variable in the kmalloc range - the randomized offset of the kernel - the location of the physmap But, for a vmalloc based allocation, there is one extra hoop: since the mapping is really per page, now the attacker has actually to walk the page table, to figure out where to poke in the physmap. One more thought about physmap: does it map also code? Because, if it does, and one wants to use it for an attack, isn't it easier to look for some security test and replace a bne with be or equivalent? > It's worth having a discussion about whether we want the pmalloc API > or whether we want a slab-based API. pmalloc is meant to be useful where the attack surface is made up of lots of small allocations - my first use case was the SE Linux policy DB, where there is a variety of elements being allocated, in large amount. To the point where having ready made caches would be wasteful. Then there is the issue I already mentioned about arm/arm64 which would require to break down large mappings, which seems to be against current policy, as described in my previous mail: http://www.openwall.com/lists/kernel-hardening/2018/01/24/11 I do not know exactly what you have in mind wrt slab, but my impression is that it will most likely gravitate toward the pmalloc implementation. It will need: - "pools" or anyway some means to lock only a certain group of pages, related to a specific kernel user - (mostly) lockless allocation - a way to manage granularity (or order of allocation) Most of this is already provided by genalloc, which is what I ended up almost re-implementing, before being pointed to it :-) I only had to add the tracking of end of allocations, which is what the patch 1/6 does - as side note, is anybody maintaining it? I could not find an entry in MAINTAINERS As I mentioned above, using vmalloc adds even an extra layer of protection. The major downside is the increased TLB use, however this is not so relevant for the volumes of data that I had to deal with so far: only few 4K pages. But you might have in mind something else. I'd be interested to know what and what would be an obstacle in using pmalloc. Maybe it can be solved. -- igor -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <20180126053542.GA30189@bombadil.infradead.org> From: Igor Stoppa Message-ID: <4788245d-c8e1-3587-c1e0-09c18245fe9a@huawei.com> Date: Fri, 26 Jan 2018 13:46:55 +0200 MIME-Version: 1.0 In-Reply-To: <20180126053542.GA30189@bombadil.infradead.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [kernel-hardening] [PATCH 4/6] Protectable Memory To: Matthew Wilcox , Jann Horn Cc: jglisse@redhat.com, Kees Cook , Michal Hocko , Laura Abbott , Christoph Hellwig , Christoph Lameter , linux-security-module@vger.kernel.org, linux-mm@kvack.org, kernel list , Kernel Hardening List-ID: On 26/01/18 07:35, Matthew Wilcox wrote: > On Wed, Jan 24, 2018 at 08:10:53PM +0100, Jann Horn wrote: >> I'm not entirely convinced by the approach of marking small parts of >> kernel memory as readonly for hardening. > > It depends how significant the data stored in there are. For example, > storing function pointers in read-only memory provides significant > hardening. > >> You're allocating with vmalloc(), which, as far as I know, establishes >> a second mapping in the vmalloc area for pages that are already mapped >> as RW through the physmap. AFAICS, later, when you're trying to make >> pages readonly, you're only changing the protections on the second >> mapping in the vmalloc area, therefore leaving the memory writable >> through the physmap. Is that correct? If so, please either document >> the reasoning why this is okay or change it. > > Yes, this is still vulnerable to attacks through the physmap. That's also > true for marking structs as const. We should probably fix that at some > point, but at least they're not vulnerable to heap overruns by small > amounts ... you have to be able to overrun some other array by terabytes. Actually, I think there is something to say in favor of using a vmalloc based approach, precisely because of the physmap :-P If I understood correctly, the physmap is primarily meant to speed up access to physical memory through the TLB. In particular, for kmalloc based allocations. Which means that, to perform a physmap-based attack to a kmalloced allocation, one needs to know: - the address of the target variable in the kmalloc range - the randomized offset of the kernel - the location of the physmap But, for a vmalloc based allocation, there is one extra hoop: since the mapping is really per page, now the attacker has actually to walk the page table, to figure out where to poke in the physmap. One more thought about physmap: does it map also code? Because, if it does, and one wants to use it for an attack, isn't it easier to look for some security test and replace a bne with be or equivalent? > It's worth having a discussion about whether we want the pmalloc API > or whether we want a slab-based API. pmalloc is meant to be useful where the attack surface is made up of lots of small allocations - my first use case was the SE Linux policy DB, where there is a variety of elements being allocated, in large amount. To the point where having ready made caches would be wasteful. Then there is the issue I already mentioned about arm/arm64 which would require to break down large mappings, which seems to be against current policy, as described in my previous mail: http://www.openwall.com/lists/kernel-hardening/2018/01/24/11 I do not know exactly what you have in mind wrt slab, but my impression is that it will most likely gravitate toward the pmalloc implementation. It will need: - "pools" or anyway some means to lock only a certain group of pages, related to a specific kernel user - (mostly) lockless allocation - a way to manage granularity (or order of allocation) Most of this is already provided by genalloc, which is what I ended up almost re-implementing, before being pointed to it :-) I only had to add the tracking of end of allocations, which is what the patch 1/6 does - as side note, is anybody maintaining it? I could not find an entry in MAINTAINERS As I mentioned above, using vmalloc adds even an extra layer of protection. The major downside is the increased TLB use, however this is not so relevant for the volumes of data that I had to deal with so far: only few 4K pages. But you might have in mind something else. I'd be interested to know what and what would be an obstacle in using pmalloc. Maybe it can be solved. -- igor