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 S1755369AbcIUBSG (ORCPT <rfc822;w@1wt.eu>);
        Tue, 20 Sep 2016 21:18:06 -0400
Received: from terminus.zytor.com ([198.137.202.10]:42916 "EHLO mail.zytor.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753374AbcIUBSE (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 20 Sep 2016 21:18:04 -0400
Subject: Re: [RFC 0/3] Put vdso in ramfs-like filesystem (vdsofs)
To: Andy Lutomirski <luto@amacapital.net>
References: <20160825152110.25663-1-dsafonov@virtuozzo.com>
 <3AD1D5AF-552E-4345-855A-36ECC4B545DE@zytor.com>
 <CAJwJo6ZSO9+hHy5a1_yE3LE=fvJ_cUum_CBuCUq4d5+0iAcOqg@mail.gmail.com>
 <6d16fdfe-582e-fa4a-9d51-49bd07a22945@zytor.com>
 <efca16f2-8c83-9605-56b2-4a80af0753fc@zytor.com>
 <CALCETrVGouJVpCNdioDGt551twHpcZEqvr-GiMrEW1=FozA7VQ@mail.gmail.com>
 <6de39359-511e-1ce9-9201-85bd3425a05d@zytor.com>
Cc: Dmitry Safonov <0x7f454c46@gmail.com>,
        Dmitry Safonov <dsafonov@virtuozzo.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Ingo Molnar <mingo@redhat.com>, Thomas Gleixner <tglx@linutronix.de>,
        X86 ML <x86@kernel.org>, Oleg Nesterov <oleg@redhat.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Al Viro <viro@zeniv.linux.org.uk>
From: "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <9f45c6d8-df97-6135-a771-d800e73b2fdc@zytor.com>
Date: Tue, 20 Sep 2016 18:17:13 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <6de39359-511e-1ce9-9201-85bd3425a05d@zytor.com>
Content-Type: text/plain; charset=utf-8
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 09/20/16 18:07, H. Peter Anvin wrote:
> 
>>  - vvar is highly magical.  IMO letting it get mapped with VM_MAYWRITE
>> is asking for trouble, as anything that writes it will COW it, leading
>> to strange malfunctions.
>>

The vvar page obviously needs to be mapped MAP_SHARED, and the
underlying file needs to reject writes.  A solution where this area
doesn't end up MAP_SHARED is obviously defective.

As far as keeping the user from doing really stupid things... they can
map a RAM page over the vvar area and there is nothing the kernel really
can do to keep them from doing something like that without doing things
that are probably way worse than the disease.  At least it will be
obvious looking at the mapping file what is going on.

	-hpa