/tech/ - Technology★

>>846180 (OP)

An actual conspiracy and /pol/ is nowhere to be seen. Funny how that works. Cowards. But then again they can count past 6 million anyway.

Just one more bug for POWER to get there.

>>846180 (OP)

HOW SURPRISING!

https://github.com/xoreaxeaxeax/sandsifter/raw/master/references/domas_breaking_the_x86_isa_wp.pdf

>>846194

>An actual conspiracy

implying this isn't has vague has any conspiracy

>/pol/ is nowhere to be seen

Talking about paranoia, you know that keeping citing the bogeyman makes them appear don't you ?

>>846196

THIS

Notice that smell? Smells like... class action lawsuit. I can't wait to get my check over $12.46 from Intel.

>>846196

>>846203

And you cringey LARPers are the worst cancer too. OPs body clearly states the bug doesn't even effect AMD processors. I hate people like you who think they're smarter than industry leaders. People who think architecture A is good because its 'different' and have such lack of regards for the industry to think re-inventing the wheel is necessary. There's very good reasons POWER failed and little good reasons to start using it again. Stick to what you're good at, preaching about Linux on anonymous imageboards, that's the only industry exposure you're going to get

>>846211

T.cianigger A.I

>>846182

What's interesting is why (you) are bringing it to our attention just now when it is almost already fixed. I wonder why they thought it was so important to fix in private? It's already laughably easy to make a worm that targets x86 CPU's design quirks. What could this possibly be that they are so worried about with the already numerous ways of pwning a x86 cpu?

>>846220

>It's already laughably easy to make a worm that targets x86 CPU's design quirks. What could this possibly be that they are so worried about with the already numerous ways of pwning a x86 cpu?

Maybe because high instruction density is not considered a security issue unless you're a retarded Pajeet, in which case just stick to making mobile apps

>T.cianigger A.I

<t. Someone who likes to pretend they know how computers work on an anonymous imageboard

>>846224

Your knowledge of the industry is truly flattering. I bet you know all about the POWER architecture and POWER assembly and everything. Your meme balls are truly telling

>>846226

>You would want to be thinking something along the lines of system management mode you giant faggot.

X86 is not the only architecture with privileged modes. You and your infinite wisodm on computing architectures probably already knew that I'm sure

>>846225

Now power isn't the most optimal for energy effeiciency nor security I will grant you that. But it doesn't have the modern CISC to RISC converter and (((ME)))/(((PSP))) cancer that x86_64 has. Even though it has a similar cancer to the on die schedulers that modern x86_64 cpu's have to control heat, it is also RISC based by comparison thereby reducing heat. The power CPU's available for purchase also have a open firmware. This leads to it being easier to scale in commercial applications ontop of making bug fixing much easier at the assembly level. granted if you find a bug from running large tasks in parellel at high clock speeds there is most likely something wrong with the way it was fabricated, but I digress. No I don't have every single assembler instruction memorized for the power architecture. I am very informed on what CPU's are fucking botnets though in cy+3. So fuck off cianigger

>>846230

>But it doesn't have the modern CISC to RISC

The total die space and resources required for this is so incredibly negligible and is paramount for compatibility. You know, the thing you autists throw a massive fit over whenever its threatened to be compromised

X86s issues have been solved through architectural scaling. Its why we can have chips like Intel Atoms that can run fanless on batteries now. And POWER isn't going to prove a better solution to this

>>846216

>OPs body clearly states the bug doesn't even effect AMD processors

I didn't even directly cite anything AMD related (besides the pdf which is a general audit on x86 hardware).

>I hate people like you who think they're smarter than industry leaders

Because industry leaders can't be retarded ?

Maybe you should go out sometimes and take fresh air.

>There's very good reasons POWER failed and little good reasons to start using it again

You mean that intel having 90% of the market share and the blatant anti competitiveness that they did didn't influence other architectures from happening ?

>preaching about Linux on anonymous imageboards

.t buthurt bsdcuck

>>846237

>X86s issues have been solved

>have been solved

>solved

>Intel Atoms

>good

>>846237

Holy shit that non-sequiter. X86 CPU's are cancer because of the scaling you giant faggot. This created problems when it comes to heat reduction because the proccesor is always waiting for the schedulers to keep up with the instructions being ordered correctly. But at scale and load this creates much more heat then using a RISC architecture straight up and having the devs/compiler account for the order of operations at compile time for parellelization. By distributing the load over the proccessor you further reduce heat on RISC because of how cheap it is to transfer instructions across the die. But on x86 it's very expensive to do so thereby creating scheduler bottlenecks and heat problems due to shit order of operation with parellelization. Why do you think they can't go any further then 7nm right now in size on die? Because the heat from transfering instructions across the die is the cancer that is killing x86 from improving performance.

>>846241

Heat hasn't been an issue on x86 for years now. The inability to scale down to 7nm nodes has jack shit to do with heat. POWER and ARM experience identical thermal issues when they scale up to x86s level on desktops

>>846237

>X86s issues have been solved through architectural scaling.

let's see them scale away this

35% PERFORMANCE HIT

bitch

>>846245

I honestly do not understand

>>846240

>You mean that intel having 90% of the market share and the blatant anti competitiveness that they did didn't influence other architectures from happening ?

Failing to deliver generational performance gains is the reason Intel and AMD dominate the supercomputer, PC, and high-end workstation markets. POWER died when Apple and eventually game consoles stopped using it and IBM can only blame their own incompetence

>>846250

>POWER died

So that's why google massively invests in it.

Kys intel shill.

>>846253

> I can do that with a ARM cpu

I dare you to emulate an i7 at native speed with an arm chip without a fan.

>>846250

>Failing to deliver generational performance gains is the reason Intel and AMD dominate the supercomputer

Sure why not it's surly not because it's cheaper to buy AMD or that intel brakes their price when buy in enormous bundles.

And anti competitive behavior doesn't have influence AT ALL.

>PC, and high-end workstation markets

>amd dominating

WEW

>POWER died when Apple

Apple changed just because it was cheaper.

Apple has only made the past decade decisions because of money saving.

> and eventually game consoles

>consoles

You just mean nintendo.

Anyway nintendo went to ARM because they targeted audience that also wanted to have a transportable console.

>>846257

I dare you to not make bloated software.

>>846258

Not just Nintendo.

Also NVIDIA SHIELD

>>846257

I didn't say that you giant faggot. I can run the same software but compiled for ARM without a fan. But which would require a i7 intel proccessor to get similar speeds if compiled for x86_64.

>>846253

>Why can't I run a chip significantly more powerful than the most powerful ARM chips without a fan guys?

I feel like you're being willfully ignorant

>gets triggered when I sage like it's a downvote

>>846260

> NVIDIA SHIELD

Again it's portable, you're ranting about an architecture which isn't meant to be a small portable system or/an to do intense graphical work.

You aren't making any sense intel shill please stop and go back to /g/ or reddit.

>>846258

No, I mean Sony and Microsoft both use AMD chips and Nintendo uses ARM. POWER is fucking dead

>>846265

>No, I mean Sony and Microsoft both use AMD

Because microsoft isn't compatible with intel maybe ?

>Nintendo uses ARM

Since the switch but otherwise they use power (and also amd) since the gamecube and before that it was NEC.

>POWER is fucking dead

And still actively developed.

Please just stop you aren't convincing anyone here besides ignorants, the market share of cpu architectures in general is very wide and diverse you can't just say that X is dead because X enormous company doesn't use it.

>>846260

>Nvidia shield

>Can barely run Half-Life 2 and Portal at minimal settings and its considered a bullet point it runs at all

>Runs Dolphin fine only at native Gamecube res

Hey faggot, my Intel Atom Bay Trails tablet does the same shit on the shitty HD series GPU. it's not impressive.

You know what thr shield can't do? This;

https://www.youtube.com/watch?v=dCPP-Gg_aMw

Repeat after me;

ARM was never good and never will be

And before you call me a kike, you're the one here shilling for an architecture madr by a tranny

>>846263

Were you born stupid? At 34x less energy used and no fan a qualcom snapdragon 800 SOC has about 1/8th of the performance of a fourth gen i7 https://archive.fo/RpDmv . This is before optimization on the ARM side which is still shit and while account for ARM being a shit risc implementation.

>>846266

>Since the switch but otherwise they use power (and also amd) since the gamecube and before that it was NEC.

You mean since The console that's fucking dead AKA the WiiU

>>846267

Your atom also uses a fuck ton more of electricty and doesn't have to convert from the CISC x86 to the RISC ARM instructions for running half life and such. If the dolphin emulator was well optimized software for ARM then it would fucking work better. Do realise though what a feet that is considering the electricty/energy usage of the nvidia tegra for that application though.

ARM is shit though

>>846268

You don't know shit abound how thermal scaling works. This is infuriating. Its shocking how little anyone here knows abound fucking technology and still hide their conjecture behind walls of rhetoric

What do you think will happen when they try scaling the same Snapdragon 800 to an i7s level? It won't still be the same 34 times less energy used. Remember all those ARMv8 servers companies promised in the early 2010s? What happened to them? Why were they never delivered in the same scale people hoped? Hey faggot, maybe reality got in the way

>>846270

>If the dolphin emulator was well optimized software for ARM then it would fucking work better

You mean the emulator with the same portable codebase? Or what do you still think Android apps are written in Java?

Can your rhetoric even back why having a CISC <-> RISC converter even impacts the architecture itself when real world evidence is in complete contrary to your conjecture?

Do you understand why I hate people like you?

i'm beginning to loose faith that linus isn't a cianigger or being paid of by every corporate kike under the sun to do things one way or another.

>>846274

Gotta make money to spend money

>>846271

Well no shit, ARM still has the out of order schedulers on die cancer that x86 has. Ontop of fucking pajeets and chinks being the ones programming the microcode for it. And the shitty ARM (((kikezone))) implementation and shitty compiler support for FOSS compilers because of ARM keeping the assembly somewhat secret.

>What do you think will happen when they try scaling the same Snapdragon 800 to an i7s level?

Well let's do some math. An ARM SOC that uses 34x less energy scaled times 34 to equal the power usage of an i7. Ontop of adding liquid nitrogen to a proper heatsink. It would scale quite nicely for GFLOPS proccessed per cycle assuming it didn't melt the cheap chink case of the phone. I can't find a example of someone doing such a thing though because the software/firmware for the ARM proccessors is locked down which means little overclocking can be achieved.

>>846274

Linus has confirmed some time ago that CIA/NSA came to him to install backdoor

https://www.youtube.com/watch?v=7gRsgkdfYJ8

Even his father who is a chairman at the European union talked about it at the EU.

https://www.youtube.com/watch?v=wwRYyWn7BEo

>>846276

>Well let's do some math. An ARM SOC that uses 34x less energy scaled times 34 to equal the power usage of an i7

Power and heat output absolutely do not scale linearly like that

>>846269

>You mean since The console that's fucking dead AKA the WiiU

You can't even read correctly.

The wiiu was never arm.

The Power architecture is used by nintendo since the gamecube.

http://nintendotoday.com/wii-u-cpu/

>>846278

I know, ARM is more effiecient at energy usage per cpu cycle as we have already established. Hence why that 1/8th gap would be made up with plenty of cycles to spare.

>>846280

See

>>846273

Its okay to admit you have no idea what you're talking about lad

>>846281

Consoles do not use PowerPC anymore. Following semantics is hard I know

>>846282

Not how it works, especially not when it comes to thermals. And clock speed =/= IPC

>>846283

>Following semantics is hard I know

>wanting to be correct when obviously in the precedent post you said shit.

m8 you know that admitting being wrong with yourself is part of the process called growing up ?

You don't even have to post that you're wrong on the board just just can say "fuck I'm retarded" on your side and life goes on and nobody gives a dam.

>>846284

No I think you have a difficult time understanding what I was saying

It's okay to admit you're wrong though

No consoles use POWER anymore. I am glad we got this established

>>846286

IPC

Instructions Per Cycle

A concept well beyond you're understanding and it's self-evident

>>846286

Also in case you hadn't realized, the WiiU is depreciated by the Switch. That's the points I was trying to make. For some reason its difficult for people on those board to understand

>>846287

Wait I jumped the gun on that one. Fuck me

>>846285

假的 臺灣本島

>>846285

>I am glad we got this established

You really learned how to keep appearances on you side, continue you're going to go far like that.

Btw here's your (You).

Also, the besr ARM chips typically aren't more than 8 Single Precision Instructions Per Cycle. ARM chips aren't as heavily pipelined as POWER or X86, because otherwise you do run into the same scaling issues and ARM really cannot afford to crawl out of its low-power computing segment

Anyhow I'm tired and probably won't be replying to this thread anymore so whatever

>>846194

There it is, the faggot who has to bring up /pol/ in every thread for no rational reason.

>>846298

You're not wrong. But next time try focusing on that instead of pretending that performance or thermals are the issues that need to be solved by reinventing the wheel

This is not going to be some trivial vulnerability. There is no reason something with such a huge performance hit would be rushed through into the mainstream/upstream.

>>846302

Sage doesn't send a thread down a level you know?

As you can observe in this thread instead of sticking ot the initial post of OP the intel shills made it slide into an endless BS discussion read and learn from this anons.

>>846180 (OP)

http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table

Are there any predictions on how old this bug is? From the comments in the linux kernel it seems like it could potentially be very old.

This thread:

>OP - genuine security post

>Fuck Intel, we need more architectures like POWER

>No goy, Intel so based, x86 is best instruction set

>No it isn't

>Yes it is

>No it isn't

>Yes it is

>No it isn't

>Yes it is

And so on.

>>846310

>Are there any predictions on how old this bug is?

Since it seems to be hardware issue design problem it seems like since the beginning the software upgrades made recently is only to mitigate the potential damage.

>>846311

this and see >>846307

What do you expect when some intel shill comes to defend their overlords and freetards who wants free/libre hardware.

>>846315

>it seems two times

I need to get some sleep.

>>846315

Your posts are retarded shitposts too.

>>846311

I'm sorry anon, but being anti-POWER fanboy and giving Intel due credit is the the same as being an Intel shill. You people are fucking stupid.

>>846311

this is an accurate summary

>>846224

>>846226

>>846234

>>846253

>>846280

The reason why /tech/ has a pph of 20.

autism

>>846323

This isn't the self-diagnosis thread.

Wow this went to shit fast, thanks to /pol/tards and ARMshit fanboys.

This seems to only be relevant to virtualization though, in which case I hope you can turn this "fix" off at run time. Another nail in the wintel coffin :-)

>>846410

>/pol/tards

What? Where?

>>846410

oh, but hey thanks to your crew giving valuable meta and post quality and anonymous identity discussion.

Informing and exclaiming how "/b/ is shit is" way more important than all of technology itself.

>>846180 (OP)

(((Embargo))) on information. Comments (((redacted))) on commits. I can see the glow coming off Linux from here. Not surprising when you see all the people with @intel.com in the source tree.

This is why cloud computing will always be a security risk. It is better to run your own hardware.

>>846322

fuck your right /tech/ needs to get rid of all of this wrongthink and white men.

>>846517

This is going to be brutal for Intel. They aren't talking about which models it affects, and they're trying to fix this all in secret. It must be a huge problem affecting a wide range of Intel CPUs.

>>846589

All they did was remove comments from the code.

>>846481

Too late. His already ruined by cuckchan.

>>846589

Embargoed security patches have been a thing for several decades in Linux, anime avatar LARPer. Would you rather have full disclosure of a bug that could be used to take over most of the world's servers in a few minutes via spreading through cloud providers?

>>846566

Preety sure it affects all x86 CPU's with a MMU. Literally all of them. They did name the function

>X86_BUG_CPU_INSECURE

In OP.

>>846610

Not him, but I would much rather have that than any kind of secrecy in supposedly open environments. The only thing they are "protecting" here is Intel's pocket book.

>>846610

>Would you rather have full disclosure of a bug that could be used to take over most of the world's servers in a few minutes via spreading through cloud providers?

Considering this is only one of many that could do so, yes full disclosure would be nice. With jews you lose faggots. Stop using x86 and ARM cancer.

>>846610

Embargo for something like 2-4 weeks would be a good compromise.

Holding on it for MONTHS so the intel exec's can dump their stock and the pajeet microsoft coder's could sell it to blackhats is unacceptable. So many OS vendors and dev's know about it there is no way it hasn't leaked out to the dark side by now. Servers are being raped as we speak.

Linux dev's going along with with this just proves they put their corporate master's interest's above their users.

>>846611

how can i find out if i have MMU? my pic above

>>846322

>no id's

>The reason why /tech/ has a pph of 20.

>>846630

no for real anon, or are they all screwed cause of the evil inside?

>>846628

Every Intel processor since the 286 (I think) has had an MMU.

>>846635

ok, thanks

>>846517

From the Register link

>It appears, from what AMD software engineer Tom Lendacky was suggesting above, that Intel's CPUs speculatively execute code potentially without performing security checks.

<but trust us, our ME is patched and totally secure now

gg Intel

>I just returned my threadripper before Christmas because I figured my 4970k was "good enough".

Damn, unlucky start to the new year I guess.

I got it for $200 off on black Friday. I bet it's price will sky rocket now.

>>846642

Or is it 4790k? Whatever that Haswell was.

>>846640

Thiink you meant to paste this link, fam

https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx

>>846644

never mind, I found your quote at the bottom of that other

so whats better to use, shity android that only plays half of youtube vids or linux with evil inside?

>>846645

I don't know how he managed to write that email without adding "lol"s everywhere

>>846610

>Would you rather have full disclosure of a bug that could be used to take over most of the world's servers in a few minutes via spreading through cloud providers?

Abso-fucking-lutely. Maybe that could end (((Intel)))'s reign of terror.

>>846650

good point, im sticking with linux with evil inside...

Feels insanely good to be running GNU+Linux on my Ryzen 5 1600 right now.

Does no one care how the BSDs are affected by this?

>>846655

Maybe them being last to know is payback for breaking disclosure last time.

>>846655

Because it affects everyone, it's a CPU level bug, Linux, BSD, Minix, Windows, probably Haiku as well.

No one is reading those mailing lists.

>>846657

Wasn't that just OpenBSD and only really once? I can think of three potential times:

1: a patch against KRACK iirc, they just silently patched it, the author gave consent then removed it.

2: Accidential mailing list leak with OpenSSL

3: Only legitimate one, can't remember what it was but they asked for some absurd cover time so they just told them to fuck off.

>>846659

Who told who to fuck off?

>>846660

My memory could be really wrong but OpenBSD told a vendor to fuck themselves when they asked for a really long non disclosure time.

Jewtel has been knowingly shipping insecure chips in order to boost performance to keep AMD from catching up.

https://yarn.co/yarn-clip/aaba1aa5-149e-4e30-b8c7-1d04109be202

>>846657

They wanted months of embargo for KRACK and OBSD told them to fuck off then patched it. After the typical embargo time. Theo maybe a dick but at least he doesn't throw his users under the bus.

You should get 30days after notification then let the info drop. With so many people involved there is no way it hasn't leaked on to the darkweb by now. Only end users are getting hurt by this now. Waiting months only serves to help asshole's like

>>846640

>>846182

It is also very interesting that the big cloud players get a heads up but the little guys are going to be completely blindsided.

Does this affect older models? What is the full list of processors affected?

Does it mean we're back to Sandy Bridge performance with only iGPU improvements?

Is Apple OS vulnerable too?

Does it affect only VMs and normal systems can avoid installing/running patches all the time?

>Passthrough LARPers BTFO

>>846665

No one knows the full details yet because of the (((embargo))).

But this could go all the way back way past sandy bridge. Past even the 1st 64bit Pentium.

Apple is effected because its an issue with the INTEL cpu not their OS. They will have to patch their OS just like everyone else to mitigate the CPU bug.

>>846660

Any Intel CPU produced in the last 10 years is vulnerable

We're back to Nehalem

All OSes are vulnerable

It affects everything, it's a CPU bug that is so bad it has to be fixed by working around it on a software level.

>>846665

From what I've gathered,

all Intels for the past decade

>>846634

Yes

No, but if you don't care about security you might be able to disable it

>>846667

It could but I'd be surprised if they used the same speculative branching techniques that far back.

>>846670

wait wasn't this bug introduced by intel fscking something up with dual page table management?

>>846671

Best details I've seen so far were in https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ OP linked later.

Talks about speculative caching, and how a researcher had been trying to exploit it.

>>846665

>>Is Apple OS vulnerable too?

>be mac user

>Apple hasn't "refreshed" some of their mac lines since 2014

>OS update comes out

>update breaks blank root password patch for the 3nd time

>Already outdated systems now 1/3 slower

kek

>>846671

Lurk twenty years and you would know this bug has been discloused for months now.

>>846672

meant branching, not caching

So is 8ch going to get 30% slower now?

Can Ron please switch us to a Threadripper 1950x with 128GB of RAM?

>>846659

>Because it affects everyone, it's a CPU level bug, Linux, BSD, Minix, Windows, probably Haiku as well.

>http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table:

"From a little digging through the FreeBSD source tree, it seems that so far other free operating systems are not implementing page table splitting"

This may turn out to just be a Windows,OSX, and Linux problem.

>>846677

FreeBSD is notorious for ignoring basic security precepts.

>>846678

OpenBSD isn't and they don't seem affected either.

>>846677

There are likely other solutions to this problem that will not result in a performance hit. Hell, it sounds like just some simple optimization on the memory management side of things could solve this issue

>>846676

You can easily configure a server to optimize kernel and userspace better so its highly doubtful. Remember, this only effects userspace programs that want to access kernel space memory. Just push more rudimentary shit to userspace and reserve kernel space for only the most secure bits. Windows could be effected far less for all we know since they can actually afford to move more shit to userspace on the count of their pseudo-microkernel design but we won't know for sure until Patch Tuesday

>>846679

Maybe they are trying to keep extra-tight on the non-disclosure aspect to regain rep on that front?

>>846679

If you understood how this bug worked you would realise that it affects anything with a MMU using the x86 arcitecture. Lurk twenty years now.

>>846681

https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2

Redis is looking at ~25% hit.

Doesn't 8ch use Redis?

>>846668

Looks to be executing unsigned "predictive" code. It's essentially like your browser executing scripts from webpages that come up on search suggestions. Except on a Kernel and CPU level. You can see how bad this is.

>>846683

AMD stated it's not affecting their chips since their engineers aren't massive retards.

>>846683

ARM64 is getting some of the same patches too

https://lwn.net/Articles/740393/

>>846683

If that was the case then a software fix wouldn't work to begin with you giga retard.

>>846686

Holy shit were you born stupid? Did you even research how the bug works? Lurk twenty years and everything is a fucking botnet you giant faggot. Do you really expect any of these liars to tell the truth, jewtel or (((amd)))? They won't.

>>846688

I am aware of this you giant faggot. That's because it won't fix it permenently. It's like a bandaid ontop of the giant steaming pile of shit that is the x86 architecture and it's clones.

>>846682

>Maybe they are trying to keep extra-tight on the non-disclosure aspect to regain rep on that front?

A) OpenBSD will not sign NDA's. If Linus signed a NDA over this then he completely sold you out to protect intel.

B) The rep they have now is they wont cover for shitty hardware vendors. They have always honored reasonable embargo's.Waiting MONTHS to sit on patches only fucks over the users in the end.

The coverup is always worse then the crime. I have a feeling this may turn in to a major shitshow of who-knew-what-and-when.

>>846690

Are you the OP of that retro home computer thread?

You're right about the software patch though, the nice thing about a rushed software patch is that there are going to be more bugs to exploit in it, probably for a long time to come.

>Inb4 this only impacts Linux because of its monolithic kernel design and Microsoft mitigates this by simply pushing some drivers to userspace

Windows wins again freetards

>>846645

if (Muhcpu= Intel)

cout << "Block." << endl;

>>846194

>some faggot brings up /pol/ in a derogative manner in every thread

>not astroturfing

Really activates my almonds

>>846694

I've been looking for OpenBSD's response (none that I can see), but came across KARL in the process. (KARL is a re-link of the Kernel on boot, with a random object ordering.) Do you think that this is why they haven't bothered?

>>846704

I love how you showcase the fact you have exactly 0 comprehension on the nature of the bug and dare post the brainlet meme

>>846703

Do the BSDs handle virtual memory differently than GNU/Linux?

>>846706

No because of the POSIX standard, it is a CPU bug in x86 proccessors and the MMU https://archive.fo/GSnCc and has nothing to do with the way virtual memory is handled in linux. They are just modifying it to make it ever so slightly more difficult to abuse.

>>846689

AMD doesn't run unsigned unsafe speculative code like Intel does. Did YOU read anything they were saying? Also, if it affected AMD the headlines wouldn't be all about Intel.

How hard is this going to fuck up virtual machines? I want to continue running Windows in a VM with hardware passthrough so I can play vidya but this seems like it might shit up the performance.

>>846706

No idea: I would assume not because you're basically just implementing the Intel interface to the MMU. It's pretty much a complex hardware interface.

I wonder about this comment in the patch, maybe it's a red herring, in the function map_ldt_struct:

+		/*
+		 * Map it RO so the easy to find address is not a primary
+		 * target via some kernel interface which misses a
+		 * permission check.
+		 */

Maybe some syscalls were leaking kernel space addresses, leaving them open to exploit?

>>846710

Wondering about that too, haven't seen any bare metal hypervisors mentioned.

>>846683

That depends. OpenBSD tends to also be ahead of the game when it comes to security holes. Maybe one of their random mitigation tricks happens to prevent it? At this point it's all speculation though.

>>846721

No, you can't prevent a hardware bug short of cutting off access to the hardware affected. This bug is in the hardware design of any x86 CPU with a MMU. OpenBSD handles their security valiantly compared to other OS's. But even they can't fix hardware issues like this one in software.

cool was considering switching over to AMD and this just sealed the decision

>>846722

What they're doing with Windows and Linux is a mitigation because obviously they can't patch out broken hardware. Same issue with 3DS, where they can't patch out their bootloader, they can only try their best to hinder you from getting sufficient access to change it. It just wouldn't surprise me if OpenBSD had pre-empted the issue in some way, whatever it is. Apparently we'll know on the 4th for sure.

>>846723

I'm most pissed off because of the dearth of AMD-based laptops, in particular, the lack of anything approaching Thinkpads or Toughbooks in general hardware quality, and that they've got their own blob issues and Intel ME type rubbish.

If it was a PC-based solution I was interested in I'm more interested in POWER9.

>>846725

*to exploit the bootloader, bad wording. There's several serious flaws that allow early persistent takeover of the system.

>>846725

There's still old powerpc macbooks out there if you are looking for slightly more secure hardware. Just slap openbsd and coreboot on one and you are good to go.

>>846712

Think I found the reason in the full diff:

This has a down side: the LDT isn't (currently) randomized, and an attack
that can write the LDT is instant root due to call gates (thanks, AMD, for
leaving call gates in AMD64 but designing them wrong so they're only useful
for exploits).  This can be mitigated by making the LDT read-only or
randomizing the mapping, either of which is strightforward on top of this
patch.

This will significantly slow down LDT users, but that shouldn't matter for
important workloads -- the LDT is only used by DOSEMU(2), Wine, and very
old libc implementations.

Now that the LDT mapping is in a known area when PAGE_TABLE_ISOLATION is
enabled its a primary target for attacks, if a user space interface fails
to validate a write address correctly. That can never happen, right?

The SDM states:

    If the segment descriptors in the GDT or an LDT are placed in ROM, the
    processor can enter an indefinite loop if software or the processor
    attempts to update (write to) the ROM-based segment descriptors. To
    prevent this problem, set the accessed bits for all segment descriptors
    placed in a ROM. Also, remove operating-system or executive code that
    attempts to modify segment descriptors located in ROM.

So its a valid approach to set the ACCESS bit when setting up the LDT entry
and to map the table RO. Fixup the selftest so it can handle that new mode.

Gotta love the Intel shills poking at AMD (The first bit on Intel chips was reformatted, the AMD bit was added):

+ * On Intel CPUs, if a SYSCALL instruction is at the highest canonical
+ * address, then that syscall will enter the kernel with a
+ * non-canonical return address, and SYSRET will explode dangerously.
+ * We avoid this particular problem by preventing anything executable
+ * from being mapped at the maximum canonical address.
+ *
+ * On AMD CPUs in the Ryzen family, there's a nasty bug in which the
+ * CPUs malfunction if they execute code from the highest canonical page.
+ * They'll speculate right off the end of the canonical space, and
+ * bad things happen.  This is worked around in the same way as the
+ * Intel problem.

More nuggets:

Note: PCID is generally available on Intel Sandybridge and later CPUs.
Note: Up until this point TLB flushing was broken in this series.

PARAVIRT generally requires that the kernel not manage its own page tables.
It also means that the hypervisor and kernel must agree wholeheartedly
about what format the page tables are in and what they contain.
PAGE_TABLE_ISOLATION, unfortunately, changes the rules and they
can not be used together.

>>846725

Well OpenBSD just implemented karl in the official release that came out in October. They say they did it in 3 weeks. Why the rush to completely re-implement how the kernel works and is loaded?

https://marc.info/?l=openbsd-tech&m=149732026405941&w=2

It would be interesting if they mitigated the issue by (((pure coincidence))).

>>846729

WINE BTFO

this is pissing me off even thinking all my vm's are going to take a fucking 35% performance hit. but my anger has to be nothing compared to every cloud corporate kike out there who is itching to shove their dick in intel/amd's asshole for the billions of dollars that's going to cost them.

>>846734

This is Intel only actually. AMD apparently does not cut corners. Really makes you think in terms of how Intel always seems untouchable in single core performance.

In the end though, you deserve it. I think your anger is magnified by the fact that you trusted Intel.

>>846725

Wait, you mean the Nintendo 3DS?

Nintendo can patch boot9 whenever they want. The reason they can't after people hack it is because Luma puts FIRM into read-only mode

As far as the new DS flashcard based hacks go, that isn't the result of a security flaw, rather, the bootloader is "backdoor'd" (more specifically so Nintendo Repair centers can re-flash the OS in the event someone sends in a bricked console as a result of a botched firmware update)

>>846739

What they can't do is patch out the errors that allow B9S (or A9LH) to happen. Those are in the read-only bootrom. Actually, that's something they tried to account for in the Switch, which has a way to generate bootrom "patches". Kind of cute but they should've focused on getting it right to begin with since it's the root of trust.

intel did this on purpose to destroy the old non-me botnet market. i'll bet they disclosed the bug themselves through an intermediary, at the appropriate, most profitable time.

>>846755

>the scale of the problem isn't known

It affects all x86 cpu's with a MMU. Did you even read the fucking thread and links?

>>846757

Since when do we know about the actual exploit? It's under wraps until the 4th supposedly.

>>846755

Pentium 1's are the "newest" intel cpu to be confirmed not affected. Intel managed to fuck up so badly that they took an obsolete class of exploits that everyone had forgotten about and single handedly brought it back from extinction.

While the actual circumstances under which this bug could be exploited are very, very limited, the nature of the use cases (virtualization) make this pretty severe and indirectly effects everyone.

>>846759

Lurk twenty years you giant faggot.

https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initial-Gaming-Tests

So my intuition proved correctly, applications that run mainly in usermode are not affected by this whatsoever. You can all stop shitflinging now you insufferable fanboys

Higher AWS bill and having to reboot everything? My job is going to be a bit more exciting, thanks Intel.

>>846764

You think a reboot is going to clear the MMU?

>>846764

What else do they pay you for?

If I only run free software which I trust I should not need this kernel patch right? All I need the computer for is browse the internets and compile my c++.

>>846767

Well considering you can deliver this infection via just loading javascript into memory, you better absolutely trust everything that runs on your computer will never be hacked or targeted in some fashion. While also always browsing and blocking literally everything but text on the interwebs. Even then things like CSS quirks in browser can be abused to hack you. But I don't think anyone is that autistic for the gerneral population yet.

TLDR if you want real security stop using x86. If you want the feeling of security get the patch. If you want speed and to possibly be spied on then don't get the patch.

>>846768

>if you want real security stop using x86. If

Every major architecture has at least 1 privileged mode. At least x86 is actually being actively audited for security do to its ubiquity. Maybe don't use x86 if you're a cum drinking retard

>>846768

>you can deliver this infection via just loading javascript into memory

source on this? it is possible to write a javascript or webassembly program which directly exploits the cpu bug?

>>846772

>webassembly

Oh don't even get me started on that cancer. Lurk two years if you want to know more.

>>846782

It likely does affect the Pentium D. But unless you run a database that needs to access kernel mode memory from usermode numerous times a day, you will likely not notice a difference. Standard usermode application like web browsers and even the latest AAA video games have been benchmarked and have seen absolutely no performance impact whatsoever

>>846776

>>doesn't affect TempleOS

Because programs already use ring 0 you retard. There's no need for an exploit, the botnet has free access.

FYI: The performance hits will be the worst on programs that do a lot of syscalls and nothing else, like networked programs and shit that needs IO. CPU intensive tasks have no difference.

>>846784

Is it worth moving from hardened sources?

Would there be a grsec kernel with KASLR that is freely available any more?

Is there another way to migitate the flaw using hardened?

>>846787

It seems like literally only server software that needs to abstract kernel memory and access it from usermode for security reasons is affected. That's why Google and Amazon are shitting themselves

For everyone else though, there is absolutely no performance penalty whatsoever and its just business as usual

>>846788

Page Table Isolation is already rolled out to the latest kernels to mitigate it AFAIK. Obviously this comes with the aforementioned performance penalty, but this can be solved with better optimization of how kernel and userspace are abstracted and is really a quick and dirty fix for now

Incidentally, Macfags will likely never notice a difference since OSX already uses PTI

>>846786

That's the joke.

>>846767

this kernel patch is going to get shoved down your throat weather your like it or not. the only way to avoid it is to never update your kernel ever again.

>>846810

Or compile your own kernel with it disabled since only distro maintainers will be blackmailed/coerced by (((them))) to enable the botnet or disable it by default. It still won't save you if you use x86 though.

>>846772

Javascript can be used to achieve arbitrary code execution if there is an vulnerability in the web browser. Once this has been reached the x86 vulnerability could be exploited.

>>846780

>that image

WE

WUZ

been waiting for someone to call that out

>>846818

>>846820

Meds aren't black though?

>>846807

See

>>846762

>>846807

The only applications that are impacted are PCI based storage and database programs

Video games, web browsers, and fucking hell, productivity applications like video editors and Photoshop, will have no performance impact. Stop being a cocksucking fanboy for 2 seconds. The major of users aren't going to see a difference

>>846829

Oh the majority of people will see a difference in their backend performance, and this is a major screw-up for a hardware vendor.

>>846194

OMG GONAD GLOMPF BTFO HOW WILL HE EVER RECOVER

>>846830

No they will not because the majority of programs the average user interacts with are run completely in userspace and do not need to access kernel mode memory a million times a day like database programs. This is why gaming benchmarks are seeing 0 percent performance impact. The only people who should care are server admins. That's why Google and Amazon are shitting themselves right now.

Of course throwing all logic and reason out the window to be a mouth-breathing fanboy is far easier than using your brain so I'm not surprised

>>846832

Just what do you think I meant by backend performance? The online services people use will run slower and/or pass their costs down, or maybe be idiotic and just run it insecurely. It's gonna matter, and it'll probably hurt Intel (which I'm fine with).

>>846834

The whole internet isn't going to slow down as a result either though, retard, Amazon and Jewgle won't let that happen. They'll probably all switch to Threadripper servers before they let that happen. Overall its likely they'll come up with a better workaround, it's likely this can be fixed with better optimization with privileged memory access

Overall the only party here's getting hurt is Intel, which I couldn't care less about, as long as muh gaems run fine and I don't feel like I completely wasted my money on my Skylake, next processor will certainly be Ryzen though

>>846836

I have no idea about Amazon but Google do mix architectures to avoid this, they've got a lot of POWER running around.

>>846836

I'm hardly preaching the apocalypse over this. But it's not some trivial issue either, I for one am pretty pissed off that this sort of flaw exists when they should know better.

>>846832

>what is (insert botnet browser)'s massive cache

enjoy seeing pozfox slow down to a crawl as it makes 500 system calls saving all of the web5.0 frameworks files, and the browsers built-in indexeddb, and all the telemetry and history, all over the harddrive. dont forget all the io that windows 10 generates with it's botnet.

>>846845

There's little reason any browser should be making any calls to kernel mode memory. Modern web browsers in fact tend to sandbox tabs and applets for security reasons. If your web browser requires direct kernel memory access you shouldn't be using that browser today begin with

>>846847

muh WebGL tho

>>846847

Repeating your Intel fanboy paroles will not make them true. Kill yourself you fucking moron. No user space program accesses kernel memory holy shit how retarded are you. This will slow down *everything* that needs syscalls, the more it needs / time the larger the slowdown, how about shut your idiot mouth you worthless piece of shit.

>>846856

Why the fuck are usermode programs seeing 0 percent performance impact with PTI enabled then?

This isn't fanboyism, it's fucking reality, and people like you are salty for no fucking reason other than the fact you have no cannon fodder to feed your shitstorm on anonymous imageboards you condescending twat

>>846856

>This will slow down *everything* that needs syscalls

This isn't about syscalls, this is about usermode programs needing to access kernel mode memory. Video games and web browsers do not need to access memory in kernel mode and api calls they require are likely exposed in usermode memory.

The biggest impacts are web databases that need to run in usermode to serve data for security reason while also needing to access kernel mode memory millions of times a day. This will also impact PCI mode SSDs because filesystems are typically run in kernel space

We are all adults here anon please act like one

>>846855

GL web apps, much like video games, call the usermode GPU drivers. Again, hence why video games are not impacted on Linux. Not sure how Windows is going to deal with this since kernel and user mode abstraction is all over the fucking place on Windows but the upcoming patch will likely deal with it

>>846860

>Again, hence why video games are not impacted on Linux.

Because it doesn't have any?

>>846861

Well this probably wont impact performance on WINE either since I don't think the WINE devs would be retarded enough to allow Windows applications to directly access kernel memory to begin with

>>846194

>muh /pol/ for no reason at all

Nigger.

https://www. phoronix.com/scan.php?page=news_item&px=x86-PTI-EPYC-Linux-4.15-Test

apparently "20year lurker" man is vindicated somewhat

>>846857

>Why the fuck are usermode programs seeing 0 percent performance impact with PTI enabled then?

Because some programs do no/very few syscalls.

>>846867

>spacing URLs like you're on halfchan

Seriously man lurk 2 years at minimum

>>846865

/pol/jeet detected

>>846858

NO USERSPACE PROGRAMS ACCESS KERNEL MEMORY, THAT IS THE POINT OF THE SEPARATION

>>846868

This isn't about syscalls necessarily, this is about usermode programs needing to access kernel mode memory. If an application runs entirely in usermode, or entirely in kernel mode, it is not effected. If a kernel mode program needs to access usermode, it is not effected, but if a usermode application needs to access kernel mode, it is effected. The overhead is because usermode applications now need gated access to kernel memory and kernel memory is no longer freely exposed to usermode programs

>>846648

Android is Linux with even more evil inside.

>>846872

Wrong. Kernel space is typically exposed to user space via virtual memory for performance reasons. Its the kernels job to manage what data can be read freely. The Intel CPU bug allows all memory that would normally be unreadable to be exposed to usermode applications, hense why page table isolation is now necessary.

>>846861

>what is steam on linux

>>846882

>regretting it in the first place

IHBT

>>846884

Something that doesn't respect your freedoms?

>>846890

>>846884

speaking of not respecting freedoms, i wonder how many syscalls steam for linux makes with VAC. steam probably wasn't included in that benchmark

If jewgle etc. adopt threadripper where will I get my hands on the stuff they're dumping?

Do I hang around the dumpster out back or something?

>>846732

>Our immune systems work better when they are unique. Otherwise one

airline passenger from Singapore with a new flu could wipe out Europe

(they should fly to Washington instead).

Sick. Not as sick as FUCKWIT but still pretty hot.

>>846882

Are there even any coreboot compatible AM3 mobos?

>>846732

I wonder who use it as a host system as their most advanced vm system is chroot.

Next time they and loonix devs should hide userspace from users for even greater security. :^)

>>846732

There wasn't any rush. This randomization has been in the works for several releases. In fact, over a year ago someone on misc was asking about running OpenBSD with disk mounted read-only, and one of the developers (or maybe even Theo) said that was no longer supported because now libraries get randomized on every boot. Doing the same with kernel was just the next logical step.

Will PS4/Xboner have the same issue since they're x86 based? Could this lead to finally getting them cracked open?

>>846939

ayymd not affected. I wonder if intel will delay their new chips due to this

>>846912

Yes, search the coreboot wiki nigger.

>>846180 (OP)

AMIGA FOREVER

PC BTFO

Shills will defend this and cover it up and say nothing is going on. Remember that.

No surprises here. Every tech expert and their dogs knows that with intel you lose.

Amazing that big corps like amazon and google that have a lot of money to lose don't know this.

Trusting intel is just as bad as trusting microsoft.

>>846973

but the tech expert linus tech tips told me intel has more "platform stability" :(

>>846974

he is the most trusted source of unbiased tech related information, everything from obscure operating systems like linux and *bsds, to nerf guns. weird how he got that one wrong

>>846991

>I really am beginning to realize that Linux is really just as untrustworthy and shady as Windows

I wouldnt go that far but this case is pretty shady indeed.

>>846970

They have been. Look at all the "muh kernel memory access" droolposting above from someone paid to not understand what a fucking syscall is.

Fun fact: every time an extension icon redraws in chrome/chromium it writes the image to a berkdb database on disk and forces a sync (inotifywatch $profiledir/Extension\ State if you don't believe me). Imagine how many other retarded things your entire desktop must be doing 50 times a minute.

>>846194

Easiest PowerPC to get ahold of: G3 and G4 PowerBooks and iBooks. Get them with nice shattered screens. They'll be comparable to or a little slower than an Intel Pentium 4. You should be able to find them for next to nothing online.

Shattered screen is best because you can take the thing off, throw it away, and plug in a VGA monitor and have a 'slab' computer with built in keyboard and mouse. You just need to add an OpenFirmware script which re-aliases screen from Stone_A to Stone_B so that the Linux kernel will display on the correct output device (VGA monitor rather than shattered LCD screen).

>>846211

>Why do I find this so hard to believe?

Dunno. Why do you? I remember some early AMD Phenoms being hit with a similarly costly kernel workaround for a bug in the MMU HW. It wouldn't even be the first time.

>>847006

I was considering this too. The problem is that the source code for the "openfirmware" BIOS has been shoahed off the internet. The oldest archive of it is two years old. That is alot of time to fuck up or botnet the firmware of the physical powerbooks. Unless someone has a backup of it there's no real reason to go down this path since you still have similar shiitty problems using openbsd on it as on x86 because of known BIOS/openfirmware bugs/trojans. the screens are really easy to fix though if you know what you are doing you could even upgrade/replace the screen if you go and upgrade the on board GPU at the same time using something like a newer AGP card or a self-made AGP to pci-e mini converter

>>847023

>openbsd

No Mandatory Access Control. How could it be taken seriously?!!

Also no bootable encrypted root with OpenBSD. Crypto and ZFS are theoretically possible with ppc32 grub2. Therefore Hardened Gentoo GNU/SELinux wins.

>>847026

>grub

>on openfirmware

Were you born retarded? You don't need grub when you can modify the firmware you giant faggot. That's why I was talking about the source code for the openfirmware project so that support for encrypted drives could be added in forth instead of the insane systemdicks mess that grub2 is. That and fixing firmware bugs. But it was shoahed off the internet you stupid fuck.

Watching all the shill arguments about how this isn't a big deal is really eye opening. If Nvidia or AMD sold you a graphic card, and then went

>well we found a bug

>some specific situations will be half as fast as they were before!

>Sorry!

you'd be pissed off if Nvidia or AMD got online and went

>well it only affects a small portion of customers and look here's some times where it barely affected performance

People bought these Intel CPUs after looking at benchmarks and expecting a certain level of performance. Now now, we're seeing worst case scenarios where post-patch the Intel CPU is running half as fast as it used to.

Anyone who tells you a product that isn't what you thought it was isn't a big deal is not your friend. They are lying and full of shit. All these fucking tech sites

>Buy the Intel, it's 5% faster overall!

>Intel is 10% faster in games! It scored 110 instead of 100!

>Get the Intel!

<losing 50% of performance with Intel in some situations isn't bad

<buy more Intel!

>>847032

someone needs to file a class action lawsuit against intel for false advertising. They knew about this but didn't want to disclose it because it would hurt sales. Fucking kike CEO even dumped his stocks early in december.

>>847026

OpenBSD has encrypted /root, the install docs page has a whole segment on it. In fact, OpenBSD has a full encrypted disk, i.e. /boot and /root.

You're just a retard.

>>847034

... until you find out ofwboot doesn't support reading that FDE.

You're just a retard calling others retard.

>>847031

>source code for the openfirmware project

You mean https://github.com/openbios ?

word on the street is it will be unembargoed (soon)

>>846649

You learn to do that over time when working in a large corpo.

>>847041

That's the sparc version and possibly a botnet. We need the powerpc version for powerbook macs. It used to be located here https://archive.fo/GEbMu but here is the shoahed version https://archive.fo/vlWP3 . Anyone have a backup?

>>847038

You are a even larger colossal retard. If you have the source code to the "openfirmware" on macbooks you can just program it to read FDE instead of adding the bloat that would be grub2.

Why is AMD not taking advantage of this to push Epyc?

>>846688

>what is a workaround

If I turn off virtualization features in my bios, am I unaffected? This should mostly impact public clouds right?

>>847052

They don't need to. These fixes for Intel are completely clobbering Intel disk performance. Which means all those giant websites with massive databases are going to get fucked.

Imagine you run something like Facebook or Twitter and when you get his new updated kernel, you lose 50% of your database performance when database has to go to disk.

Intel is currently trying to bribe Microsoft and Linux to making sure this patch applies to all x86 CPUs, including the AMDs that this doesn't affect. I assume AMD is staying quiet, for now, because no one really knows if the patch to fix Intel is going to also apply to AMD.

>>847054

Nope, this affects everything, and the "fix" that destroys performance is coming to your kernel very soon, unless you compile your own. Shills are just trying to write this off as something that only affects database and virtualization. It affects those more than anything, but performance is going to tank over a lot more than that, and it's going to make a lot of things massively insecure.

The paid off tech sites are already starting to write this off as just a datacenter issue and then wagging 3 gaming benchmarks in front of people's face so they can go

>look your games are still just as fast!

>keep buying Intel!

>>847057

I thought AMD was not affected by this? This is a Intel hardware bug.

>>846738

All high-performance CPU manufacturers cut corners. This is literally necessary for extracting decent IPC from real-world programs. The question is which corners get cut, and how the implications of cutting them were handled/mitigated. Sometimes the mitigations turn out to be buggy/incomplete. That's the risk you take every time you do hacky stuff.

By the way, this is not limited to hardware. Performance hacks in software also come with a decent risk of unforeseen consequences. Sometimes they blow up right in your face, and fixing those blowing corner cases is not trivial. Oh well.

>>847059

It is, and they are trying to make sure the fix is applied to AMD so AMD CPUs are slowed down too. They are also trying to be as ambiguous as possible by saying shit like

>well it's not confirmed if it affects AMD or not

Intel knows that if its performance is going downhill, they will try and take AMD's with it too. They are joust like Nvidia, if they have to change software to make their product slower, they'll do everything they can to make sure it negatively affects their competitors more.

>>847060

This doesn't affect AMD CPUs. So you are saying AMD cuts fewer corners? Also, why is Intel cutting corners in a situation that could affect security so massively? I can understand 5.0 + 5.0 = 10.0000001, but this is on a different level.

>>847057

Linux is patched for all x86 CPU, not only Intel. AMD has stated this does not affect their CPU, and has also written a patch to detect whether to apply the fix or not based on vendor, but it is unknown if it will be merged on 4.15 or 4.16. For all we know, x86 performance may be affected for all CPU for a month, but it should be fixed at least by 4.16.

>>847061

Intel really is a pit of jew snakes.

>>847063

This fix is getting backported to earlier kernels. You think AMD's patch is going to affect all those other LTS kernels and such? The fact that you're going to have to patch your kernel if you're on AMD, because of an Intel bug, really shows how much control Intel has over the x86 ecosystem.

>>847067

>this isn't a bug!

>we'll work with ARM and AMD to fix it!

>it could affect them too!

>lots of other CPUs have problems!

>but these problems aren't bugs or flaws!

>it only affects workloads! If you don't give your CPU workloads, it's not slower!

>some workloads might not even be affected at all!

>your games will be fine!

Predictable.

>>847067

Even the cucks at hacker news aren't buying it.

>>846910

They are now forgiven after they introduced actual 8-cores at consumer price points.

Does anyone know which config option does the patch refer to in the new kernel?

http://www.zdnet.com/article/security-flaws-affect-every-intel-chip-since-1995-arm-processors-vulnerable/

>>847083

Important Links

https://meltdownattack.com/

https://spectreattack.com/

>>847061

>So you are saying AMD cuts fewer corners?

No, I'm saying they chose to cut different corners.

>Also, why is Intel cutting corners in a situation that could affect security so massively?

You don't know what it could affect beforehand. Hacks tend to have unpredictable consequences.

>>847079

You did get 8 integer cores with the bulldozer family, so they weren't lying completely

They also publicised the halving of FPUs at the time so there's nothing to forgive really, people should just have RTFM before purchasing something that didn't satisfy their needs

>>847067

this is weak damage control

>dude, you got hacked!

>intel inside!

I can feel the collective piledriver smug in here. Feels pretty good.

I would love it if AMD could speed up the launch of their next Ryzen chips to take advantage of this.

Everything Went Live

Attacks

https://meltdownattack.com

https://spectreattack.com/

Papers

https://meltdownattack.com/meltdown.pdf

https://spectreattack.com/spectre.pdf

Project Zero Write up

https://googleprojectzero.blogspot.co.at/2018/01/reading-privileged-memory-with-side.html

>>847091

FX CPUs get shit on by the mustard race, but it's not a bad CPU for the price. Even if the '8 cores' thing was always bullshit.

>>847092

>I would love it if AMD could speed up the launch of their next Ryzen chips to take advantage of this.

>wanting botnet

The only reason that I would buy amd is when they'll release the hardware source.

>>847095

nice man me too, what CPU are you using now? I have a core i5 :^)

>>847067

That's "there are no tanks in bahgdad" levels of bullshit. The Linux patches specifically indicate AMD doesn't need the workarounds and 'there is no significant penalty yet it will be migtated over time' is some lol. How's that $300M of diversity, doing, Intel?

>>847095

Your post is worthless if you aren't making it from a Commodore 64 my friend.

>>847095

P4

>>847099 meant for >>847096

>>847099

Nice man I'll switch from Intel to AMD once AMD open sources all their hardware too. Until then I'll stay on Intel :^)

>>847097

>The Linux patches specifically indicate AMD doesn't need the workarounds

AMD is still vulnerable. Note how that line is no longer in Linus' tree.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/cpu/common.c#n927

>>847099

>More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013).

>Pentium 4

>2000 to 2008

>>847103

That comment just says they are going to assume all x86 CPUs are affected, not that AMD (and Via) are affected. Kind of funny how Via gets excluded from all of this, it's almost like Intel is just trying to drag their main competition into this and they're not actually worried about all x86 CPUs.

>>847106

from the website for the attack

>Which systems are affected by Spectre?

>Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.

>>847094

>Even if the '8 cores' thing was always bullshit.

Not really. It's 8 ALUs and 4 FPUs, so it depends on your workflow x264 really like those CPUs.

>>847110

Only spectre. If you read the rest of the page, Spectre isn't the one that is requiring kernel patching, only Meltdown does. Spectre looks like it'll be a compiler fix with some patching to existing software. Meltdown is the one that needs kernel patches, and so far it's only confirmed to work on Intel.

>>847106

Via has been out of the game for how long now?

>>847110

>Is there a workaround/fix?

>There are patches against Meltdown for Linux ( KPTI (formerly KAISER)), Windows, and OS X. There is also work to harden software against future exploitation of Spectre, respectively to patch software after exploitation through Spectre .

The patch is for Meltdown, good try Jewtel.

>>847114

I believe they are now planning to reenter it, in partnership with some chink semiconductor company.

>>847114

Their embedded market is doing very well, and now they are teaming up with the Chinese Zhaoxin ZX to make high performance x86 CPUs. They are claiming they want to hit Ryzen levels of performance in two or three years.

>>847120

Yup. It might actually provide decent competition to Intel and AMD. But it'll probably be another three or five years before they get there, and even then do you really want communist botnet?

>>847093

The Project Zero post is really interesting for any anons who want to know more about the vulnerability. Just saying.

>>847113

>Spectre looks like it'll be a compiler fix with some patching to existing software

Source?

From https://spectreattack.com/#faq-why-spectre

>Why is it called Spectre?

>The name is based on the root cause, speculative execution. As it is not easy to fix, it will haunt us for quite some time.

>>847114

I actually have a Via nano equipped thin client. Doesn't look that bad compared to Geode or Atom.

>>847107

Why is this video so fucked up?

>>847124

How is it fucked up?