Re: Hyper-Threading Vulnerability

andrea_at_cpushare.com
Date: 05/14/05

  • Next message: Tejun Heo: "Re: [PATCH scsi-misc-2.6 04/04] scsi: remove unnecessary scsi_wait_req_end_io()" 
    Date:	Sat, 14 May 2005 17:45:38 +0200
To: Alan Cox <alan@lxorguk.ukuu.org.uk>

    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 */
     
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Tejun Heo: "Re: [PATCH scsi-misc-2.6 04/04] scsi: remove unnecessary scsi_wait_req_end_io()"

    Relevant Pages

    • Re: No difference on my machine
      ... show better reproducable timing values. ... Apparently 300 cycles on my machine. ... My understanding is that without a serializing instruction, ... come from after the rdtsc in our code, ...
      (alt.lang.asm)
    • Re: Calculating a programs run time
      ... instructions should be: ... The hardware doesn't switch rdtsc over to producing a 64-bit result in a single register; it still uses the 32-bit style of producing a 64-bit result in 2 registers. ... clock ticks, but in the most recent models, it counts front side bus ticks, multiplied by the design value of the clock speed multiplier. ... The reason for the change is to permit timing to work across clock speed frequency changes, such as occur with "Demand Based Switching" to reduce idle power consumption. ...
      (comp.lang.fortran)
    • Re: Scalable hash map: The defeat of lock-based synchronization
      ... You can look into ffmpeg's timing ... If I recall correctly, using rdtsc ... measuring every operation will give you the latter. ... the overall time will give you the former + loop overhead + context ...
      (comp.programming.threads)
    • Re: LibTomMath [0.26]
      ... |>Yeah I use clockfor the timing. ... |>portable rdtsc() that was contributed to Libtomcrypt to get more ... | Not all processors can use the rdtsc() function. ... Clock() should be more ...
      (sci.crypt)
    • Re: high resolution timer
      ... you need those timers. ... Maybe if you explain what you are trying to do someone has a better/different solution for you that does work with the normal kernel. ... in timing, especially in a "sloppy scheduling environment" like that provided by the standard Linux kernels. ...
      (Fedora)