Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753296AbeADU47 (ORCPT + 1 other); Thu, 4 Jan 2018 15:56:59 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:45436 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752552AbeADU44 (ORCPT ); Thu, 4 Jan 2018 15:56:56 -0500 Date: Thu, 4 Jan 2018 21:56:54 +0100 From: Pavel Machek To: "Eric W. Biederman" Cc: Dan Williams , "torvalds@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "peterz@infradead.org" , "tglx@linutronix.de" , "alan@linux.intel.com" , "Reshetova, Elena" , "mark.rutland@arm.com" , "gnomes@lxorguk.ukuu.org.uk" , "gregkh@linuxfoundation.org" , "jikos@kernel.org" , "linux-arch@vger.kernel.org" Subject: Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier Message-ID: <20180104205654.GE10427@amd> References: <151502463248.33513.5960736946233335087.stgit@dwillia2-desk3.amr.corp.intel.com> <20180104010754.22ca6a74@alans-desktop> <1515035438.20588.4.camel@intel.com> <87vagiusj1.fsf@xmission.com> <87wp0xu12k.fsf@xmission.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ryJZkp9/svQ58syV" Content-Disposition: inline In-Reply-To: <87wp0xu12k.fsf@xmission.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: --ryJZkp9/svQ58syV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > > It falls there so that the cpu only issues reads with known good 'index= ' values. > > > >> I suspect it would be better to have those barriers in the tun/tap > >> interfaces where userspace can inject packets and thus time them. Then > >> the code could still speculate and go fast for remote packets. > >> > >> Or does the speculation stomping have to be immediately at the place > >> where we use data from userspace to perform a table lookup? > > > > The speculation stomping barrier has to be between where we validate > > the input and when we may speculate on invalid input. >=20 > So a serializing instruction at the kernel/user boundary (like say > loading cr3) is not enough? That would seem to break any chance of a > controlled timing. Timing attack is not as straightforward as this. You can assume cache snooping from second CPU _while_ kernel is executing. Yes, that will mean timing, but.... Best regards, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --ryJZkp9/svQ58syV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlpOlRYACgkQMOfwapXb+vLb6wCfWYgmH4BO9HC99ipYpXHfO5kv X9sAoLAEQQmL1/ovZVnhlAtm+IlQa5Rl =09LP -----END PGP SIGNATURE----- --ryJZkp9/svQ58syV--