Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 30 Jan 2018 21:38:36 +0100
From:   Borislav Petkov <bp@alien8.de>
To:     David Woodhouse <dwmw@amazon.co.uk>
Cc:     arjan@linux.intel.com, tglx@linutronix.de, karahmed@amazon.de,
        x86@kernel.org, linux-kernel@vger.kernel.org,
        tim.c.chen@linux.intel.com, peterz@infradead.org,
        pbonzini@redhat.com, ak@linux.intel.com,
        torvalds@linux-foundation.org, gregkh@linux-foundation.org,
        mingo@kernel.org, luto@kernel.org, linux@dominikbrodowski.net
Subject: Re: [PATCH] x86/speculation: Use Indirect Branch Prediction Barrier
 in context switch
Message-ID: <20180130203836.bsgme6kf6hstgbrx@pd.tnic>
References: <1517263487-3708-1-git-send-email-dwmw@amazon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <1517263487-3708-1-git-send-email-dwmw@amazon.co.uk>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Jan 29, 2018 at 10:04:47PM +0000, David Woodhouse wrote:
> +		if (tsk && tsk->mm &&
> +		    tsk->mm->context.ctx_id != last_ctx_id &&
> +		    get_dumpable(tsk->mm) != SUID_DUMP_USER)
> +			indirect_branch_prediction_barrier();

Ok, so while staring at this, someone just came up with the following
sequence:

1. Malicious process runs with UID=A, does BTB poisoning
2. Sensitive process (e.g. gpg) starts also with UID=A, no IBPB flush occurs since task is initially dumpable
3. gpg now does prctl(PR_SET_DUMPABLE, ...) to clear the dumpable flag
4. gpg now does sensitive stuff that it thinks is protected
5. gpg does indirect branches that shouldn't be influenced by the malicious process

Now, if you switch between steps 3. and 4., you're good because gpg
became non-dumpable. But if you *don't* switch, the bad BTB entries are
still there.

So, *actually*, we need to flush IBPB in set_dumpable() too, when we
clear SUID_DUMP_USER.

Or, are we missing something obvious here and that is not needed because
of reasons I haven't thought about?

I know, gpg doesn't do prctl() but disables core dumping with
setrlimit() but there might be other processes who do that...

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.