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 270616B0003 for ; Tue, 13 Feb 2018 10:20:11 -0500 (EST) Received: by mail-wm0-f72.google.com with SMTP id e195so4759593wmd.9 for ; Tue, 13 Feb 2018 07:20:11 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com. [194.213.3.17]) by mx.google.com with ESMTPS id w8si762256edh.139.2018.02.13.07.20.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Feb 2018 07:20:09 -0800 (PST) Message-ID: <5a830229.88c9500a.8a8d1.a5afSMTPIN_ADDED_BROKEN@mx.google.com> From: Igor Stoppa Subject: RE: [kernel-hardening] [PATCH 4/6] Protectable Memory Date: Tue, 13 Feb 2018 15:20:03 +0000 References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <20180126053542.GA30189@bombadil.infradead.org> <8818bfd4-dd9f-f279-0432-69b59531bd41@huawei.com> <17e5b515-84c8-dca2-1695-cdf819834ea2@huawei.com> ,<414027d3-dd73-cf11-dc2a-e8c124591646@redhat.com> In-Reply-To: <414027d3-dd73-cf11-dc2a-e8c124591646@redhat.com> Content-Language: en-GB Content-Type: multipart/alternative; boundary="_000_688F43F436AB4D988B8234437CFD85BC_" MIME-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: To: Laura Abbott , Kees Cook Cc: Boris Lukashev , Christopher Lameter , Matthew Wilcox , Jann Horn , Jerome Glisse , Michal Hocko , Christoph Hellwig , linux-security-module , Linux-MM , kernel list , Kernel Hardening --_000_688F43F436AB4D988B8234437CFD85BC_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGksDQphcG9sb2dpZXMgZm9yIChwcm9iYWJseSkgYnJlYWtpbmcgYW55IGVtYWlsIGV0aXF1ZXR0 ZSwgYnV0IGknbSB0cmF2ZWxsaW5nIGFuZCBpIGhhdmUgYXZhaWxhYmxlIG9ubHkgdGhlIGNvcnBv cmF0ZSBtYWlsIGNsaWVudC4NCkknbGwgcmVwbHkgbW9yZSBleHRlbnNpdmVseSB0byBhbGwgdGhl IGNvbW1lbnRzIGkgZ28gbmV4dCB3ZWVrLCB3aGVuIGknbSBiYWNrIHRvIHRoZSBvZmZpY2UuDQoN CkluIHRoZSBtZWFud2hpbGUgaSB3b3VsZCBsaWtlIHRvIHBvaW50IG91dCB0aGF0IEkgaGFkIGFs cmVhZHkgYWRkcmVzc2VkIHRoaXMsIGluIHBhc3QgdGhyZWFkLCBidXQgZ290IG5vIHJlcGx5Lg0K DQpUbyByZWNhcDoNCi0xKSB2bWFsbG9jZWQgbWVtb3J5IGlzIGhhcmRlciB0byBhdHRhY2sgdGhh biBrbWFsbG9jZWQsIGJlY2F1c2UgaXQgcmVxdWlyZXMgdGhlIGF0dGFja2VyIHRvIGZpZ3VlcmUg b3V0IGFsc28gdGhlIHBoeXNpY2FsIGFkZHJlc3MuIEN1cnJlbnRseSBpdCdzIHN1ZmZpY2llbnQg dG8gaWRlbnRpZnkgdGhlIHJhbmRvbWl6ZWQgYmFzZSBhZGRyZXNzIGFuZCB0aGUgb2Zmc2V0IGlu IG1lbW9yeSBvZiB0aGUgdmljdGltLg0KSSBoYXZlIG5vdCBzZWVuIGNvbW1lbnRzIGFib3V0IHRo aXMgc3RhdGVtZW50IEkgbWFkZS4gSXMgaXQgaW5jb3JyZWN0Pw0KLTIpIHRoaXMgcGF0Y2hzZXQg aXMgYWJvdXQgcHJvdGVjdGluZyBzb21ldGhpbmcgdGhhdCByaWdodCBub3cgaXMgbm90IHByb3Rl Y3RlZCBhdCBhbGwuIFRoYXQgc2hvdWxkIGJlIHRoZSBzdGFydGluZyBwb2ludCBmb3IgY29tcGFy aXNvbi4gSWYgaXQgd2FzIHBvc3NpYmxlIHRvIGhhdmUgc2VwYXJhdGUgc2VjdGlvbiBsaWtlIGNv bnN0IG9yIF9yb19hZnRlciBpbml0LCB0aGUgc2l0dWF0aW9uIHdvdWxkIGJlIGRpZmZlcmVudCwg YnV0IGkgd2FzIHRvbGQgdGhhdCBpdCdzIG5vdCBwb3NzaWJsZS4gZnVydGhlcm1vcmUsIGl0IHdv dWxkIHJlcXVpcmUgcmVzZXJ2aW5nIGEgZml4ZWQgc2l6ZSAiem9uZSIsIGkgdGhpbmsuDQotMylX aGF0IGlzIHRoZSBhdHRhY2sgd2Ugd2FudCB0byBtYWtlIGhhcmRlciB0byBwZXJmb3JtPyBCZWNh dXNlIGV2ZW4gY29uc3QgZGF0YSBjYW4gYmUgYXR0YWNrZWQsIGlmIHdlIGFzc3VtZSB0aGF0IHRo ZSBhdHRhY2tlciBjYW4gYWx0ZXIgcGFnZSBtYXBwaW5ncy4gSW4gcmVhbGl0eSwgdGhlIG9ubHkg c2FmZSB3YXkgd291bGQgYmUgdG8gaGF2ZSBvbmUtd2F5IG9ubHkgcHJvdGVjdGlvbi4gQnV0IHdl IGRvIG5vdCBoYXZlIGl0LiBXaHkgYWx0ZXJhdGlvbnMgb2YgcGFnZSBwcm9wZXJ0aWVzIGFyZSBu b3QgY29uc2lkZXJlZCBhIHJpc2sgYW5kIHRoZSBwaHlzbWFwIGlzPw0KQW5kIGhvdyB3b3VsZCBp dCBiZSBlYXNpZXIgKGkgc3VwcG9zZSkgdG8gYXR0YWNrIHRoZSBsYXR0ZXI/DQpJJ20gYWxsIGZv ciBoYXJkZW5pbmcgd2hhdCBpcyBwb3NzaWJsZSwgYnV0IEkgZmVlbCBJIGRvIG5vdCBoYXZlIGZ1 bGwgdW5kZXJzdGFuZGluZyBvZiBzb21lIG9mIHRoZSBhc3N1bXB0aW9ucyBiZWluZyBtYWRlIGhl cmUuDQpHZXR0aW5nIHNvbWUgYW5zd2VycyB0byBteSBxdWVzdGlvbnMgYWJvdmUgbWlnaHQgaGVs cCBtZSBzZWVpbmcgdGhlIHBvaW50IGJlaW5nIG1hZGUuDQoNCi0tDQp0aGFua3MsIGlnb3INCg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJ Z29yIFN0b3BwYSBJZ29yIFN0b3BwYQ0KTToNCkU6IGlnb3Iuc3RvcHBhQGh1YXdlaS5jb208bWFp bHRvOmlnb3Iuc3RvcHBhQGh1YXdlaS5jb20+DQoyMDEyPHRlbDoyMDEyPsq10enK0i261bb70MG7 +dHQvr/L+Q0KMjAxMjx0ZWw6MjAxMj4gTGFib3JhdG9yaWVzLUhlbHNpbmtpIFJlc2VhcmNoIENl bnRlcg0KRnJvbTpMYXVyYSBBYmJvdHQNClRvOktlZXMgQ29vayxJZ29yIFN0b3BwYSwNCkNjOkJv cmlzIEx1a2FzaGV2LENocmlzdG9waGVyIExhbWV0ZXIsTWF0dGhldyBXaWxjb3gsSmFubiBIb3Ju LEplcm9tZSBHbGlzc2UsTWljaGFsIEhvY2tvLENocmlzdG9waCBIZWxsd2lnLGxpbnV4LXNlY3Vy aXR5LW1vZHVsZSxMaW51eC1NTSxrZXJuZWwgbGlzdCxLZXJuZWwgSGFyZGVuaW5nLA0KRGF0ZToy MDE4LTAyLTEzIDAwOjQwOjU0DQpTdWJqZWN0OlJlOiBba2VybmVsLWhhcmRlbmluZ10gW1BBVENI IDQvNl0gUHJvdGVjdGFibGUgTWVtb3J5DQoNCk9uIDAyLzEyLzIwMTggMDM6MjcgUE0sIEtlZXMg Q29vayB3cm90ZToNCj4gT24gU3VuLCBGZWIgNCwgMjAxOCBhdCA3OjA1IEFNLCBJZ29yIFN0b3Bw YSA8aWdvci5zdG9wcGFAaHVhd2VpLmNvbT4gd3JvdGU6DQo+PiBPbiAwNC8wMi8xOCAwMDoyOSwg Qm9yaXMgTHVrYXNoZXYgd3JvdGU6DQo+Pj4gT24gU2F0LCBGZWIgMywgMjAxOCBhdCAzOjMyIFBN LCBJZ29yIFN0b3BwYSA8aWdvci5zdG9wcGFAaHVhd2VpLmNvbT4gd3JvdGU6DQo+Pg0KPj4gWy4u Ll0NCj4+DQo+Pj4+IFdoYXQgeW91IGFyZSBzdWdnZXN0aW5nLCBpZiBJIGhhdmUgdW5kZXJzdG9v ZCBpdCBjb3JyZWN0bHksIGlzIHRoYXQsDQo+Pj4+IHdoZW4gdGhlIHBvb2wgaXMgcHJvdGVjdGVk LCB0aGUgYWRkcmVzc2VzIGFscmVhZHkgZ2l2ZW4gb3V0LCB3aWxsIGJlY29tZQ0KPj4+PiB0cmFw cyB0aGF0IGdldCByZXNvbHZlZCB0aHJvdWdoIGEgbG9va3VwIHRhYmxlIHRoYXQgaXMgYnVpbHQg YmFzZWQgb24NCj4+Pj4gdGhlIGNvbnRlbnQgb2YgZWFjaCBhbGxvY2F0aW9uLg0KPj4+Pg0KPj4+ PiBUaGF0IHNlZW1zIHRvIGdlbmVyYXRlIGEgbG90IG9mIG92ZXJoZWFkLCBub3QgdG8gbWVudGlv biB0aGUgZmFjdCB0aGF0DQo+Pj4+IGl0IG1pZ2h0IG5vdCBwbGF5IHZlcnkgd2VsbCB3aXRoIHRo ZSBNTVUuDQo+Pj4NCj4+PiBUaGF0IGlzIGVmZmVjdGl2ZWx5IHdoYXQgaSdtIHN1Z2dlc3Rpbmcg LSBhcyBhIGZvcm0gb2YgcHJvdGVjdGlvbiBmb3INCj4+PiBjb25zdW1lcnMgYWdhaW5zdCBkaXJl Y3QgcmVhZHMgb2YgZGF0YSB3aGljaCBtYXkgaGF2ZSBiZWVuIGNvcnJ1cHRlZA0KPj4+IGJ5IHNv bWUgaXJyZWxldmFudCBtZWFucy4gSW4gdGhlIGNvbnRleHQgb2YgcG1hbGxvYywgaXQgd291bGQg cHJvYmFibHkNCj4+PiBiZSBhIHNlcGFyYXRlIHR5cGUgb2Ygcm8rdmVyaWZpZWQgcG9vbA0KPj4g b2ssIHRoYXQgc2VlbXMgbW9yZSBsaWtlIGFuIGV4dGVuc2lvbiB0aG91Z2guDQo+Pg0KPj4gQVRN IEkgYW0gaGF2aW5nIHByb2JsZW1zIGdhaW5pbmcgdHJhY3Rpb24gdG8gZ2V0IGV2ZW4gdGhlIGJh c2ljIG1lcmdlZCA6LSkNCj4+DQo+PiBJIHdvdWxkIGNvbnNpZGVyIHRoaXMgYXMgYSBwb3NzaWJp bGl0eSBmb3IgZnV0dXJlIHdvcmssIHVubGVzcyBpdCBpcw0KPj4gc2FpZCB0aGF0IGl0J3MgbmVj ZXNzYXJ5IGZvciBwbWFsbG9jIHRvIGJlIGFjY2VwdGVkIC4uLg0KPg0KPiBJIHdvdWxkIGFncmVl OiBsZXQncyBnZXQgYmFzaWMgZnVuY3Rpb25hbGl0eSBpbiBmaXJzdC4gQm90aA0KPiB2ZXJpZmlj YXRpb24gYW5kIHRoZSBwaHlzbWFwIHBhcnQgY2FuIGJlIGRvbmUgc2VwYXJhdGVseSwgSU1PLg0K DQpTa2lwcGluZyBvdmVyIHBoeXNtYXAgbGVhdmVzIGEgcHJldHR5IGJpZyBhcmVhIG9mIGV4cG9z dXJlIHRoYXQgY291bGQNCmJlIGRpZmZpY3VsdCB0byBzb2x2ZSBsYXRlci4gSSBhcHByZWNpYXRl IHRoaXMgbWlnaHQgYmxvY2sgYmFzaWMNCmZ1bmN0aW9uYWxpdHkgYnV0IEkgZG9uJ3QgdGhpbmsg d2Ugc2hvdWxkIGp1c3QgZ2xvc3Mgb3ZlciBpdCB3aXRob3V0DQphdCBsZWFzdCBzb21lIGlkZWEg b2Ygd2hhdCB3ZSB3b3VsZCBkby4NCg0KVGhhbmtzLA0KTGF1cmENCg== --_000_688F43F436AB4D988B8234437CFD85BC_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
hi,
apologies for (probably) breaking any email etiquette, but i'm travelling a= nd i have available only the corporate mail client.
I'll reply more extensively to all the comments i go next week, when i'm ba= ck to the office.

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

To recap:
-1) vmalloced memory is harder to attack than kmalloced, because it require= s the attacker to figuere out also the physical address. Currently it's suf= ficient 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 prote= cted at all. That should be the starting point for comparison. If it was po= ssible 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 si= ze "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 mappin= gs. 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 under= standing of some of the assumptions being made here.
Getting some answers to my questions above might help me seeing the point b= eing made.

--
thanks, igor



--------------------------------------------------
Igor Stoppa Igor Stoppa
M:
E: igor.stoppa@huawei.com
2012=CA=B5=D1=E9=CA=D2-=BA=D5=B6=FB=D0=C1=BB=F9=D1= =D0=BE=BF=CB=F9
2012 Laboratories-Helsinki Research Center
From:Laura Abbott
To:Kees Cook,Igor Stoppa,
Cc:Boris Lukashev,Christopher La= meter,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@hu= awei.com> wrote:
>>
>> [...]
>>
>>>> What you are suggesting, if I have understood it correctly= , is that,
>>>> when the pool is protected, the addresses already given ou= t, will become
>>>> traps that get resolved through a lookup table that is bui= lt based on
>>>> the content of each allocation.
>>>>
>>>> That seems to generate a lot of overhead, not to mention t= he fact that
>>>> it might not play very well with the MMU.
>>>
>>> That is effectively what i'm suggesting - as a form of protect= ion for
>>> consumers against direct reads of data which may have been cor= rupted
>>> 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 me= rged :-)
>>
>> 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
 --_000_688F43F436AB4D988B8234437CFD85BC_-- -- 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