linux-s390.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
To: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	kvm@vger.kernel.org, Heiko Carstens <heiko.carstens@de.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	David Hildenbrand <david@redhat.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jon Masters <jcm@redhat.com>, Marcus Meissner <meissner@suse.de>,
	Jiri Kosina <jkosina@suse.cz>,
	w@1wt.eu, keescook@chromium.org, thomas.lendacky@amd.com,
	dwmw@amazon.co.uk, ak@linux.intel.com, pavel@ucw.cz
Subject: Re: Avoiding information leaks between users and between processes by default? [Was: : [PATCH 1/5] prctl: add PR_ISOLATE_BP process control]
Date: Wed, 24 Jan 2018 15:42:54 +0000	[thread overview]
Message-ID: <20180124154254.318ddde4@alans-desktop> (raw)
In-Reply-To: <20180124083705.GA14868@light.dominikbrodowski.net>

On Wed, 24 Jan 2018 09:37:05 +0100
> To my understanding, Linux traditionally tried to aim for the security goal
> of avoiding information leaks *between* users[+], probably even between
> processes of the same user. It wasn't a guarantee, and there always were

Not between processes of the same user in general (see ptrace or use gdb).

> (and will be) information leaks -- and that is where additional safeguards
> such as seccomp come into play, which reduce the attack surface against

seccomp is irrelevant on many processors (see the Armageddon paper). You
can (given willing partners) transfer data into and out of a seccomp
process at quite a respectable rate depending upon your hardware features.

> I am a bit worried whether this is a sign for a shift in the security goals.
> I fully understand that there might be processes (e.g. some[?] kernel
> threads) and users (root) which you need to trust anyway, as they can

dumpable is actually very useful but only in a specific way. The question
if process A is dumpable by process B then there is no meaningful
protection between them and you don't need to do any work. Likewise if A
and B can dump each other and are both running on the same ht pair you
don't have to worry about them attacking one another. In all those cases
they can do it with ptrace already.

[There's a corner case here of using BPF filters to block ptrace]

Alan

  parent reply	other threads:[~2018-01-24 15:42 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-23 13:07 [RFC][PATCH 0/5] s390: improve speculative execution handling v2 Martin Schwidefsky
2018-01-23 13:07 ` [PATCH 1/5] prctl: add PR_ISOLATE_BP process control Martin Schwidefsky
2018-01-23 17:07   ` Dominik Brodowski
2018-01-24  6:29     ` Martin Schwidefsky
2018-01-24  8:37       ` Avoiding information leaks between users and between processes by default? [Was: : [PATCH 1/5] prctl: add PR_ISOLATE_BP process control] Dominik Brodowski
2018-01-24  9:24         ` David Woodhouse
2018-01-24 11:15         ` Pavel Machek
2018-01-24 12:48           ` Martin Schwidefsky
2018-01-24 19:01             ` Pavel Machek
2018-01-24 20:46               ` Alan Cox
2018-01-29 13:14                 ` Pavel Machek
2018-01-29 20:12                   ` Alan Cox
2018-01-24 15:42         ` Alan Cox [this message]
2018-01-24  8:08     ` [PATCH 1/5] prctl: add PR_ISOLATE_BP process control Christian Borntraeger
2018-01-23 13:07 ` [PATCH 2/5] s390/alternative: use a copy of the facility bit mask Martin Schwidefsky
2018-01-23 13:59   ` Cornelia Huck
2018-01-23 14:40     ` Martin Schwidefsky
2018-01-23 15:04       ` Cornelia Huck
2018-01-23 13:07 ` [PATCH 3/5] s390: add options to change branch prediction behaviour for the kernel Martin Schwidefsky
2018-01-23 13:07 ` [PATCH 4/5] s390: define ISOLATE_BP to run tasks with modified branch prediction Martin Schwidefsky
2018-01-23 14:21   ` Christian Borntraeger
2018-01-23 20:32     ` Radim Krčmář
2018-01-24  6:36       ` Martin Schwidefsky
2018-01-24 11:50         ` Radim Krčmář
2018-01-23 13:07 ` [PATCH 5/5] s390: scrub registers on kernel entry and KVM exit Martin Schwidefsky
2018-01-23 13:09   ` Christian Borntraeger
2018-01-23 14:32     ` Martin Schwidefsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180124154254.318ddde4@alans-desktop \
    --to=gnomes@lxorguk.ukuu.org.uk \
    --cc=ak@linux.intel.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=dwmw@amazon.co.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=jcm@redhat.com \
    --cc=jkosina@suse.cz \
    --cc=keescook@chromium.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=meissner@suse.de \
    --cc=pavel@ucw.cz \
    --cc=pbonzini@redhat.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=thomas.lendacky@amd.com \
    --cc=w@1wt.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).