From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,
	RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 28748 invoked from network); 14 Jan 2022 13:36:55 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 14 Jan 2022 13:36:55 -0000
Received: (qmail 20094 invoked by uid 550); 14 Jan 2022 13:36:48 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 19966 invoked from network); 14 Jan 2022 13:36:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1642167395;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=n+u9lImGJHsltEhgnOxi+5lKtT79IMZvETmYQxQXldM=;
	b=H4a0F/783qn7pxlfkP9k56qhmXvcE2qqE/n4Vr64y/437F8edQgXX4CEQKkiU9G4Z6Dhlb
	d44TFKzt7CA3tfx2FfutzYKLZOMPSufH6oH8xYTni5Y9LaD0Vp0fL6xxOp9VADG9j8EwY2
	3akRAwjzjK7AJu5lXFdcR4OMD6qYH1o=
X-MC-Unique: eQAah2ufPRiIcSj7ZNrWFg-1
From: Florian Weimer <fweimer@redhat.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: linux-arch@vger.kernel.org,  Linux API <linux-api@vger.kernel.org>,
  linux-x86_64@vger.kernel.org,  kernel-hardening@lists.openwall.com,
  linux-mm@kvack.org,  the arch/x86 maintainers <x86@kernel.org>,
  musl@lists.openwall.com,  libc-alpha@sourceware.org,
  linux-kernel@vger.kernel.org,  Dave Hansen <dave.hansen@intel.com>,  Kees
 Cook <keescook@chromium.org>,  Andrei Vagin <avagin@gmail.com>
References: <3a1c8280967b491bf6917a18fbff6c9b52e8df24.1641398395.git.fweimer@redhat.com>
	<e431fa42-26ec-8ac6-f954-e681b1e0e9a6@kernel.org>
Date: Fri, 14 Jan 2022 14:36:24 +0100
In-Reply-To: <e431fa42-26ec-8ac6-f954-e681b1e0e9a6@kernel.org> (Andy
	Lutomirski's message of "Thu, 13 Jan 2022 13:47:26 -0800")
Message-ID: <87sftqtp5z.fsf@oldenburg.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
Subject: [musl] Re: [PATCH v3 1/3] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL)
 to disable vsyscall

* Andy Lutomirski:

> Is there a reason you didn't just change the check earlier in the
> function to:
>
> if (vsyscall_mode == NONE || current->mm->context.vsyscall_disabled)

Andrei requested that I don't print anything if vsyscall was disabled.

The original patch used a different message for better diagnostics.

> Also, I still think the prctl should not be available if
> vsyscall=emulate.  Either we should fully implement it or we should
> not implement.  We could even do:
>
> pr_warn_once("userspace vsyscall hardening request ignored because you
> have vsyscall=emulate.  Unless you absolutely need vsyscall=emulate, 
> update your system to use vsyscall=xonly.\n");
>
> and thus encourage good behavior.

I think there is still some hardening applied even with
vsyscall=emulate.  The question is what is more important: the
additional hardening, or clean, easily described behavior of the
interface.

Maybe ARCH_VSYSCALL_CONTROL could return different values based on to
what degree it could disable vsyscall?

The pr_warn_once does not seem particularly useful.  Anyone who upgrades
glibc and still uses vsyscall=emulate will see that, with no way to
disable it.

Thanks,
Florian