From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x224KnRNhw9BYVo/GsPDFQUA2dak4QXmvqgbvHJWnvECJoHPjtW7qf2yGUNDv9C3dAQxSqCUi ARC-Seal: i=1; a=rsa-sha256; t=1517344723; cv=none; d=google.com; s=arc-20160816; b=XHEmY3UU5O3dpN7NgCCrDMHN4CCnjkHe5YxZp1HidxtFACkE+u2YGFSPUvHuaDHHKz pS7TG/ElAY0hqEMaej8lsVAklHs7/zfB7PDaya5bKMaHEQxOsJ5Y4qVXjD91LLO6m7VI dx1P5XitDjKXCLFNZX11Pv49Myb8X9D1GFaJW+FUbYXNwJdUFRT6/ABpr9mSuWGM76nu igOnrNMumQHL4P42x6x00vNyvy/Hof0o8ONvrmpT/DvgcNIUNXEW0Uz+7QazNhIxUicD 2sn9wWEzygD1+8zWxd1FZL7mx8H/Ylp7xhn0baEfuzPfRdN3n0k6EpfGenxL1EX1iKbf DjBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:arc-authentication-results; bh=1IBO06+duIUdburC8ZkIlsbfZcbmhCbPhTz0Dxr7hTA=; b=ZHS/0Jp8+2z8Nbk7BVZQeEuAj/g0e2WUBepm8GNcEL8FwArZhmwEYys+6h8zbVYa1e wWQvMCIYiVmvT5Ck9a9UgLqr6oFuN73+JTmFBYlYV5YI7b3DVPHa+q13GoQIO1mA4koi t0UC3iE1npzKnL8TDkbwOFx0tCLnUhROKVsJiKyGwwudW+z2LSjRSDkwQjbi7QiV3tK7 ZENHYjZTeUCPCoK1M1dRLLvKOGhRhCm7b3Bytlch+SbS1CpxrQGrf0DYxU+pSgwi6IQ+ LBlBk48ogLUBHZGYdRbr7u3JQVQxjNeMR9RJ9t3wuBXaysnuSBzDOnhAKqqXXOj5wsg7 d9Pg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de Authentication-Results: mx.google.com; spf=pass (google.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de Date: Tue, 30 Jan 2018 21:38:36 +0100 From: Borislav Petkov To: David Woodhouse 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) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590966106432961445?= X-GMAIL-MSGID: =?utf-8?q?1591051261071541384?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: 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.