/icbm/ Intel Custom Bug Meme general

I got some questions :

Why doesn't Intel rolls an microcode update?
Will windows or Mac be slowed down too?
Who the fuck updates it's kernel?
When are new apus (AMD) coming out?

Other urls found in this thread:

lkml.org/lkml/2017/12/27/2
lwn.net/Articles/569635/
lkml.org/lkml/2017/12/4/709
theregister.co.uk/AMP/201...
pythonsweetness.tumblr.com/pos...
bishopfox.com/blog/2017/10/a-bug-has-no-name-multiple-heap-buffer-overflows-in-the-windows-dns-client/
myredditnudes.com/
twitter.com/AnonBabble

get the fuck out of here there's enough threads as it is

>Why doesn't Intel rolls an microcode update?
Already did. 30~61% performance drop.

We should contain all discussion in a general.

If there's a microcode update, why is there a separate patch for Linux?
No, you

>Why doesn't Intel rolls an microcode update?
They have yet to even confirm the bug, they are probably working their asses off to find a solution.

>Will windows or Mac be slowed down too?
Microsoft apparently started working on a patch already back in November. But yes, all three OS do the same optimisation by mapping kernel space into lower memory of every process.

>Who the fuck updates it's kernel?
Kernel updates are quite frequent on Linux, because they usually contain security fixes. On average, my Ubuntu LTS 16.04 updates kernel every 3-4 weeks.

No, that's the performance drop reported by PostgreSQL using the Linux patch AFAIK.

Unironically this.

I've the same kernel from 2013 on my 4 gnu/Debian computers and server.
Thanks for the full answer, if someone does another general when this is dead include this
I feel kinda bad, but I never really do anything risky except for Sup Forums
That's why I made this thread!

where my fellow ryzens at

>I've the same kernel from 2013 on my 4 gnu/Debian computers and server.
Then you should probably update asap, 2013 kernel means you're probably on 3.xx versions, and a lot has happened since then.

i propose the general be called /JUST/

not even debian stable is that out of date, you just never update them

>Just bought a 1700X with a GTX 1080 Ti PC
>Feel like a retard for going AMD when all I do is gayming which prefers higher IPC
>mfw this bug happens, lowering Intel performance

3.x kernel, your security hole is bigger than goatse stretched anus

OP here, I got 3/4 AMD computers, unfortunately I got one xenon server so... I'm just really curious


Another topic, considering most of the internet services runs on xenon servers will I get indirect gimped in for example a cloud service?
I will do when I update to the new stable release, in just postponing it since the last year tee hee
That's right! I froze the kernel packages because I didn't want my graphic drivers to break down
Never do that, unless you're me of course

they'll just give us the keys to push our own ME updates. problem solved, thanks intel
my 7700k is still superior to memerippers

>Why doesn't Intel rolls an microcode update?
Maybe because the issue can't be fixed with a microcode update. Or maybe because there's still an embargo in place.

>I didn't want my graphic drivers to break down
you're not still using fglrx or something, are you?

I'm a also interested in that "indirect gimp"

>I didn't want my graphic drivers to break down
I'm and I resolved this by installing Nvidia's CUDA .deb package which handles kernel dependencies for me. Whenever I update the kernel, the system has also recompiled driver for new symbols automagically.

ALERT: no microcode update will fix the issue

Has Intel confirmed this, yet?

Thanks!
Source?

>two major operating systems are scrambling to create a workaround in the kernel
There's your source.

I'll give you that's it is a pretty clear indicator and strong circumstantial evidence, but it's still not an official statement. Seeing how Microsoft began patching in November and that Intel hasn't said anything so far indicates to me that they are working hard at resolving the issue.

I'm not confident enough to say anything definitive until Intel themselves make a statement.

There is no statement because they need to fix it before telling people how to exploit it.

NOTHING BEATS FUCKWIT LMAO

>The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, was mulled by the Linux kernel team

>There is no statement because they need to fix it before telling people how to exploit it.
People already know how to exploit this.

what bug what is wrong with Intel ?
I have i5-4690K 3.50GHz will I experience any issues gaming wise

My question is : what if I don't apply the update? I use windows and Linux, I can stop this patch from being applied.
How at risk am I? What are the requeriments for someone to exploit my machine?

No they don't. There are only guesses.

T H I R T Y S E V E N
H
I
R
T
Y

S
E
V
E
N

Tell me then.

Research has confirmed the bug is an issue with the processors architecture and so cannot be fixed simply with a bios update.

AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.

Disable page table isolation by default on AMD processors by not setting the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI is set.

>Why doesn't Intel rolls an microcode update?
Because it can't be fixed with microcode updates.
The design (looks like prefetching algo) is FUBAR.

>No they don't. There are only guesses
Then why is there a hastily made patch for Linux that by default is enabled on all Intel CPUs for now?

Microsoft apparently started working on a patch for this in November, which means that your system is probably just going to get updated as usual with Windows updated.

As for Linux, you do want to apply the patch / upgrade the kernel.

>What are the requeriments for someone to exploit my machine?
The claim is that a userspace process can somehow make kernel memory leak, which is obviously bad and compromises your entire system. You still have to run a process on your system, but that process can install a rootkit without you being aware of it.

Useful resources explaining the bug:

lkml.org/lkml/2017/12/27/2

lwn.net/Articles/569635/

lkml.org/lkml/2017/12/4/709

theregister.co.uk/AMP/201...

pythonsweetness.tumblr.com/pos...

See and Seems like it's possible to exploit the prefetcher.

By "people" I mean the general public. Obviously a select group of developers knows what the issue is.

>You still have to run a process on your system
Sounds like something every single cloud provider has to do.

My last windows patch was in October, part of a Simplix pack.

>As for Linux
Still see no reason to do so.
>still have to run a process
I'm usually not that retarded.

>3570k and mobo decided to die
>bummed out that I didn't get to wait for next Zen
>mfw not even mad that I went with the 1700 now
Fuck the RAM prices tho

>Sounds like something every single cloud provider has to do.
Exactly. And it should be fairly easy to break out of VM isolation as well and get control over the host OS. So it's obviously a big deal that needs to get resolved quickly.

Quite many people read the Linux mailing lists, user. Including people looking for making exploits.

It's the mods job to pin down a general
But it's Sup Forumsentoomen who we are talking about
Lame pajeets

>>still have to run a process
>I'm usually not that retarded.
Well, this is obviously a hyperbole, but your JavaScript engine is a process isn't it, and you're running JavaScript that some one else has written in your browser/engine. If that engine has an exploit too (which they often do), you could potentially be fucked.

How will this affect Mac products? What happens when that $14,000 iMac now runs even worse?

>Quite many people read the Linux mailing lists, user
What are you arguing about? There is no publicly known exploit for this yet. We know that there's definitely something and it's probably really bad but that's it.
The number of people who know how to exploit this is both controlled and minimal.
There is no official statement yet because it first needs to be fixed.

>don't buy an 1800X they said
>it's a waste of money they said

Get fucked, intel shills. Ryzen Master Race!

>How will this affect Mac products?
macOS needs a similar fix.

>What happens when that $14,000 iMac now runs even worse?
The fixes for all OS revolve around the cost of context switching. This impacts high-end servers that does a lot of IO in a larger degree than your day to day use at home, so chances are that most applications don't see any drastic difference in performance, but stuff like database engines and intensive disk reading/writing does.

True. I guess I prefer to be unsecured than to take the hit. I spent so much time improving my t430, I don't want to get another laptop. I hope this brings to the market more sockets for both vendors.

That said, Intel is fucked.

>tfw Core lMao(M) laptop
Fuck, is it going to get even slower?

>There is no publicly known exploit for this yet
That's true, but that's not the same as people not knowing how to exploit it.

>The number of people who know how to exploit this is both controlled and minimal.
Minimal, maybe. Controlled, absolutely not. This may have been an exploit known for years by intelligence services and russian botnet makers.

>There is no official statement yet because it first needs to be fixed.
There is no official statement because it wasn't known a few days ago and they will try all they can to fix it in microcode before they admit that it is a hardware design flaw.

So is there any chance apple reworks the MacBook pro line for ryzen? I know it was kicked around for a minute but this may get the idea back on the board. I'd probably buy a ryzen 7 MacBook pro with Vega in it.

>True. I guess I prefer to be unsecured than to take the hit
See You're probably not going to notice any considerable performance degradation for normal use.

SPLOITS ARE CLEARLY ALREADY OUT THERE BUT THEYRE BUSY TARGETING HIGH VALUE SYSTEMS TO GET INB4 THE PATCH

BY THE TIME IT MAKES IT TO SOME PLEB WHO EMBEDS IT IN SOME JAVASCRIPT TO POP THRU UR BROWSER ITLL BE MONTHS, ALSO COST BIG BUX

I have no idea, but I would be interested in knowing too.

Probably, I'd rather see some proof, though. If I apply a patch and I think it might affect considerably, that's all I'll think about. You know, placebo and stuff.

Definitely going for AMD next time.
On the other hand, this will make it much cheaper to upgrade my current cpu (i5 to i7) in the following months.

>that's not the same as people not knowing how to exploit it
Don't argue semantics with me.
>Controlled, absolutely not
Controlled to the maximum degree possible.
>it wasn't known a few days ago
So it's pure chance that both Windows and Linux started implementing the exact same mitigation strategy at around the same time a few months ago?

bug baked into all Intel CPUs of the last decade
>bug baked into all Intel CPUs
>all Intel CPUs
>Intel CPUs
>Intel

This isn't a fucking bug. This was intentionally placed in the sillycone by (((Intel engineers))) as part of their overreaching scheme for world domination

The goy were never supposed to find out about it. Now there is an embargo so that the problem can't be patched until a new exploit can be put into software.

I meant weeks, but wrote days for some reason. But yeah, it's not by pure chance, but that DNS remote code injection bug discovered in Windows this summer wasn't blown out in newspapers either and there still aren't any reported exploits, but it would be naive to assume that because there are no reported exploits then there cannot be any.

Absence of evidence is clearly not evidence of absence.

>Why doesn't Intel rolls an microcode update?
My motherboard hasn't had a BIOS update since January 2012, how exactly is a microcode update going to help me?

>Will windows or Mac be slowed down too?
Yes

>Who the fuck updates it's kernel?
What?

>When are new apus (AMD) coming out?
Desktop APUs this month supposedly.

AFAIK this has NOTHING to do with the ME, but how all intel CPUs up-to and INCLUDING Coffee Lake handle certain sets of executions.

Microcode can be applied by the OS as well. The BIOS method is more thorough since it also applies it to systems that wouldn't get it normally.

You are arguing over an incredibly stupid detail that I already clarified twice.
I did not say that there is no human on this planet that knows how to exploit the bug.

Not disagreeing, just going to point out that the embargo has been up for months. Bug has been discovered like half a year ago.

>tfw chink tablet with Atom

What did he mean by this? Does that mean that Windows is gimping AMD or that Windows in only gimping Intel? Please respond, I don't speak Kernel.

>... there's enough...
...There ARE enough...*

>that I already clarified twice.
I'm sorry, but I'm not taking your word for it when you say "Intel hasn't made a statement because HACKERS!!!!!zomg" when all the required information to make an exploit is already out there. It's far more likely that they will exhaust all possible resources in order to fix this in microcode before they have to resign and admit that it is a hardware design issue.

UR ALREADY CHINK BOTNETTED SO WHATS THE DIFFERENCE :^)

>just going to point out that the embargo has been up for months. Bug has been discovered like half a year ago.

And yet they still released Coffee Lake with the "bug" in it. They knew between the time when the silicon was finalized and when product would ship to customers. They went ahead and knowingly sold a worse-than-defective item.

Fucking kikes at Intel

wtf I hate Intel now

If it is true (I only know Linux kernel), then yes that would mean that Windows is gimping AMD as well.

>"now"

only if you fuckers don't make a new thread as soon as you hit the bump limit

I know low level x86 quite well. Could you explain what KPTI and KVA means? As far as I understand it has something to do with branch prediction and virtual memory. How does this exploit work? I'm a 4 year CS student, but I have zero background in security. Is there an explanation out there that I could understand?

They already resigned. That's why a software solution is being implemented.
Do you really think that Intel isn't working together with Microsoft and Linux on this?

If all the required information is out there then we would already be hearing about it being used.

Well, yeah. I bought my i5 3570k two and a half years ago and it has served me well. I was under the impression that while Intel CPUs are pricey, they're also high-quality. That impression is gone now.

>world's most advanced kernal
>doing simple string comparisons to check cpu type

Bravo, bravo. Even windows probably does something better.

>string comparison with !=

How easy is to to spoof that CPU string from user space?

t. java brainlet

what is strcmp?

>an microcode update
>an microcode
>an

>Do you really think that Intel isn't working together with Microsoft and Linux on this?
It should be fairly easy to grep Linux patches for Intel contributions on this.

>If all the required information is out there then we would already be hearing about it being used.
Did you hear about the DNS exploit** in Windows being used? No, you didn't.

Your analogy is flawed.

** exploit in question: bishopfox.com/blog/2017/10/a-bug-has-no-name-multiple-heap-buffer-overflows-in-the-windows-dns-client/

>Doesn't understand C, but shitposts anyway

Its another episode of
>amd perfect product placement makes Sup Forumstecnology become r/AMD
who wants to get upvoted

KPTI (formerly KAISER) is Kernel Page Table Isolation, the Linux kernel fix for the Intel bug. Read the LWN articles for details, basically it separates user and kernel memory pages. The Windows fix is the same thing though it has another name.

>imblyin Sup Forums wasn't /r/amd since before ryzen came out

>tfw even javascript can access your kernel

So how does having different pages for user and kernel space impact performance? Isn't that kinda the point of paging to begin with?

Not the guy you were asking, but I'll try to explain:

Knowledge about the exploit is not public right now, so we can only speculate from the way the fix was implemented in the Linux kernel.

I'll assume that you know how virtual memory works. What they are doing is unmapping the whole kernel from memory each time the cpu switches to userland and remapping it when a syscall is executed. Of course, that is extremely bad for performance because you also have to flush TLBs and caches if you do this. It really makes no sense performance wise, so everyone assumes that a security hole was found that somehow allows reading or even writing of protected pages. Normally the hardware should ensure that pages that belong to the kernel cannot be accessed from ring 3. The only workaround to stay secure is to remove the kernel from the memory mapping every time userland code runs so it can't be fucked with.

Again, nobody knows what's going on, these are all just assumptions based on the fact that they implemented this change and are holding back some of the documentation for it.

Why does the performance degradation happen? Also who pulled 30% out of their ass?

>hasn't read K&R

Before, when doing a syscall you could use the same TLB because it also contained kernel addresses. Now, every time a syscall is made the TLB must be flushed and reloaded. That's where the performance loss occurs.

your fps will be kill user

because now instead of sharing some of the same memory space the computer has to completely switch memory space.

it'd be like if you were making dinner and every time you had to chop something you had to go to the house next door.

Thanks. Great explanation

I don't know alot about the exploit itself, but I do know why the fix for it causes a performance drop.

KPTI = kernel page table isolation

I speak about it in this post: Basically, it used to be like this:

The kernel also uses virtual address space, but kernel's address space was mapped into the same virtual address space as every single process (although protected from reading and writing), which reduced the cost of context switching (e.g. when doing a syscall).

The fix is to place kernel memory in its own isolated virtual address space (instead of mapping it in along with every process), which means that when you do a context switch the kernel needs to replace the page directory and page tables, and memory accesses in the kernel may actually cause page faults. This is where the performance hit comes from.

To my understanding, the weakness has to do with prefetching algorithm implemented in hardware. I'm not a hardware guy, but essentially the architecture does a lot of "clever" tricks to attempt to speed up memory accesses by loading ahead of time.

See above.

>Your analogy
I made no analogies, you did. What are you even trying to prove with it? Was it used or not?

>grep Linux patches for Intel contributions
I'm not going to bother doing background checks on people making commits for this.
It doesn't necessarily mean that there are literally Intel engineers commiting code to the kernel.

Yeah, because >performance and >ebil amd chewing our market share
Probably hoped no one would notice. I find it hard to believe they didn't know about the bug.