Jump to content

IT razno.


Mikorist

Preporučeni Komentari

summa summarum

Spectre PoC daje čarobni rezultat iz sopstvenog adresnog prostora.

Aplikacije se mogu kompajlirati sa opcijom LFENCE opcode ili  Retpoline, što sprečava krađu podataka. Tako će aplikacije (kao što su vaš pretraživač, Skype, Steam itd.) Biti zaštićene (eventualno).

Ako želite da testirate operativni sistem koji koristi Retpoline, probajte Clear Linux. Napravljen od Intela

https://clearlinux.org/
https://clearlinux.org/documentation/clear-linux/get-started/virtual-machine-install/virtualbox
https://clearlinux.org/documentation/clear-linux/get-started/virtual-machine-install/vmware-player
https://clearlinux.org/blogs/clarity-desktop (after it's downloaded launch the gui by typing "startx")

Instalacija  gcc input "sudo wsupd bundle-add c-basic"

http://www.phoronix.com/vr.php?view=25821

Pod njim uopšte ne radi Spectre PoC. I prva i druga varijanta.

Ostaje nejasno kako će Cloud servisi da se zaštite i specifični sistemi i okruženja (emulatori i virtuelne mašine) .

Ovde je pun tekst koji je izdat 3. januara

https://dl.packetstormsecurity.net/papers/attack/spectre-attacks-exploiting-sepculative-execution.pdf


Na stranici 15 i 16 je originalni source code koji kopiraju i prepravljaju na Github. A Spectre Example Implementation 

Ono što su oni ovde objavili je bezalen primer Spectre PoC . Koji je bilo i moguće objaviti javno bez većih posledica .

Jedina posledica jeste  širenje bespotrebne panike. I opomena proizvođačima CPU.  

Ali u istom pdf-u se navode i drugi primeri koji nisu objavljeni van laboratorije.
 

Do sad koliko vidim (na svu sreću) niko nije objavio radni primer Spectre napada van memorije. 

Odnosno direktno na aplikaciju - što bi bilo pogubno kroz konzolu.

Takav PoC pretpostavlja prihvaćanje složenijih komandnih argumenata (sem da ispisuje magičnu reč iz sopstvene memorije) - ali niko nije uspeo da napravi tako nešto ili pokazao jedan radni primer, za koji znam ...

A nadam se i da neće. Ipak naučnici imaju kodekse ponašanja na zavidnom nivou. 

Link to comment
Podeli na ovim sajtovima

  • 2 nedelje kasnije...

Ovo je luda kuća.

Evo šta kaže majstor koji radi direktno na ovome - David Woodhouse

Quote

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

Link to comment
Podeli na ovim sajtovima

  • 2 nedelje kasnije...
  • 4 nedelje kasnije...

Na mobilnom nadjem neki sajt za online slušanje klasične muzike.

Želim da slušam na PCu pa taj linak pošaljem sebi kao mail.

Mail stigne ali linka nema ?!?!?!:o:o

Nekoliko puta ponovim i isto. Kad pogledam mail na mobilnom prikaže se linak. Kad stigne na PC nema ništa.:angry:

Ko filtrira poruke? Gmail ili neki adbloker ili koj djavo?

Link to comment
Podeli na ovim sajtovima

Link to comment
Podeli na ovim sajtovima

  • 2 months later...

Mene to asocira na "loudness war" s pocetka 80-ih, a sada je u toku "hardware war" sa operativnim sistemima koji imaju prekomplikovane opcije i zahteve po pitanju hardvera, a realno su davez za rad. Razumem ja njihovu zelju da vire u svaki kompjuter, ali onda se os deli besplatno. Treba nam operativni sistem, a ne operativacijin sistem :) 

Cak su se i ljutnuli u MS-u, kada sam ih na nekom seminaru pitao kada misle da naprave profesionalini OS...da ne iskacu nikakvi "pomocnici", da sistem ima ozbiljniju proveru modula a da ne trazi po netu update, da zakrpe i pecevi nisu veci od osnovnog os-a, da me ne dave sa pitanjima "da li si siguran"..valjda u to sto radim? :) 

Link to comment
Podeli na ovim sajtovima

  • 4 months later...

Čitam sad šta su ovi retardi u evropskom parlamentu usvojili pre par dana.
Veliki igrači poput Googla, Facebooka i Twittera će, dakle, morati da naprave ''pametne filtere'' koji će svaki copyrightovani materijal morati instant da prepoznaju i obrišu.
Kako ovo NIJE tehnički izvodljivo - kapiram da će Google, FB i Twitter BLOKIRATI pristup svojim servisima državljanima EU - u fazonu ''kad ste tolki retardi sada svirajte u prste bez 90% interneta''.

Evo šta su usvojili - :buehehe::buehehe:

https://www.eff.org/deeplinks/2018/09/today-europe-lost-internet-now-we-fight-back

Link to comment
Podeli na ovim sajtovima

Kreiraj nalog ili se prijavi da daš komentar

Potrebno je da budeš član DiyAudio.rs-a da bi ostavio komentar

Kreiraj nalog

Prijavite se za novi nalog na DiyAudio.rs zajednici. Jednostavno je!

Registruj novi nalog

Prijavi se

Već imaš nalog? Prijavi se ovde

Prijavi se odmah
  • Članovi koji sada čitaju   0 članova

    • Nema registrovanih članova koji gledaju ovu stranicu
×
×
  • Kreiraj novo...