From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755923AbbCSNYq (ORCPT <rfc822;w@1wt.eu>);
	Thu, 19 Mar 2015 09:24:46 -0400
Received: from forward-corp1g.mail.yandex.net ([95.108.253.251]:34103 "EHLO
	forward-corp1g.mail.yandex.net" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1751381AbbCSNYp (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 19 Mar 2015 09:24:45 -0400
Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru
Message-ID: <550ACE17.9040600@yandex-team.ru>
Date: Thu, 19 Mar 2015 16:24:39 +0300
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Vlastimil Babka <vbabka@suse.cz>,
        "Kirill A. Shutemov" <kirill@shutemov.name>,
        Konstantin Khlebnikov <koct9i@gmail.com>
CC: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Andy Lutomirski <luto@amacapital.net>
Subject: Re: [PATCH RFC] mm: protect suid binaries against rowhammer with
 copy-on-read mappings
References: <20150318083040.7838.76933.stgit@zurg> <20150318095702.GA2479@node.dhcp.inet.fi> <5509644C.40502@yandex-team.ru> <550AC958.9010502@suse.cz>
In-Reply-To: <550AC958.9010502@suse.cz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 19.03.2015 16:04, Vlastimil Babka wrote:
> On 03/18/2015 12:41 PM, Konstantin Khlebnikov wrote:
>> On 18.03.2015 12:57, Kirill A. Shutemov wrote:
>>>
>>> I don't think it worth it. The only right way to fix the problem is ECC
>>> memory.
>>>
>>
>> ECC seems good protection until somebody figure out how to break it too.
>
> I doubt that kind of attitude can get us very far. If we can't trust the
> hardware, we lose sooner or later.
>

Obviously ECC was designed for protecting against cosmic rays which 
flips several bits. If attacker modifies whole cacheline he can chose
value which have the same ECC. I hope next generation of DRAM (or PRAM)
wouldn't be affected.

Software solution is possible: we can put untrusted applications into
special ghetto memory zone. This is relatively easy for virtual 
machines. And it seems might work for normal tasks too (page-cache
pages should be doubled or handled in the way similar to copy-on-read
from that patch).

-- 
Konstantin