RE: [kernel-hardening] [PATCH 4/6] Protectable Memory

From: Igor Stoppa <igor.stoppa@huawei.com>
To: Laura Abbott <labbott@redhat.com>, Kees Cook <keescook@chromium.org>
Cc: Boris Lukashev <blukashev@sempervictus.com>,
	Christopher Lameter <cl@linux.com>,
	Matthew Wilcox <willy@infradead.org>,
	Jann Horn <jannh@google.com>, Jerome Glisse <jglisse@redhat.com>,
	Michal Hocko <mhocko@kernel.org>,
	Christoph Hellwig <hch@infradead.org>,
	linux-security-module <linux-security-module@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	kernel list <linux-kernel@vger.kernel.org>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>
Subject: RE: [kernel-hardening] [PATCH 4/6] Protectable Memory
Date: Tue, 13 Feb 2018 15:20:03 +0000	[thread overview]
Message-ID: <688F43F4-36AB-4D98-8B82-34437CFD85BC> (raw)
In-Reply-To: <414027d3-dd73-cf11-dc2a-e8c124591646@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 3802 bytes --]

hi,
apologies for (probably) breaking any email etiquette, but i'm travelling and i have available only the corporate mail client.
I'll reply more extensively to all the comments i go next week, when i'm back to the office.

In the meanwhile i would like to point out that I had already addressed this, in past thread, but got no reply.

To recap:
-1) vmalloced memory is harder to attack than kmalloced, because it requires the attacker to figuere out also the physical address. Currently it's sufficient to identify the randomized base address and the offset in memory of the victim.
I have not seen comments about this statement I made. Is it incorrect?
-2) this patchset is about protecting something that right now is not protected at all. That should be the starting point for comparison. If it was possible to have separate section like const or _ro_after init, the situation would be different, but i was told that it's not possible. furthermore, it would require reserving a fixed size "zone", i think.
-3)What is the attack we want to make harder to perform? Because even const data can be attacked, if we assume that the attacker can alter page mappings. In reality, the only safe way would be to have one-way only protection. But we do not have it. Why alterations of page properties are not considered a risk and the physmap is?
And how would it be easier (i suppose) to attack the latter?
I'm all for hardening what is possible, but I feel I do not have full understanding of some of the assumptions being made here.
Getting some answers to my questions above might help me seeing the point being made.

--
thanks, igor

--------------------------------------------------
Igor Stoppa Igor Stoppa
M:
E: igor.stoppa@huawei.com<mailto:igor.stoppa@huawei.com>
2012<tel:2012>实验室-赫尔辛基研究所
2012<tel:2012> Laboratories-Helsinki Research Center
From:Laura Abbott
To:Kees Cook,Igor Stoppa,
Cc:Boris Lukashev,Christopher Lameter,Matthew Wilcox,Jann Horn,Jerome Glisse,Michal Hocko,Christoph Hellwig,linux-security-module,Linux-MM,kernel list,Kernel Hardening,
Date:2018-02-13 00:40:54
Subject:Re: [kernel-hardening] [PATCH 4/6] Protectable Memory

On 02/12/2018 03:27 PM, Kees Cook wrote:
> On Sun, Feb 4, 2018 at 7:05 AM, Igor Stoppa <igor.stoppa@huawei.com> wrote:
>> On 04/02/18 00:29, Boris Lukashev wrote:
>>> On Sat, Feb 3, 2018 at 3:32 PM, Igor Stoppa <igor.stoppa@huawei.com> wrote:
>>
>> [...]
>>
>>>> What you are suggesting, if I have understood it correctly, is that,
>>>> when the pool is protected, the addresses already given out, will become
>>>> traps that get resolved through a lookup table that is built based on
>>>> the content of each allocation.
>>>>
>>>> That seems to generate a lot of overhead, not to mention the fact that
>>>> it might not play very well with the MMU.
>>>
>>> That is effectively what i'm suggesting - as a form of protection for
>>> consumers against direct reads of data which may have been corrupted
>>> by some irrelevant means. In the context of pmalloc, it would probably
>>> be a separate type of ro+verified pool
>> ok, that seems more like an extension though.
>>
>> ATM I am having problems gaining traction to get even the basic merged :-)
>>
>> I would consider this as a possibility for future work, unless it is
>> said that it's necessary for pmalloc to be accepted ...
>
> I would agree: let's get basic functionality in first. Both
> verification and the physmap part can be done separately, IMO.

Skipping over physmap leaves a pretty big area of exposure that could
be difficult to solve later. I appreciate this might block basic
functionality but I don't think we should just gloss over it without
at least some idea of what we would do.

Thanks,
Laura

[-- Attachment #2: Type: text/html, Size: 5191 bytes --]