From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x226zoeC8tGk2p+xXxFqITtaHJPFZoPpg0I8nB0Uhe8yhI+9m4Lu25JcrR/MqvDppsZtWDAiP ARC-Seal: i=1; a=rsa-sha256; t=1517346202; cv=none; d=google.com; s=arc-20160816; b=Fh2+cm//LCxmsmV2leyaajwSSVJwRxqmrjHMN3P33TP8SgUO+8mMgBZUh/+hztiXPE hdtPDsuzZqSR94RysVb42d4vu2BLo+vQFwfxCbRZNELtNXP7piKTdwhraxQQ3owyfxGt yX+DORtiC/xMz0Tfa9T2HtdgWQ0MchMiygzOjIW8Fy3HnUwibMyueEpQhTkooECYU5za rXLSF7sbQfarSjyF75aAPH8I59TlTfsBPh+eB0qvl4wQjeMOzh582kUrS4JNoME1BVrq PtszmzOAmRK3JU/6rbIzAQ1WIHU7SEABRJr9945z3weaSER4p2R/jJg5Xmt8u5LpDrGj lPiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :arc-authentication-results; bh=+TvFVOIhVuIWDqfv4T6l/goGBtIny5Hh8z1vyoDGMe8=; b=kJE4RM+KVjtC1Seio+CLNk7jpf7yjFppk9BsisBQwxiItQeDRVgDi+o3YtUS6WRFd7 +9+tGz5+G82MBfJ856t4kWciJtOFW9wrcn4r+Gm9/J4cDYKxRV55/aeKexfST+n8BtM5 aveihmNanp4i7WWHax+uN9YMsMZAk1j9MVC7NMVdD4sMNmnmMetWNU37PD5MKwpViULc 7rR+EJlI+UdaxgTbdHahy3U/2iTBIwGG17OGofzoDql35G1QjaQPdGdSzKdxeBji8pzf vkRIaCSLzsgEBOdFilOaA3rL6/fyDxe7Ir2tMgKeAMW4tl3rQkn6/egdpLCq6xc0h7RP lroA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of tim.c.chen@linux.intel.com designates 192.55.52.88 as permitted sender) smtp.mailfrom=tim.c.chen@linux.intel.com Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of tim.c.chen@linux.intel.com designates 192.55.52.88 as permitted sender) smtp.mailfrom=tim.c.chen@linux.intel.com X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,436,1511856000"; d="scan'208";a="14662647" Subject: Re: [PATCH] x86/speculation: Use Indirect Branch Prediction Barrier in context switch To: Borislav Petkov , David Woodhouse Cc: arjan@linux.intel.com, tglx@linutronix.de, karahmed@amazon.de, x86@kernel.org, linux-kernel@vger.kernel.org, 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 References: <1517263487-3708-1-git-send-email-dwmw@amazon.co.uk> <20180130203836.bsgme6kf6hstgbrx@pd.tnic> From: Tim Chen Message-ID: <024dd53b-1912-34fa-deb8-550c111df521@linux.intel.com> Date: Tue, 30 Jan 2018 13:03:20 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <20180130203836.bsgme6kf6hstgbrx@pd.tnic> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590966106432961445?= X-GMAIL-MSGID: =?utf-8?q?1591052811737132424?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 01/30/2018 12:38 PM, Borislav Petkov wrote: > 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. The attacker has to guarantee itself to run right before victim. And the window of attack is very small, as only the first context switch to victim may be vulnerable. The victim will be immune on the next switch. For timing attack, the attacker needs to scan one bit at a time. So probably the attacker could glean 1 bit of information on the switch back to the attacker and then the attacker could not scan further. So it doesn't seem to be very practical attack if the victim has set itself to be non-dumpable. Tim > > 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. >