mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: andrea@cpushare.com
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Lee Revell <rlrevell@joe-job.com>, Dave Jones <davej@redhat.com>,
	Matt Mackall <mpm@selenic.com>, Andy Isaacson <adi@hexapodia.org>,
	Andi Kleen <ak@muc.de>, "Richard F. Rebel" <rrebel@whenu.com>,
	Gabor MICSKO <gmicsko@szintezis.hu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	tytso@mit.edu, Andrew Morton <akpm@osdl.org>
Subject: Re: Hyper-Threading Vulnerability
Date: Sat, 14 May 2005 17:45:38 +0200	[thread overview]
Message-ID: <20050514154538.GB6695@g5.random> (raw)
In-Reply-To: <1116084186.20545.47.camel@localhost.localdomain>

On Sat, May 14, 2005 at 04:23:10PM +0100, Alan Cox wrote:
> You cannot use rdtsc for anything but rough instruction timing. The
> timers for different processors run at different speeds on some SMP
> systems, the timer rates vary as processors change clock rate nowdays.
> Rdtsc may also jump dramatically on a suspend/resume.

x86-64 uses it for vgettimeofday very safely (i386 could do too but it
doesn't).

Anyway I believe at least for seccomp it's worth to turn off the tsc,
not just for HT but for the L2 cache too. So it's up to you, either you
turn it off completely (which isn't very nice IMHO) or I recommend to
apply this below patch. This has been tested successfully on x86-64
against current cogito repository (i686 compiles so I didn't bother
testing ;). People selling the cpu through cpushare may appreciate this
bit for a peace of mind. There's no way to get any timing info anymore
with this applied (gettimeofday is forbidden of course). The seccomp
environment is completely deterministic so it can't be allowed to get
timing info, it has to be deterministic so in the future I can enable a
computing mode that does a parallel computing for each task with server
side transparent checkpointing and verification that the output is the
same from all the 2/3 seller computers for each task, without the buyer
even noticing (for now the verification is left to the buyer client
side and there's no checkpointing, since that would require more kernel
changes to track the dirty bits but it'll be easy to extend once the
basic mode is finished).

Thanks.

Signed-off-by: Andrea Arcangeli <andrea@cpushare.com>

Index: arch/i386/kernel/process.c
===================================================================
--- eed337ef5e9ae7d62caa84b7974a11fddc7f06e0/arch/i386/kernel/process.c  (mode:100644)
+++ uncommitted/arch/i386/kernel/process.c  (mode:100644)
@@ -561,6 +561,25 @@
 }
 
 /*
+ * This function selects if the context switch from prev to next
+ * has to tweak the TSC disable bit in the cr4.
+ */
+static void disable_tsc(struct thread_info *prev,
+			struct thread_info *next)
+{
+	if (unlikely(has_secure_computing(prev) ||
+		     has_secure_computing(next))) {
+		/* slow path here */
+		if (has_secure_computing(prev) &&
+		    !has_secure_computing(next)) {
+			clear_in_cr4(X86_CR4_TSD);
+		} else if (!has_secure_computing(prev) &&
+			   has_secure_computing(next))
+			set_in_cr4(X86_CR4_TSD);
+	}
+}
+
+/*
  *	switch_to(x,yn) should switch tasks from x to y.
  *
  * We fsave/fwait so that an exception goes off at the right time
@@ -639,6 +658,8 @@
 	if (unlikely(prev->io_bitmap_ptr || next->io_bitmap_ptr))
 		handle_io_bitmap(next, tss);
 
+	disable_tsc(prev_p->thread_info, next_p->thread_info);
+
 	return prev_p;
 }
 
Index: arch/x86_64/kernel/process.c
===================================================================
--- eed337ef5e9ae7d62caa84b7974a11fddc7f06e0/arch/x86_64/kernel/process.c  (mode:100644)
+++ uncommitted/arch/x86_64/kernel/process.c  (mode:100644)
@@ -439,6 +439,25 @@
 }
 
 /*
+ * This function selects if the context switch from prev to next
+ * has to tweak the TSC disable bit in the cr4.
+ */
+static void disable_tsc(struct thread_info *prev,
+			struct thread_info *next)
+{
+	if (unlikely(has_secure_computing(prev) ||
+		     has_secure_computing(next))) {
+		/* slow path here */
+		if (has_secure_computing(prev) &&
+		    !has_secure_computing(next)) {
+			clear_in_cr4(X86_CR4_TSD);
+		} else if (!has_secure_computing(prev) &&
+			   has_secure_computing(next))
+			set_in_cr4(X86_CR4_TSD);
+	}
+}
+
+/*
  * This special macro can be used to load a debugging register
  */
 #define loaddebug(thread,r) set_debug(thread->debugreg ## r, r)
@@ -556,6 +575,8 @@
 		}
 	}
 
+	disable_tsc(prev_p->thread_info, next_p->thread_info);
+
 	return prev_p;
 }
 
Index: include/linux/seccomp.h
===================================================================
--- eed337ef5e9ae7d62caa84b7974a11fddc7f06e0/include/linux/seccomp.h  (mode:100644)
+++ uncommitted/include/linux/seccomp.h  (mode:100644)
@@ -19,6 +19,11 @@
 		__secure_computing(this_syscall);
 }
 
+static inline int has_secure_computing(struct thread_info *ti)
+{
+	return unlikely(test_ti_thread_flag(ti, TIF_SECCOMP));
+}
+
 #else /* CONFIG_SECCOMP */
 
 #if (__GNUC__ > 2)
@@ -28,6 +33,7 @@
 #endif
 
 #define secure_computing(x) do { } while (0)
+#define has_secure_computing(x) 0
 
 #endif /* CONFIG_SECCOMP */
 

  reply	other threads:[~2005-05-14 15:46 UTC|newest]

Thread overview: 144+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-13  5:51 Gabor MICSKO
2005-05-13 12:47 ` Barry K. Nathan
2005-05-13 14:10   ` Jeff Garzik
2005-05-13 14:23     ` Daniel Jacobowitz
2005-05-13 14:32       ` Jeff Garzik
2005-05-13 17:13         ` Andy Isaacson
2005-05-13 18:30           ` Vadim Lobanov
2005-05-13 19:02             ` Andy Isaacson
2005-05-15  9:31               ` Adrian Bunk
2005-05-13 17:14         ` Gabor MICSKO
2005-05-13 20:23     ` Barry K. Nathan
2005-05-13 18:03 ` Andi Kleen
2005-05-13 18:34   ` Eric Rannaud
2005-05-13 18:35   ` Alan Cox
2005-05-13 18:49     ` Scott Robert Ladd
2005-05-13 19:08       ` Andi Kleen
2005-05-13 19:36       ` Grant Coady
2005-05-16 17:00       ` Linus Torvalds
2005-05-16 12:37         ` Tommy Reynolds
2005-05-18 19:07     ` Bill Davidsen
2005-05-13 18:38   ` Richard F. Rebel
2005-05-13 19:05     ` Andi Kleen
2005-05-13 21:26       ` Andy Isaacson
2005-05-13 21:59         ` Matt Mackall
2005-05-13 22:47           ` Alan Cox
2005-05-13 23:00             ` Lee Revell
2005-05-13 23:27               ` Dave Jones
2005-05-13 23:38                 ` Lee Revell
2005-05-13 23:44                   ` Dave Jones
2005-05-14  7:37                     ` Lee Revell
2005-05-14 15:33                       ` Andrea Arcangeli
2005-05-15  1:07                         ` Christer Weinigel
2005-05-15  9:48                         ` Andi Kleen
2005-05-14 15:23                   ` Alan Cox
2005-05-14 15:45                     ` andrea [this message]
2005-05-15 13:38                       ` Mikulas Patocka
2005-05-16  7:06                         ` andrea
2005-05-14 16:30                     ` Lee Revell
2005-05-14 16:44                       ` Arjan van de Ven
2005-05-14 17:56                         ` Lee Revell
2005-05-14 18:01                           ` Arjan van de Ven
2005-05-14 19:21                             ` Lee Revell
2005-05-14 19:48                               ` Arjan van de Ven
2005-05-14 23:40                                 ` Lee Revell
2005-05-15  7:30                                   ` Arjan van de Ven
2005-05-15 20:41                                     ` Alan Cox
2005-05-15 20:48                                       ` Arjan van de Ven
2005-05-15 21:10                                         ` Lee Revell
2005-05-15 22:55                                           ` Dave Jones
2005-05-15 23:10                                             ` Lee Revell
2005-05-16  7:25                                               ` Arjan van de Ven
2005-05-15  9:37                                   ` Andi Kleen
2005-05-15  3:19                                 ` dean gaudet
2005-05-15 10:01                             ` Andi Kleen
2005-05-15 10:23                               ` 2.6.4 timer and helper functions kernel
2005-05-19  0:38                                 ` George Anzinger
2005-05-15  9:33                           ` Hyper-Threading Vulnerability Adrian Bunk
2005-05-14 17:04                       ` Jindrich Makovicka
2005-05-14 18:27                         ` Lee Revell
2005-05-15  9:58                       ` Andi Kleen
2005-05-14  0:39         ` dean gaudet
2005-05-16 13:41           ` Andrea Arcangeli
2005-05-15  9:43         ` Andi Kleen
2005-05-15 18:42           ` David Schwartz
2005-05-15 18:56             ` Dr. David Alan Gilbert
2005-05-16  7:10           ` Eric W. Biederman
2005-05-16 11:04             ` Andi Kleen
2005-05-16 19:14               ` Eric W. Biederman
2005-05-16 20:05                 ` Valdis.Kletnieks
2005-05-15 14:00         ` Mikulas Patocka
2005-05-15 14:26         ` Andi Kleen
2005-05-13 23:32       ` Paul Jakma
2005-05-14 16:29         ` Paul Jakma
2005-05-13 19:14     ` Jim Crilly
2005-05-13 20:18       ` Barry K. Nathan
2005-05-13 23:14         ` Jim Crilly
2005-05-13 19:16   ` Diego Calleja
2005-05-13 19:42     ` Frank Denis (Jedi/Sector One)
2005-05-15  9:54     ` Andi Kleen
2005-05-15 13:51       ` Mikulas Patocka
2005-05-15 14:12         ` Andi Kleen
2005-05-15 14:21           ` Mikulas Patocka
2005-05-15 14:52           ` Tomasz Torcz
2005-05-15 15:00             ` Disk write cache (Was: Hyper-Threading Vulnerability) Mikulas Patocka
2005-05-15 15:21               ` Gene Heskett
2005-05-15 15:29                 ` Jeff Garzik
2005-05-15 16:27                   ` Disk write cache Kenichi Okuyama
2005-05-15 16:43                     ` Jeff Garzik
2005-05-15 16:50                       ` Kyle Moffett
2005-05-15 16:56                       ` Andi Kleen
2005-05-15 20:44                         ` Andrew Morton
2005-05-15 23:31                           ` Cache based insecurity/CPU cache/Disk Cache Tradeoffs Brian O'Mahoney
2005-05-15 16:58                       ` Disk write cache Mikulas Patocka
2005-05-15 17:20                       ` Kenichi Okuyama
2005-05-16 11:02                       ` Linux does not care for data integrity (was: Disk write cache) Matthias Andree
2005-05-16 11:12                         ` Arjan van de Ven
2005-05-16 11:29                           ` Matthias Andree
2005-05-16 14:02                             ` Arjan van de Ven
2005-05-16 14:48                               ` Matthias Andree
2005-05-16 15:06                                 ` Alan Cox
2005-05-16 15:40                                   ` Matthias Andree
2005-05-16 18:04                                     ` Alan Cox
2005-05-16 19:11                                       ` Linux does not care for data integrity Florian Weimer
2005-05-29 21:02                                   ` Linux does not care for data integrity (was: Disk write cache) Greg Stark
2005-05-29 21:16                                     ` Matthias Andree
2005-05-30  6:04                                       ` Greg Stark
2005-05-30  8:21                                         ` Matthias Andree
2005-06-01 19:02                                       ` Linux does not care for data integrity Bill Davidsen
2005-06-01 22:02                                         ` Matthias Andree
2005-06-02  0:12                                           ` Bill Davidsen
2005-06-02  0:36                                         ` Jeff Garzik
2005-06-02  1:37                                           ` Bill Davidsen
2005-06-02  1:54                                             ` Jeff Garzik
2005-06-02  8:53                                         ` Helge Hafting
2005-06-02 12:00                                           ` Bill Davidsen
2005-06-02 13:33                                             ` Lennart Sorensen
2005-06-04 13:37                                               ` Bill Davidsen
2005-06-04 15:31                                                 ` Bernd Eckenfels
2005-05-16 14:57                           ` Linux does not care for data integrity (was: Disk write cache) Alan Cox
2005-05-16 13:48                         ` Linux does not care for data integrity Mark Lord
2005-05-16 14:59                           ` Matthias Andree
2005-05-16  1:56                   ` Disk write cache (Was: Hyper-Threading Vulnerability) Gene Heskett
2005-05-16  2:11                     ` Jeff Garzik
2005-05-16  2:24                     ` Mikulas Patocka
2005-05-16  3:05                       ` Gene Heskett
2005-05-16  2:32                     ` Mark Lord
2005-05-16  3:08                       ` Gene Heskett
2005-05-16 13:44                         ` Mark Lord
2005-05-18  4:03                       ` Eric D. Mudama
2005-05-15 16:24                 ` Mikulas Patocka
2005-05-16 11:18                   ` Matthias Andree
2005-05-16 14:33                     ` Jeff Garzik
2005-05-16 15:26                       ` Richard B. Johnson
2005-05-16 16:00                         ` [OT] drive behavior on power-off (was: Disk write cache) Matthias Andree
2005-05-16 18:11                       ` Disk write cache (Was: Hyper-Threading Vulnerability) Valdis.Kletnieks
2005-05-16 14:54                     ` Alan Cox
2005-05-17 13:15                       ` Bill Davidsen
2005-05-17 21:41                         ` Kyle Moffett
2005-05-18  4:06                     ` Eric D. Mudama
2005-05-15 21:38                 ` Tomasz Torcz
2005-05-16 14:50               ` Alan Cox
2005-05-15 15:00             ` Hyper-Threading Vulnerability Arjan van de Ven
2005-05-13 22:51 linux
2005-05-14  8:03 ` Arjan van de Ven

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=20050514154538.GB6695@g5.random \
    --to=andrea@cpushare.com \
    --cc=adi@hexapodia.org \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davej@redhat.com \
    --cc=gmicsko@szintezis.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=rlrevell@joe-job.com \
    --cc=rrebel@whenu.com \
    --cc=tytso@mit.edu \
    /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

all inboxes | Powered by JetHome®