Jump to content











Photo
- - - - -

CPU Microcode Update Driver

spectre meltdown

  • Please log in to reply
58 replies to this topic

#1 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 10 January 2018 - 03:54 PM

This info is applicable to Windows OS's running on Intel or AMD CPUs.


This Fling is a Windows driver that can be used to update the microcode on a computer system’s central processor(s) (“CPU”). This type of update is most commonly performed by a system’s firmware (“BIOS”). However, if a newer BIOS cannot be obtained from a system vendor then this driver can be a potential substitute.


VMware CPU Microcode Update Driver: https://labs.vmware....e-update-driver

Linux Processor Microcode Data File Version: 20180108 (Latest) Date: 1/8/2018: https://downloadcent...e-Data-File?v=t

EDIT: Version 20180108 has been removed from download page, and replaced with Version: 20171117 (Latest) Date: 11/17/2017.

 

I am on a i3 3225 Win7x64 PC, followed instruction on page https://labs.vmware....er#instructions and was able to confirm on "Event Viewer" "Successfully updated microcode on one or more CPUs".

Unfortunatelly after running SpecuCheck I got this:

Spoiler


NOTE: Wasn't able to run PowerShell script on my win7x64 so that's why I ran SpecuCheck. Of course KB4056897 was installed on my system before doing all this.

VMware program did work (as I confirmed), but in file "microcode-20180108.tgz" Intel Microcode Data File for my i3 3225 was not patched for this vulnerabilities. So this means Intel is launching this file "microcode-20180108.tgz" to public and not all Microcode Data have been updated to fix this vulnerabilities and no mention to this on download page.

INTEL HAS LOST ALL CREDIBILITY FOR ME.

Somebody with a newer Processor should check this in order to verify if Intel has really fixed this on recent Processors.


alacran


  • Brito likes this

#2 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 10 January 2018 - 06:10 PM

As we can see in following pictures VMware CPU Microcode Update Driver really works updating the Microcode on my system.

 

Before applying VMware CPU Microcode Update Driver:

 

5a564964b0ca6_Beforeupdatemicrocode.png.

 

After applying VMware CPU Microcode Update Driver:

 

5a5649752519f_Afterupdatemicrocode.png.8

 

But Intel has not updated it to fix this vulnerabilities on recent version for my i3 3225, as SpecuCheck reported:

 

Specucheck.png.d05b62a8418c8152ef486fb33

 

 

alacran


  • Brito likes this

#3 Brito

Brito

    Platinum Member

  • .script developer
  • 10616 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 10 January 2018 - 07:41 PM

Good information. Has any of you noticed impact on the performance after the upgrade?



#4 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 10 January 2018 - 08:17 PM

From an info I got on MDL only the CPU's on following list got a Microcode Update on Linux Processor Microcode Data File Version: 20180108 (Latest) Date: 1/8/2018 (absolutely necesary to make Windows patch to work).

 

Spoiler

 

Surce: https://forums.mydig...-5#post-1402924

 

So it seams if your CPU is not in that list you are out ok luck and they decided not to update your CPU Microcode



#5 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 10 January 2018 - 11:02 PM

Good information. Has any of you noticed impact on the performance after the upgrade?

 

An interesting reading (from MS) about the patch and resulting performances here.

Now "newer" config for the writer means "2016-era PCs with Skylake, Kabylake or newer CPU".  

"older" means "2015-era PCs with Haswell or older CPU".

The older your CPU, the bigger the hit.

 

I myself work in a big company (10000+ users) and most desktops are still older than Haswell CPU which I believe is representative of the standard user population (unless you are a gamer or have specific needs).  

My desktop (which I use for developping and which is running perfect for my needs) is a core 2 duo from 2009  :(

First thing I did last sunday was to prevent this patch from even getting near my computer as I dont think my good old machine can stand this patch.

 

I also hear that the hit is more visible on the IO side (I have seen some credible stats where you could expect a 25 to 30% hit).

 

Gamers are mostly not affected (as most of the work these days in on the GPU side).

 

Now indeed this is disappointing from Intel.

Will I stop buying Intel processors? Nope, still love them (my wallet does not).

When I will see production servers running AMD processors for years 24/365 without a glitch, then may be, big may be, I will consider AMD for my desktops :)



#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 11 January 2018 - 08:53 AM

An interesting reading (from MS) about the patch and resulting performances here.
Now "newer" config for the writer means "2016-era PCs with Skylake, Kabylake or newer CPU".  [/size]
"older" means "[/size]2015-era PCs with Haswell or older CPU".[/size]
The older your CPU, the bigger the hit.

The writer is Terry Myerson.

This automatically means that whatever is written in the article is either inaccurate or misleading, or both. :w00t: :ph34r:

 

The "poor" guy is the one that puts his name (I presume being well paid for this) under any kind of crap the MS PR and marketing department decide to divulge.

 

My desktop (which I use for developping and which is running perfect for my needs) is a core 2 duo from 2009  :([/size]
First thing I did last sunday was to prevent this patch from even getting near my computer as I dont think my good old machine can stand this patch.[/size]

 
The Core-duo is supposedly not affected by the meltdown or spectre vulnerabilities.
 
There is a list (not understandable) on Intel's site:
https://security-cen...anguageid=en-fr
 
And a much more extended (and actually understandable) list on Techarp.
 
If this latter is to be considered reliable :unsure: the Core-duo is not on the list.
https://www.techarp....ltdown-spectre/
 
:duff:
Wonko



#7 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 11 January 2018 - 09:47 AM

The writer is Terry Myerson.

This automatically means that whatever is written in the article is either inaccurate or misleading, or both. :w00t: :ph34r:

 

The "poor" guy is the one that puts his name (I presume being well paid for this) under any kind of crap the MS PR and marketing department decide to divulge.

 

 
The Core-duo is supposedly not affected by the meltdown or spectre vulnerabilities.
 
There is a list (not understandable) on Intel's site:
https://security-cen...anguageid=en-fr
 
And a much more extended (and actually understandable) list on Techarp.
 
If this latter is to be considered reliable :unsure: the Core-duo is not on the list.
https://www.techarp....ltdown-spectre/
 
:duff:
Wonko

 

I did not know about Terry Myerson : noted down.

About core duo, good news :)

A question remain : is it sensible or not to disable this patch on affected intel machine to eventually avoid a performance hit?



#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 11 January 2018 - 11:16 AM

A question remain : is it sensible or not to disable this patch on affected intel machine to eventually avoid a performance hit?

 

And I have not a (valid) answer.

 

To date - though this may change *anytime* - patching the systems against this vulnerability makes no sense whatever (as I see it), for two reasons:

1) though the vulnerabilities are potentially very dangerous, there is seemingly not (yet) anything "in the wild" capable of leveraging on these vulnerabilities, and however there are a number of conditions to have it actually work, and the real risk is - from the little I can understand - in setups where the same machine hosts several virtual machines, i.e. typically web servers and services, not so much a "common" desktop.

2) right now all the patches (to the OS or the CPU or both) are seemingly creating havoc, mainly - I believe - because they are half @§§ed, made in a frenzy with little or no verification of functionalities (and IMHO not even any real guarantee that they actually work).

 

On a server (which is something usually managed by professionals in the field, whatever "professional" means and whatever the "field" actually is) possibly hosting instances from different users and particularly different users from different organizations, it is "necessary" to patch as soon as possible (if for no other reasons to show to customers how much you are attentive and how much you care for the integrity of their data).

 

On a desktop, or on the mini-laptop[1] you use when on the move ?

Not yet, at least seen from here, it seems like there are a large number of headless chickens running around in panic, without a real reason.

 

The main possible vector of attack is - rather obviously - the browser, and it seems that pretty much all browsers are not affected, about Spectre:

https://www.ghacks.n...pectre-attacks/

 

http://xlab.tencent....ctre_check.html

 

Of the three browsers I personally use:

1) Opera (the real thing, Presto, not the crappy Chrome derived one) : Not vulnerable to Spectre

2) SRware Iron (actually a crappy derivative of Chrome, still seemingly "better"): Not vulnerable to Spectre

3) QtWeb: Not vulnerable to Spectre

 

Meltdown results may well be different, however.

 

 

:duff:

Wonko

 

[1] BTW, Atoms seem also to be not affected.


  • Brito likes this

#9 Mr B

Mr B

    Newbie

  • Members
  • 17 posts
  •  
    Sweden

Posted 11 January 2018 - 10:04 PM

Um... this speculative execution thing has been around since Pentium Pro. I'm not entirely convinced that the two lists above (which state pretty much exactly the same thing, only, Intel grouped them by family, Techarp listed each CPU individually) are in any way shape or form, complete.

Would a core 2 duo / quad be vulnerable here? I think so. As is a few of the Atom's, but not all. Those without speculative execution, to save more power, would probably not be affected of a bug that specifically exists in that part of the CPU design.

 

But then again. End / home users can pretty much just ignore this anyway. Install the patch, the performance isn't affected enough to be noticeable. You lose something like 30% iops on a really fast NVME SSD. You wont notice. On a slower drive, you lose less.

It SUCKS that the CPU had this bug in the first place, but what is even worse is that most motherboard manufacturers have no intention of patching anything older then 1-2 generations ago. So you will be stuck with whatever protection a software update provides. I say you, but i mean we all, me included. My Sandybridge (i5 gen2) is on a MSI motherboard, and MSI confirmed a support request with "no patch for you, sucker."

Well, they didn't put it quite like that. It was more "To old, buy our new stuff." Like hell i will...



#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 12 January 2018 - 09:53 AM

Um... this speculative execution thing has been around since Pentium Pro. I'm not entirely convinced that the two lists above (which state pretty much exactly the same thing, only, Intel grouped them by family, Techarp listed each CPU individually) are in any way shape or form, complete.

Yes, the point was that what you get when you look at your processor in (say) System Info is what you can find on the "explicit" list on Techarp and NOT on the "official" Intel one.

I was only pointing out the serious defect of communication towards end users by Intel.

And - if  your suspects are correct - then not only the information is badly laid out but it is also incorrect or inaccurate.

But then again. End / home users can pretty much just ignore this anyway. Install the patch, the performance isn't affected enough to be noticeable. You lose something like 30% iops on a really fast NVME SSD. You wont notice. On a slower drive, you lose less.

 

That is what seemingly is not going to happen (that end/home users won't notice it).

The issue is not with "working" mitigation/fixes, but rather with the "not working" or "not installable" ones.

Reports are accumulatong of conflicts with running software (antivirus and similar) when installing and also of issues (like no boot, that is actually noticed) when the patches are actually installled.

The Lenovo report about "retired" Intel microcode updates is IMHO much more worrying than the actual (again right at this moment, and susceptible to change anytime) risk:

 

https://pcsupport.le...curity/ps500151

 

 

 

CLIENT SYSTEMS

The following guidance is specific to Lenovo Personal Computing (PCSD) offerings.

Withdrawn CPU Microcode Updates: Intel provides to Lenovo the CPU microcode updates required to address Variant 2, which Lenovo then incorporates into BIOS/UEFI firmware. Intel recently notified Lenovo of quality issues in two of these microcode updates, and concerns about one more. These are marked in the product tables with “Earlier update X withdrawn by Intel” and a footnote reference to one of the following:

*1 – (Kaby Lake U/Y, U23e, H/S/X) Symptom: Intermittent system hang during system sleep (S3) cycling. If you have already applied the firmware update and experience hangs during sleep/wake, please flash back to the previous BIOS/UEFI level, or disable sleep (S3) mode on your system; and then apply the improved update when it becomes available. If you have not already applied the update, please wait until the improved firmware level is available.

*2 – (Broadwell E) Symptom: Intermittent blue screen during system restart. If you have already applied the update, Intel suggests continuing to use the firmware level until an improved one is available. If you have not applied the update, please wait until the improved firmware level is available.

*3 – (Broadwell E, H, U/Y; Haswell standard, Core Extreme, ULT) Symptom: Intel has received reports of unexpected page faults, which they are currently investigating. Out of an abundance of caution, Intel requested Lenovo to stop distributing this firmware.

the above, would be a lot of work (for once :whistling:) for the IT guys in an organization, but for the end users (private) or small offices (with no "resident" IT support, making use of external consultants) it has all the potentiality to become a nightmare. 

 

And as seen above even those OEM that *somehow* tried and are trying to provide patches may have been given (by Intel) unsafe or unstable code, with not-so-marginal side effects.

 

It is a complete mess. :(

 

:duff:

Wonko



#11 Mr B

Mr B

    Newbie

  • Members
  • 17 posts
  •  
    Sweden

Posted 12 January 2018 - 05:44 PM

I was only pointing out the serious defect of communication towards end users by Intel.

And - if  your suspects are correct - then not only the information is badly laid out but it is also incorrect or inaccurate.

 

Well. Everyone that is making CPU's, try to downplay this issue. Everyone has it, and everyone is affected. Not all their products are affected, but everything from ARM CPU's in mobile devices, and vehicles, to server CPU's is open to this.

 

That is what seemingly is not going to happen (that end/home users won't notice it).

The issue is not with "working" mitigation/fixes, but rather with the "not working" or "not installable" ones.

Reports are accumulatong of conflicts with running software (antivirus and similar) when installing and also of issues (like no boot, that is actually noticed) when the patches are actually installled.

The Lenovo report about "retired" Intel microcode updates is IMHO much more worrying than the actual (again right at this moment, and susceptible to change anytime) risk:

 

Yes, i admit. My "end users wont notice" was only aimed at the performance loss, and security issue. The botched slap on band-aids they are pushing right now, everyone notices that.

 

It is a complete mess.

 

Yes. Yes it is.



#12 Mikorist

Mikorist

    ▂ ▃ █ ▅ ▆

  • Advanced user
  • 771 posts
  •  
    United Nations

Posted 14 January 2018 - 09:14 PM

Hello. I am Live.
 
Spectre PoC on my MacOS High Sierra. Latest version from App Store with updates. 3.3 GHz Core i5
 
I tested myself because I did not believe it that is Spectre bug unifixable.
 
char * secret = "The Magic Words are Squeamish Ossifrage.";
 
Attached File  spectre.jpg   213.72KB   0 downloads
 
Version from here works 100%
https://github.com/crozone/SpectrePoC
 
 
Here's the original
https://dl.packetsto...e-execution.pdf
 
At end of pdf is
A Spectre Example Implementation (page 15, 16)
 

Spoiler

Spectre Information Disclosure Proof Of Concept
 
Posted Jan 3, 2018
Authored by Yuval Yarom, Michael Schwarz, Mike Hamburg, Moritz Lipp, Paul Kocher, Werner Haas, Thomas Prescher, Stefan Mangard, Daniel Gruss, Daniel Genkin
 
There is no simple help from this . . .
 
Here is a gallery in comments where Spectre 2 works (I saw AMD processors there too - on AMD you can disable eBPF JIT ) . With or without patches (all possible operating systems) :
 
https://gist.github....bbd7b2a9e3d4bb6
 
 
It looks like I discovered new protection.
Does not work any single Spectre exploit that I found on a memory zone that is inaccessible to anyone.
So if you want to hide something from the attackers just:
 

mprotect(addr,PROT_NONE)

 I edited original version with :
 
 

Spoiler

 On OSX i put MAP_ANON instead of MAP_ANONYMOUS to prevent compiler starts misbehaving .

For Windows, VirtualProtect must be allocated after allocation with VirtualAlloc or plain malloc,

but you need to be aligned to 4096 so that the entire segment could be read.

I do not know now for Windows whether it is working on unaligned.
 
If you want to read put this instead

Spoiler

Attached File  1.jpg   340.22KB   0 downloads
So, you can theoretically make root exploit with Spectre PoC if you know how to use mmap precisely inside them.  :ph34r:  
 
 
You can Compile it for Windows by using TDM-GCC. And test yourself.
 

Spoiler

 

Include -m32 to compile a 32-bit version. It might work for you when a 64-bit version doesn't.
 
Create an exclusion in your Antivirus.
 
On MacOS X

Spoiler

 

On Ubuntu

 

Spoiler

 

News isn't great on OSX... https://support.appl.../en-gb/HT201260 Looks like they're not doing any mitigation for Spectre at the OS level, just a forthcoming Safari patch to stop JavaScript-based exploitation. And orginal macOS is still using the old microcode version from the firmware
 
So to be clear, Windows, Linux (e.g. openSUSE) and Mac OS are fully patched from Meltdown CVE-2017-5753. Some applications that handle sensitive information require updates though, otherwise the Spectre PoC might be able to read the data. Firefox, Chrome & more are already patched for this reason.
 
There is only one OS (currently) in world I know of that are fully patched from Spectre attack at the OS level. Applications are recompiled with the LFENCE opcode or make use of Retpoline, which prevents data theft.
 
Clear Linux (by Intel) that uses Retpoline
 
https://clearlinux.o...on/clear-linux/
 
I've mainly tested it due to it using Retpoline instead of a microcode update.
But ClearLinux is not meant to be used as a "normal desktop OS".
 
I need to go to Wine Emulator support. They must patch him too. Because Spectre works through Wine   :(
Attached File  34825584-64d493b6-f6d3-11e7-812f-5f69cfb267f2.jpg   262.07KB   0 downloads
 
 
Attached File  geOa1Ut.png   506.97KB   0 downloads



#13 Mikorist

Mikorist

    ▂ ▃ █ ▅ ▆

  • Advanced user
  • 771 posts
  •  
    United Nations

Posted 14 January 2018 - 10:32 PM

miko.jpg

 

Windows 10....

 

On the other forum, this picture was deleted. I wonder why :(

 

 

The moderator's explanation is to create panic and  people are getting confused... :D


  • Brito likes this

#14 Mikorist

Mikorist

    ▂ ▃ █ ▅ ▆

  • Advanced user
  • 771 posts
  •  
    United Nations

Posted 14 January 2018 - 10:39 PM

Screenshot_2018_01_11_06_55_52.png

 

Ubuntu



#15 Mikorist

Mikorist

    ▂ ▃ █ ▅ ▆

  • Advanced user
  • 771 posts
  •  
    United Nations

Posted 14 January 2018 - 10:41 PM

The Linux Distro that used Edward Snowden. TAILS.

 

34850768-876a6bea-f727-11e7-9544-7515f32

 

I am worried NOW about Edward Snowden Security.


  • Brito likes this

#16 Brito

Brito

    Platinum Member

  • .script developer
  • 10616 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 14 January 2018 - 10:46 PM

What about an updated Android? Same results there? :huh:



#17 Mikorist

Mikorist

    ▂ ▃ █ ▅ ▆

  • Advanced user
  • 771 posts
  •  
    United Nations

Posted 14 January 2018 - 10:51 PM

Yep. I tested. 
 
Here is Android/ARM64 Spectre PoC
 
https://github.com/V...r/CVE-2017-5753

We can just throw those our phones and laptops into the trash.

I do not trust anyone anymore that we are safe and can relax. 

 

I can relax when I die.


  • Brito likes this

#18 Mikorist

Mikorist

    ▂ ▃ █ ▅ ▆

  • Advanced user
  • 771 posts
  •  
    United Nations

Posted 14 January 2018 - 10:55 PM

Only Raspberry Pi is safe. I tested my.
 
Here's why
 


#19 Brito

Brito

    Platinum Member

  • .script developer
  • 10616 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 14 January 2018 - 11:21 PM

Related: https://ipfstube.eri...USUbsgmx2aCQTS 

 

:lol:


  • Mikorist likes this

#20 Mikorist

Mikorist

    ▂ ▃ █ ▅ ▆

  • Advanced user
  • 771 posts
  •  
    United Nations

Posted 14 January 2018 - 11:32 PM

Spectre Attacks (in research paper from above) can be Inter-Application (not necessarily targeting the kernel and memory directly). Firmware Updates can address some forms of attack. Software Patching (especially Signature Identification) can address immediate concerns. Is this going to stop Spectre Attacks, completely? Absolutely not (as the research paper alludes to). Spectre PoC can be mutated into another form like i show here. And always reinventing the method to aim flow in the CPU architecture design.
 

So the only newly designed processor can be safe. 

 

 And designed on the Raspberry Pi CPU principles.
 

And this truth does not like anyone.

 

I throw these truths and pictures in many different places. At Github. Under different names. In more than one forum.

 
I consulted with different people. With professionals and hackers.
 
Here's what Linus says 
 
https://lkml.org/lkml/2018/1/3/797
 

 

Why is this all done without any configuration options?

A *competent* CPU engineer would fix this by making sure speculation
doesn't happen across protection domains. Maybe even a L1 I$ that is
keyed by CPL.

I think somebody inside of Intel needs to really take a long hard look
at their CPU's, and actually admit that they have issues instead of
writing PR blurbs that say that everything works as designed.

.. and that really means that all these mitigation patches should be
written with "not all CPU's are crap" in mind.

Or is Intel basically saying "we are committed to selling you shit
forever and ever, and never fixing anything"?

Because if that's the case, maybe we should start looking towards the
ARM64 people more.

Please talk to management. Because I really see exactly two possibibilities:

- Intel never intends to fix anything

OR

- these workarounds should have a way to disable them.

Which of the two is it?

Linus



#21 Mikorist

Mikorist

    ▂ ▃ █ ▅ ▆

  • Advanced user
  • 771 posts
  •  
    United Nations

Posted 15 January 2018 - 12:11 AM

Should Spectre, Meltdown Be the Death Knell for the x86 Standard?
 

Essentially, the only cure — at least today — is for the organism to die and for another one to take its place. The bloodline has to die out entirely.

The organism with the genetic disease, in this case, is Intel’s x86 chip architecture, which is the predominant systems architecture in personal computers, datacenter servers, and embedded systems.

 
https://www.extremet...ll-x86-standard



#22 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 15 January 2018 - 08:33 AM

 

The moderator's explanation is to create panic and  people are getting confused... :D

 

Maybe because it is actually creating panic and getting people confused. :dubbio:

 

:duff:

Wonko


  • Mikorist likes this

#23 Mr B

Mr B

    Newbie

  • Members
  • 17 posts
  •  
    Sweden

Posted 15 January 2018 - 01:24 PM

Only Raspberry Pi is safe. I tested my.

Nah. ANY CPU without speculative execution should be safe when it comes to spectre / meltdown as far as i can tell. This includes a bunch of ARM devices, as in your linked article, pretty much anything on a A5 or A7, is safe. As is any Intel Atom pretty much up to 2013 when they released Silvermont. I'm not familiar enough with AMD's low power devices to say for sure, but i THINK everything they have is affected all the way back to AMD K5. And any CPU branded VIA since Nano. Should be a fair bit of business systems using Via C7. They would be happy to know it's not affected.
  • Mikorist likes this

#24 Mikorist

Mikorist

    ▂ ▃ █ ▅ ▆

  • Advanced user
  • 771 posts
  •  
    United Nations

Posted 15 January 2018 - 02:07 PM

 If you do not count CPUs without speculative execution the only safe device  is probably the Abacus.  :buehehe:



#25 Mikorist

Mikorist

    ▂ ▃ █ ▅ ▆

  • Advanced user
  • 771 posts
  •  
    United Nations

Posted 15 January 2018 - 02:16 PM

Bad news: A Spectre-like flaw will probably happen again
 
 https://www.cnet.com...ars-pcs-phones/






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users