Quantcast
[ 3 / biz / cgl / ck / diy / fa / g / ic / jp / lit / sci / tg / vr / vt ] [ index / top / reports / report a bug ] [ 4plebs / archived.moe / rbt ]

Due to resource constraints, /g/ and /tg/ will no longer be archived or available. Other archivers continue to archive these boards.Become a Patron!

/g/ - Technology


View post   

[ Toggle deleted replies ]
File: 153 KB, 600x815, 14667770634080.jpg [View same] [iqdb] [saucenao] [google] [report]
64119134 No.64119134 [Reply] [Original] [archived.moe] [rbt]

http://www.techpowerup.com/240187/amd-struggles-to-be-excluded-from-unwarranted-intel-vt-flaw-kernel-patches

>AMD is immune to the VT flaw
>Linux kernel developers include AMD in the black list anyway, cucking it over alongside with Intel
>"This shows that AMD's requests are being turned down by Kernel developers. Their intentions are questionable in the wake of proof that AMD processors are immune, given that patched software inflicts performance penalties on both Intel and AMD processors creating a crony "level playing field," even if the latter doesn't warrant a patch."

What the actual fuck are you doing, you stupid fagshits? Stop this fucking bullshit right fucking now and let AMD fucking breathe already, you fucking POS. I always supported Linux for the last 15 years, but this is beyond retardation levels that the FOSS community had up until now.

>> No.64119154

>>64119134
I'm glad the Linux kernel is open source so I can decide whether I want this patch or not.

If Windows pulls this shit as well the shit storm will be epic.

>> No.64119156

>>64119134
compile it yourself

>> No.64119172

>>64119156
It's being pushed with the official kernel structure, you dumb shit. This is not only about "recompiling a build".

>> No.64119184

>>64119156
Don't need to, it's a kernel option so super easy to switch

>> No.64119211
File: 15 KB, 480x480, 1367433108127.jpg [View same] [iqdb] [saucenao] [google] [report]
64119211

>>64119134
I thought open sores was the best choice? what went wrong with l*nux?

>> No.64119212

>>64119184
This, OP is a fag.

>> No.64119218

>>64119184
>super easy to switch
Not for big data centers and servers. They're on plan and contracts, so this affects them directly and they can't "jump ships" easily. What this basically means is that kernel developers' autistic behavior towards AMD at this very moment literally directly affects Amazon, Baidu, Netflix, Alibaba, and many bother big companies who already gone Zen instead of Inturd.

>> No.64119228

Is there any software fix of Ryzen Performance Marginality problem?

>> No.64119235

>>64119172
It's literally just a switch. Any distro could decide not to cripple AMD CPUs. And if they don't you can rebuild it within minutes yourself.

>> No.64119239
File: 17 KB, 600x378, wojak.png [View same] [iqdb] [saucenao] [google] [report]
64119239

>>64119134
Intel makes their own Linux distro. Why isn't AMD doing the same? And if they are, why don't they just strip out the patch? Couldn't other distributions also provide versions made specifically for AMD CPUs, like not just x86_64 but for the specific brand?

>> No.64119252

>>64119211
It is. With Linux you can decide to use the AMD patch that won't cripple your performance. If Windows pulls this same shit AMD users are cucked into oblivion (which they deserve for running a closed source proprietary OS).

>> No.64119276

>>64119211
>what went wrong with l*nux?
Linus and Stallman basically being maximo autismo faglording retards towards AMD at this current moment. Probably would last for a long time, too.

>Any distro could decide not to cripple AMD CPUs
This is not how that works, kid. This is a direct kernel issue and many custom distros utilize same kernel structure. Let's say this affects kernel version A, for example. Then this will automatically affect any and every distro built on the said kernel A's core. And there's a shitton of distros that already jumped onto latest Linux kernel, the one which is affected by denial-that-AMD-immune-to-VT-flaw. You can't easily fix this by "just changing the distro", as most distros work on same kernel. Not all, yes, that's true, but most of them.

>> No.64119322

>>64119276
Distros can just apply the patch by AMD so the CPU bug feature flag isn't set for those CPUs. I don't see why you think distros will just continue to use the kernel as it is while the patch is easy and distros already make tweaks to the kernel anyway. Exempting AMD from the performance loss is really just a small tweak (a huge decision, maybe, but still just a tweak).

>> No.64119329

https://twitter.com/aionescu/status/947976055179976704

>> No.64119330
File: 1.25 MB, 458x250, WTHIWWYP.gif [View same] [iqdb] [saucenao] [google] [report]
64119330

>This really pisses me off. It looks like Intel have used their power and influence to corrupt the open source scene to put AMD at the same disadvantage as them and thus stifle competition.

>People have noticed a recent development in the Linux kernel: a rather massive, important redesign (page table isolation) is being introduced very fast for kernel standards... and being backported! The "official" reason is to incorporate a mitigation called KASLR... which most security experts consider almost useless. There's also some unusual, suspicious stuff going on: the documentation is missing, some of the comments are redacted

>> No.64119348

>>64119322
>Distros can just apply the patch by AMD so the CPU bug feature flag isn't set for those CPUs
The """"""patch by AMD""""" doesn't completely resolve the problem, as performance hit is still there, it's just 5% now instead of 30~35% on Inturd. Meaning that this shit still sits there and AMD simply made a small workaround, but it's NOT fixed at the kernel level.

>> No.64119351

>>64119330
>There's also some unusual, suspicious stuff going on: the documentation is missing, some of the comments are redacted

That's just the embargo, sweetie. Just wait for it to end and we'll really see what's going on. For now cling on to your tin foil hat.

>> No.64119375

>>64119134
in this sjw world we live in nowadays, we don't clap for the chap that can run faster but brake his ankle so everyone gets the medal for crossing the finish line at the same time

>> No.64119390

>>64119218
>Amazon has employees that manage billions of dollars worth of tech infrastructure.
>It accomplishes this by layers of automation stacked on top of layers of automation.
>They can't automate adding a flag to the kernel boot based on CPU type.

They've probably already done it. Not that it matters. For better or worse Intel still controls the majority of the enterprise market. That's why this is such a big deal to these types of companies.

>> No.64119403

>>64119348
The patch by AMD is literally just a flag to exclude AMD processors from PTI.

>> No.64119422

>>64119403
>The patch by AMD is literally just a flag to exclude AMD processors from PTI
It's not being overridden completely. That shit still affects AMD even after the "patch". And this can't be fixed fully until kernel itself gets that shit out.

>> No.64119434

>>64119134
You shouldn't get so upset honey

>> No.64119442

>>64119218
I'm talking about enabling/disabling PTI

>> No.64119452

>>64119422

Why do incucks lie so much?

>> No.64119467

>Intel cuts corners to get performance advantage
>Intel dominates market for 7 years
>AMD comes back, IPC the same as intel without cut corners
>Massive intel bugs discovered, ME completely broken into and 5-60% performance hit to keep your memory secure
>Both linux and windows devs are bribed to cripple AMD needlessly as well

We'll never have anything nice at this rate

>> No.64119475
File: 113 KB, 1199x527, DSfjMjLVQAAeicj.jpg [View same] [iqdb] [saucenao] [google] [report]
64119475

>>64119134
wait I thought the patch was going to exclude AMD cpus

>> No.64119489

>>64119452
He means the Linux kernel is modified even for AMD cpus while not setting the option flag. This will still have some performance loss. Not the massive loss Intel cpus will get, but still non-zero.

The prospect for AMD is still better because when the kernel folks have figured out how to elegantly handle this shit, AMD cpus shouldn't need to be affected anymore. For now it's just full damage control and playing safe.

>> No.64119500

>>64119475
Nope, maybe later.

>> No.64119509
File: 147 KB, 1024x640, 1492546254905.jpg [View same] [iqdb] [saucenao] [google] [report]
64119509

>>64119154
>>64119156
>>64119184
>>64119212
>>64119235
>>64119252
>>64119322

I do not know if this is Brian or just freetards defending the indefensible.

>> No.64119536

>>64119509
They are just pointing out that a decision by the kernel guys doesn't necessarily have to be implemented by the user because it's FOSS. I don't think it has anything to do with defending because I haven't seen an argument here why it's good for the kernel to gimp AMD, only ways to circumvent it.

>> No.64119537

>>64119489
>when the kernel folks have figured out how to elegantly handle this shit
They DELIBERATELY put that shit in there DESPITE knowing FULLY GODDAMN WELL that AMD is NOT being affected by VT flaw AT-FUCKING-ALL. There is NO "figuring out" anything as it's a DELIBERATE KEKERY to "even out platforms"! Basically what this means is that 99.82% of all kernel shiteads are Intbeciles who got MASSIVELY BUTTMAD that AMD has a strong win now over their Inturd, so they DELIBERATELY cuck AMD over JUST IN SPITE, just so that THEY could feel slightly better and more "secure" about their sorry asses. And they don't give two shits about the fact this affects ENTIRE FUCKING LINUX USER WORLD.

>> No.64119569

>>64119537
Switch to Windows. :^)

>> No.64119573

>>64119537
Calm the fuck down.

>DESPITE knowing FULLY GODDAMN WELL that AMD is NOT being affected by VT flaw AT-FUCKING-ALL
As long as there is an embargo we cannot know your claim is true. AMD looks very confident they aren't affected and that is promising but the kernel devs have to be sure and protect their users against data breaches.

>There is NO "figuring out" anything
Yes there is because this is all very new and the kernel is a pretty complicated mechanism.

>as it's a DELIBERATE KEKERY to "even out platforms"
Source: your large anus

> 99.82%
Okay, enough. Just stop.

>And they don't give two shits about the fact this affects ENTIRE FUCKING LINUX USER WORLD.
Linux folks not giving a shit about Linux folks. Wewest of lads

>> No.64119577

>>64119134
What rubbish. Hopefully some common sense will prevail.

>> No.64119585
File: 666 KB, 895x565, 1464088144588.png [View same] [iqdb] [saucenao] [google] [report]
64119585

>>64119537
No, you're wrong. This affects AMD whether you like it or not, and no amount of chest beating will change that. AMD is going to have to get nerfed in order for the OS to be safe.

>> No.64119591

>>64119569
Out of my current seven custom builds in the house, only two are running on Windows, and those are XP SP3 32 bit with W7 64 bit SP1 machines. Four more are on different Linux distros and seventh system runs on BSD.

>> No.64119592

>>64119134
>implying amd cpus haven't also been backdoored
kek.

>> No.64119599

>>64119585
Source on amd architecture being vulnerable to this?

>> No.64119607
File: 1.89 MB, 484x682, JUST.png [View same] [iqdb] [saucenao] [google] [report]
64119607

>>64119585
You forgot to enter tripcode and log in, Brian.

>> No.64119608

thank you based Intel

>> No.64119620

>>64119599
It's not. That stupid furfag literally talks out of his ass.

>> No.64119629

>>64119467
>still being unaware of the fact that life on this gay earth is hell
wake up anon

>> No.64119639

>>64119629
fuck off you satanist piece of shit

>> No.64119645

>>64119599
It's absolutely secure, literally 0 flaws:
http://www.youtube.com/watch?v=qgiUuTmXyGs

>> No.64119648

>>64119620
We are not sure yet. AMD claims it's unaffected but there's still an embargo and the Linux devs haven't really explained why they applied this to AMD cpus as well. Maybe they are overreacting, maybe they have reasons to believe AMD is affected as well but obviously cannot clarify this, yet.

We will have to wait and brace for impact.

>> No.64119660

>>64119648
>Linux devs haven't really explained why they applied this
See >>64119330.

>> No.64119664
File: 68 KB, 1326x614, Screenshot from 2018-01-03 21-09-54.png [View same] [iqdb] [saucenao] [google] [report]
64119664

>>64119134
Linus hasn't said anything about it. They just hardpatched everything, __for now__

>> No.64119679

>>64119660
That post has a value of exactly zero. Why would you links this to anyone?

>> No.64119695

>>64119679
Keep on living in delusional denial of the harsh reality until the very end, I guess.

>> No.64119706

>stocks already falling down

>> No.64119727

>>64119695
Why do you insist on this text holding any truth while there is an embargo? I understand you want it to be this way but we really cannot know yet. Just wait a bit until the embargo is lifted.

>> No.64119728

Has Linux (kernel) been compromised? Is BSD the answer? I've been using GNU/Linux for the past 14 years but I'm not into blind loyalty and if this is the time to jump ship let me know. FreeBSD or OpenBSD?

>> No.64119754
File: 85 KB, 984x784, 1504673891329.jpg [View same] [iqdb] [saucenao] [google] [report]
64119754

>>64119706
>THE GAMES hasn't even begun yet and AMD already in strong green while Inturd all in red
Weeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeew

>> No.64119764

>>64119728
>Has Linux (kernel) been compromised?
No, it's a hardware bug. The Linux kernel has been patched to provide a work around.

>Is BSD the answer?
No, it's a hardware bug.

>I've been using GNU/Linux for the past 14 years but I'm not into blind loyalty and if this is the time to jump ship let me know. FreeBSD or OpenBSD?
FOSS is about choice. Pick anyone that suits you best. If this hardware bug is the only reason you want to jump then I can assure you you really don't have to, because it's OS agnostic. If you were sitting on the fence for a while then you really should.

>> No.64119799

>>64119134
Looks like Nvidia is going to be affected as well >>64119763

>> No.64119800
File: 881 KB, 352x200, 1503363948725.gif [View same] [iqdb] [saucenao] [google] [report]
64119800

>>64119764
>Linux kernel has been patched to provide a workaround
>30~35% performance loss on both Intel and AMD
>AMD still has 5% performance loss even after applying it's own workaround of a "workaround"
>workaround

>calls a SECURITY HOLE in VT engine a "bug"

>> No.64119811

The AMD's patch has been reviewed. It's going to be excepted any day now.

It's a bad patch, it's basically blocking the patch by vendor-name checking. Knowing Linus, he'll tell AMD to fuck off and come up with an elegant patch instead. Let's see.
http://lkml.iu.edu/hypermail/linux/kernel/1712.3/01101.html

>> No.64119813

>>64119592
>implying any electronic device on earth haven't been backdored by NSA

>> No.64119820

>>64119800
How can a fucking flag cause a 5% performance loss on unaffected hardware

>> No.64119828

>>64119811
>Knowing Linus, he'll tell AMD to GIVEMETHEMONEYORELSE
Linus confirmed for being literal fucking ransoming scumshit.

>> No.64119837

>>64119811
For all I know, they've done worse workarounds. Patching by vendor name is not the most elegant but should suffice without too much complexity.

>> No.64119839

>>64119820
Because there's no 100% override, that shit still affects AMD even if it's being "mitigated" by AMD's own patch.

>> No.64119858

I bet the kikes from intel bribed the linux foundation to cripple AMD too.

>> No.64119878

>>64119839
Wasn't it switchable?

>> No.64119905

>>64119858
That's literally what fucking happened. And also this >>64119537 to the boot. It's clear as the most sunniest fucking day ever, but buttblasted Penguin shillers would defend Linus and Stallman's dirty phat asses to no end just in spite, just because they're that heavily autistic. Literal fucking retardation. They're trying to unironically justify and protect this. As much as Inturd's shills are downright Intbeciles, Linux user base proven today it's way worse.

>> No.64119969

>>64119839
Wrong.

>> No.64119970

>>64119905
Repeating your autismo rant doesn't make it true, fa.m

Stop speculating and wait for the embargo to end. Then devs can explain their actions. Maybe we'll learn that you're in the right. Maybe we don't.

>> No.64119984

People seriously didn't expect Intel, the company that has violated so many laws in the past to make AMD lose their fabs to not corrupt Linux?

Intel has never been competent. They have just used jewery to prevent AMD from having any success from the past 10 years.

The company needs to die, they have set back so much progress.

>> No.64120000
File: 26 KB, 574x493, serveimage (60).jpg [View same] [iqdb] [saucenao] [google] [report]
64120000

>>64119134
>on Linux for 15 years
>just barely realizing Linux is retarded
just come over to the dark side already

>> No.64120004
File: 952 KB, 500x685, Dudeness.gif [View same] [iqdb] [saucenao] [google] [report]
64120004

>>64119970
>He sincerely and absolutely unironically believes that Linus comes out and openly admits before entire world that he's a bribed buttmad Intel shill
You can't be more of an autistic reality-denying retard than this, folks.

>> No.64120012

>>64119828
Who are you quoting?

>> No.64120016
File: 13 KB, 480x360, Quads Dubs.jpg [View same] [iqdb] [saucenao] [google] [report]
64120016

>>64120000
See/read >>64119591.

Also - checked 'em.

>> No.64120050

>>64120000
How is BSD handling this hardware bug, fa.m?

>> No.64120063

>>64120050
They don't give a fuck actually.

>> No.64120068

would be nice to see the bsd kernel commits related to this issue and to see if they apply it only for intel or for everything x86, like linux

>> No.64120086

>>64120063
So BSD isn't viable anymore for data centers using Intel? That's harsh

>> No.64120092

looks like there will be a kernel command line flag, so no need to recompile
https://lkml.org/lkml/2017/12/27/145

>pti=off
can somebody verify this? I don't have the patches installed yet.

>> No.64120121

>>64120092
>pti=off
If this happens, then it will restore both AMD's and Intel's performance back on, but also returns VT flaw back on Intel's side.

>> No.64120126

look at line 926

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

yep, they cucked amd too

>> No.64120144

>>64120126
>for now

>> No.64120188

>>64120126
>yep, they cucked amd too

...for now. I guess they are playing it safe. Just AMD saying they aren't affected is no reason to risk the integrity of your user's systems. I'm pretty sure if AMD's claim looks legit and the kernel devs find an elegant solution most AMD performance will be restored.

>> No.64120210

>>64120050
I haven't seen patches in FreeBSD/OpenBSD yet, but I think FreeBSD will eventually publish a work-around too. https://marc.info/?l=freebsd-security&m=151494508518235&w=2

Don't know about the OpenBSD devs. They either publish a work-around too, or they drop i386 and amd64 support. Equally likely.

>> No.64120251
File: 16 KB, 252x291, merchantnormal.jpg [View same] [iqdb] [saucenao] [google] [report]
64120251

>>64120126
The linux devs are just making sure AMD processors don't have the same obscure hardware flaw as the processors developed completely independently from them, I'm sure intel's shekels had nothing to with it.

>> No.64120256
File: 40 KB, 515x488, 1507677714252.jpg [View same] [iqdb] [saucenao] [google] [report]
64120256

The expression “the Linux kernel” can easily be misunderstood as meaning “the kernel of Linux” and implying that Linux must be more than a kernel. You can avoid the possibility of this misunderstanding by saying or writing “the kernel, Linux” or “Linux, the kernel.”

>> No.64120281

so basically what is going to happen is something like this:
>new kernel version is released, it cucks all x86 vendors by default
>everyone and their dog does emergency updates, ie. vm hosts
>the patch which restores AMD performance is merged
>no one cares to upgrade, so even though the upstream kernel doesn't slow down AMD anymore, the industry stays at the previous version because it's a pita to upgrade all the hosts one more time
save this post

>> No.64120310

>>64120281
Next intel vulnerability soon I hope, then

>> No.64120314

>>64120256
Never considered this.

>Linux, the kernel.
This has the same problem, though. Like Star Wars, the movie (instead of the book, or game). or Brooklyn, the bridge.

>> No.64120400

>>64120281
>>64120310
KYS

>> No.64120412

>>64120256
>>64120314
The kernel known as "Linux"

>> No.64120424

>>64119211
Intel is one of the largest contributors to Linux, and therefore has a lot of influence and decision power over the project.

>> No.64120426

>>64120412
Or, you know, just by its name: Linux.

>> No.64120472

Stop arguing about semantics on core of Linus.

>> No.64120483
File: 63 KB, 187x232, Bildschirmfoto-7.png [View same] [iqdb] [saucenao] [google] [report]
64120483

>>64120426
I'd just like to interject for moment. What you're refering to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.
Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called Linux, and many of its users are not aware that it is basically the GNU system, developed by the GNU Project.
There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called Linux distributions are really distributions of GNU/Linux!

>> No.64120546

>>64120483
Retard

>> No.64120558

>>64120546
newfag

>> No.64120560

>>64120483
No, I was specifically referring to the kernel but you just wanted to paste this pasta instead of reading the conversation. Thanks, fag.

>> No.64120561

>>64119390
Pretty sure Amazon doesn't use Amd CPUs at all for aws

>> No.64120567

>>64120472
Linus is a colonel.

>> No.64120569

>>64120558
He probably means he incorrectly applied this meme.

>> No.64120576

Reminder.
https://itsfoss.com/linux-foundation-head-uses-macos/

>> No.64120588

>>64120483
Maximo Autismo HD.

>> No.64120601

>>64120567
Actually he's a Second Lieutenant.

>> No.64120602

>>64120576
Not-fake and gay

>> No.64120608

>>64120588
Well, if he was an autist he would've actually understood the context and NOT post this meme. This was just a dump kid triggered by the word Linux.

>> No.64120622

>>64120576

>itsfoss

wait for it...

>.com

AHAHAHHAHHAHAHHA

>> No.64120634

>>64119239
>Wojak as a nu-male programmer displaying a typical nu-male camera expression.
Relevant

>> No.64120639

>>64120608
I was talking about Stallman, you fuckard. He's maximo autismo, as he actually said that shit. It's not a "le memey" as it's almost a direct quote of things actually said.

>> No.64120648

>>64120576
Delet

>> No.64120656
File: 26 KB, 187x232, gnuplus.png [View same] [iqdb] [saucenao] [google] [report]
64120656

>>64120608
>Linux
What you're refering to as...I've recently taken to calling it...are really distributions of GNU/Linux!

>> No.64120657

>>64120639
you can tell who's a crossboarder when they confuse copypasta with meme

>> No.64120686

>>64120657
>meme (mēm)
>A unit of cultural information, such as a cultural practice or idea, that is transmitted verbally or by repeated action from one mind to another.

Not him, but how is this not the same as copy-pasta?

>> No.64120688
File: 126 KB, 1024x768, 1505447843371.jpg [View same] [iqdb] [saucenao] [google] [report]
64120688

>>64120576
I always thought windows was more their cup of tea.

>> No.64120703

>>64120686
> Not him, but
Found the reddior

>> No.64120707

>>64120210

I don't think OpenBSD maps kernel memory in the process in the first place.

FreeBSD does, I think.

>> No.64120719

>>64120686
you can't be this dense

>> No.64120721

>>64119134
This sums up linux perfectly. Being gimped because some autist feels like it.

>> No.64120730

>>64120721
OPENSUSE WON'T HAVE THIS PROBLEM
EAT SHIT LINUS

>> No.64120737

>still using linux in 2018
it's like you want to eat shit

>> No.64120752

>>64120730
BIG SUSE

>> No.64120779

>>64120703
Nice way to dodge the point, double nigger.

>> No.64120826

>>64119154
Windows had had it since November.

>> No.64120838

>>64120826
No they don't. The patch isn't out yet.

>> No.64120867

>>64120826
We would've noticed immediately if they did because the gaymen manchildren on /g/ would go batshit insane over the performance loss.

>> No.64121084

>>64120867
actually there have been some tests done and this probably doesn't affect gaming performance, so only the gentoo compiling manchildren will suffer

>> No.64121092

>>64121084
>only the gentoo compiling manchildren
>being this stupid when even Windows is getting a patch

>> No.64121113

>>64121084
Gentoo compiling manchildren probably have AMD cpus and of course won't use the kernel with this option enabled. I wouldn't be surprised if they don't apply this patch at all and even save that 1% or 2% performance.

>> No.64121130

>>64120622
>Remember that time when literally a couple months before DotCom happened Linux actually was establishing itself as a business?

>> No.64121144

>>64121084
>probably doesn't affect gaming performance
I read a spicy article that rumored Nvidia drivers using an awful lot of syscalls being heavily affected by this patch.

>Intel fucks up and AMD ryses* to the top.
>Nvidia is critically struck by collateral damage going down as well.
My body is ready.


*pun intended

>> No.64121160

>>64121130
In that time I was a teenager and Windows 95 was life.

>> No.64121185

>>64119134
feels good the be on a pre performance drop patch kernel

>> No.64121192

>>64121144
Gaymen syscalls are done by DefectX. GayForce is a very heavily DefectX-reliant GayPoo, that's why. AMD, however, has it's own pipeline and makes syscalls directly by itself, with no DefectX. And a daily reminder that Vulkan was based on Mantle, AMD's technology. This is why DefectX 12 going to be DED soon, and Vulkan is the future.

>> No.64121199

>>64121092
>being this stupid
what was stupid about my post? this patch will most likely not make a difference for most if not all programs that aren't used in servers and games.
>even Windows is getting a patch
>even the most used OS in the world is gonna get a patch
wow that was unexpected
>>64121144
i would love to see nvidia getting pwned by this patch, but i think they will just move their asses and fix the drivers

>> No.64121201

>>64119211
its mostly owned by big companies now. they do most commits and give them money and hardware.

>> No.64121208

>>64119134
no one has talked about it here yet but how did the bsd peoples react to this?

>> No.64121226

>>64121208

--> >>64120000. Check 'em.

>> No.64121297

>>64121199
>they will just move their asses and fix the drivers
This part may be a bit less trivial than you might think. Especially if the drivers serve a hardware architecture that's set in stone (or silicon, if you like).

>> No.64121313

>>64121297
>if the drivers serve a hardware architecture that's set in stone
in that case they're as fucked as intel

>> No.64121367

>>64119134
so much for the "open source" community LOL

intel has a bug that will probably shit their perfomance? BRING AMD DOWN AS WELL

that logic is literally /g/ tier

>> No.64121393

Reminding me the time when Linus&co refused to accept fuckhuge gpu patch from amd(was it drm?), because of muh code standards, but couple of months prior he gladly accepted patch from qualcomm for their new socs, which literally broke kernel's ability to compile under certain circumstances. Really shows how (((free))) and (((open))) linux.

>> No.64121401

>>64119134
>have AMD CPU
>just updated to Linux 4.14.10 a couple days ago
No fucks given, I probably won't need to update the kernel again until Ubuntu 18.04 hits, and hopefully everything will be settled by then.

>> No.64121410
File: 45 KB, 635x600, TmSdS.jpg [View same] [iqdb] [saucenao] [google] [report]
64121410

>>64121367
>intel has a bug that will probably shit their perfomance? BRING AMD DOWN AS WELL
pic related

>> No.64121425

>>64121367
>I can't even FOSS.
Yeah, because if one (1) party decides to gimp AMD must mean NOBODY can decide not to implement it this way. You probably don't know this but many distros don't even run the vanilla kernel. They tweak it for security/performance reasons. It's pretty much guaranteed that a distro will stand up as "the AMD distro" by exempting AMD cpus from the unneeded performance hit to gain popularity or, for a more established distro, to serve it's AMD users. Also it's pretty trivial to not use all of this this (preliminary) patch yourself by adding a boot flag.

>> No.64121439

>>64121425
you probably dont understand the MESSAGE being sent when the official patch includes this

but go ahead try to minimize it

>> No.64121443

>>64119970
When does the embargo end?

>> No.64121459

>>64121443
See >>64119828.

>> No.64121565

>>64121443
No idea but I'd like to know as well. To bad the one replying to you probably replied to the wrong post since there's no answer in the chain.

>> No.64121618
File: 31 KB, 600x430, serveimage (62).jpg [View same] [iqdb] [saucenao] [google] [report]
64121618

>>64121425
>a distro will stand up as "the AMD distro"
it's called pic related

>> No.64121635

>>64121439
You're probably a retard who doesn't understand meritocracy anyway.

Intel is a huge contributor to Linux, and therefore have a big say in the project. If that harms a tiny irrelevant minority of PC users who use fringe hardware made by an obscure vendor, that's a minute price to pay for their massive collaboration.

>> No.64121657

>>64121618
That's a pretty big name. Didn't expect that. This is why the Linux kernel as FOSS will be just fine despite whatever you may think of the official devs.

>> No.64121667

>>64121635
You still have stocks to sell, Brian.

>> No.64121689

>>64121635
>Intel is a huge contributor to Linux, and therefore have a big say in the project
61% now. 61% drop in performance. Enjoy your rope hanging, Linus. Yiff in hell.

>> No.64121731
File: 31 KB, 332x500, book.jpg [View same] [iqdb] [saucenao] [google] [report]
64121731

>>64121635
Meritocracy is a bad thing though.

>> No.64121745

this is BS about "oh it's just a switch". the nopti (no PTI) kernel option does not disable all of this crap for AMD cpus. see twitter.com/grsecurity and ctrl-f for "nopti". I want to see intel burn.

>> No.64121747

>>64119134
Linux Foundation + Linus Techtips + Intel = CIA

>> No.64121782

>>64119509
Why are amdtards illiterate paranoid overly sensitive imbeciles?
kill yourself
seriously

>> No.64121808

>>64121782
>t. butt blasted Intel owner

>> No.64121818
File: 162 KB, 633x900, ffffffvey.png [View same] [iqdb] [saucenao] [google] [report]
64121818

>>64121782

>> No.64121833

>>64121808
see
>>64119536
kys

>> No.64121862

>>64119134
what the fuck is going on?
The right fucking time for me to buy a gaming pc

>> No.64121876

Wait, so does this make it 30% slower overall or only in specific situations?

>> No.64121905

>>64121876
Overall, as it affects syscalls (literally 99.99% software runs out there). Also - it's not 30% anymore, it's 61% on Intel.

>> No.64121918

>>64121862
>The right fucking time for me to buy a gaming pc

If you haven't already then yes! Now you can go AMD!

>> No.64121925

>>64121905
o fuk

>> No.64121966

>>64121635
so back to my original point

the so called open source its not really OPEN

>> No.64121990

>>64121966
Linux is not open source. It's free software. There's a difference, you faggot.
https://www.gnu.org/philosophy/open-source-misses-the-point.html

>> No.64122001
File: 162 KB, 1000x1000, 1413913323099.png [View same] [iqdb] [saucenao] [google] [report]
64122001

>>64119134
Linux is for cucks anyways

>> No.64122060

Anyway, what Intel says about all this bullshit?

>> No.64122092
File: 971 KB, 484x682, JewFail.png [View same] [iqdb] [saucenao] [google] [report]
64122092

>>64122060

>> No.64122101
File: 150 KB, 1083x1200, DSkyq4HUQAAdaE2.jpg [View same] [iqdb] [saucenao] [google] [report]
64122101

>>64122060
Sold stocks 1 month ago as soon as the news hit there

>> No.64122143
File: 476 KB, 3264x2448, 1514504326564.jpg [View same] [iqdb] [saucenao] [google] [report]
64122143

>>64120004
prove us wrong then fag

>> No.64122155
File: 659 KB, 1640x686, web-Main[2].jpg [View same] [iqdb] [saucenao] [google] [report]
64122155

>>64119134

It's about gimping bitcoin etc not about AMD or Intel

>> No.64122160

>>64120210
>drop i386 and amd64 support.
AMD64 is original AMD ISA, Intel just licenses it, VENDOR_INTEL will be dropped.

>> No.64122198

>>64121618
Glad I am on Opensuse, they already reviewed it, I am willing to bet they will add the patch even if Linus is being bought and paid for by not accepting the AMD patch

>> No.64122239

>>64122155
Yeah, minus 30% will REALLY hurt bitcoin. Never ever did it recover from such a PLUNGE.

>> No.64122240

>>64119252

That doesn't explain why Linux is still forcing it on AMD when it is not required.

>> No.64122248

>>64119839
You either get page table seperation or you don't. There is no half way point.

>> No.64122252

>>64122240
Linux respects the 4 freedoms. You're not forced to do anything.

>> No.64122268

>>64122239
It's 61%, lel.

>> No.64122280

>>64122240
>why
Because even without that patch $1000 epyc was strong contender for $2500 xeon, imagine $1000 epyc being better than $4000 xeon? Intel are scared shitless and Linus can't go against Intel.

>> No.64122282

>>64122252
>You're not forced to do anything
>systemd
>Gnome 3

>> No.64122293

>>64122268
Can you link me? I heard 30% to be exaggerated already. 61% sounds like a whole new level of kek to me.

>> No.64122298

What are the chances that Linus is sucking intel dick?

>> No.64122312

>>64122282
>systemd
>Gnome 3
Thanks for a list of software that only needs to be installed because the user wishes to.

>> No.64122318

>>64122252
depends on your distro. binary distros make it harder to customize your shit but something like gentoo lets you do what you want.

>> No.64122325

>>64122298
I'd say 82.48%.

>>64122312
>Even Linus was forced to use Gnome 3 eventually

>> No.64122334

>>64122312
its installed by default in most distros and removing it will break your system. package managers were a mistake.

>> No.64122359

>>64122298
About 13.1%

source: https://go.pardot.com/l/6342/2017-10-24/3xr3f2/6342/188781/Publication_LinuxKernelReport_2017.pdf (page 14)

>> No.64122368

hey /g/ nerds. how do i install the security patch on kubuntu right now?

>> No.64122376
File: 971 KB, 484x682, Inturd.png [View same] [iqdb] [saucenao] [google] [report]
64122376

>>64122359
>2017-10-24

>> No.64122410

>>64122368
sudo shred -n 1 -v /dev/sda

>> No.64122419
File: 7 KB, 250x240, 1510497111086s.jpg [View same] [iqdb] [saucenao] [google] [report]
64122419

>>64122410
hilarious

>> No.64122440

>>64122334
>removing it will break your system. package managers were a mistake.

No, that's the distro's fault for retarded packaging. Lots of that software have optional systemd features and could run in an OS without it. Because some distros create an unneeded hard dependency for systemd your package manager uninstalls a bit more then you'd expect (the whole fukken DE for example).

Devuan is a nice example how Debian can work nicely without systemd with just some sane repackaging.

>> No.64122445

>>64122368
Don't do below, will delete your system

>>64122410

>> No.64122455

>>64122376
Well, it's not published yesterday but that percentage will not be very different today, fa.m

>> No.64122464

>>64122445
Just because I'm not a /g/ nerd, it doesn't mean that I'm retarded.

>> No.64122469

>>64122280

Might as well go back to windows if even Linux has turned into a botnet. GG.

>> No.64122481

>>64119375
>in this sjw world we live in nowadays, we don't clap for the chap that can run faster but brake his ankle so everyone gets the medal for crossing the finish line at the same time
got damt harrison bergeron dystopia!

>> No.64122507
File: 68 KB, 633x758, 1429824948319.jpg [View same] [iqdb] [saucenao] [google] [report]
64122507

>>64119252
muh closed source...look at me I use Linux...everything is broken

90% of people use windows..but I knnoww better...

>> No.64122525

>>64122469
the botnet is in your hardware. os does not matter anymore.

>> No.64122566

>>64122410
Luckily "shred" is a bit self-explanatory about its purpose.

>> No.64122576

have there ever been redacted comments in the linux source before

https://twitter.com/grsecurity/status/947147105684123649

this is hilarious

>> No.64122585

>>64122507
GNU/Linux*

>> No.64122590

>>64122507
Cry more cuck : ^ )

>> No.64122602

>>64122576
i know there are misspellings, it's a bit of a hodge-podge

>> No.64122604

>>64122507
>I'm brainlet, the post.
Good.

>> No.64122651

>>64122469
Linux has been botnet since 1993. Its funny that freetards call anything botnet while running proprietary blobs themselves.

>> No.64122684

>>64122651
> connecting linux with freetards
Here's the error.

>> No.64122692

>>64119348

5% is not 35% senpai

>> No.64122749

>>64122651
GNU Linux-libre does not have this problem.

>> No.64122882

>>64122692
Surely it's not 61% either.

>> No.64122923

>>64122882
54% reduction in speed on NVMe disks for the i7-8700k was already confirmed by Phonorix

>> No.64122959
File: 8 KB, 248x233, smug.jpg [View same] [iqdb] [saucenao] [google] [report]
64122959

>>64119134

>tfw was beginning to think I made a mistake buying a R5 1600x rather than wait for Coffelake

Feels good man.

>> No.64123126

>>64122923
It's 61% purely only on Intel.

>> No.64123214

>>64122368
>right now
You'd have to get the kernel source and the patch and compile it, then make your system use it. Just be lazy and wait for kubuntu to patch linux themselves and provide you the update during a normal system update.

>> No.64123269

>>64123126
*sigh* link? I see this 61% a lot but never seen a source.

>> No.64123349

>>64119820
Cause the CPU still has to check that kernel instruction every operation. The AMD flag check just let's it bypass the rest of it, so the performance is only nicked a bit.

>> No.64123508

>>64122334
install void linux or gentoo

>> No.64123566

>>64119509
>hurr durr using the benefits of open source is defending the indefensible
wincucks are truly max cuckold

>> No.64123588

4.14.11 includes the PTI patch, but applied to all processors. Therefore AMD is being hit with the same performance hit.

Why have they not included the patch even though it has been reviewed and confirmed as OK?

>> No.64123611

>>64122293
grsecurity had instances of a 67% performance drop from pre-patch normal, especially when the program it's fetching data on is on a NVME SSD.

>> No.64123740

>>64123611
Thanks!

>> No.64123855

>>64123588
Maybe 4.14.12 will be the one? If you're AMD, just don't upgrade.

>> No.64123890

>>64123855
https://github.com/torvalds/linux/blob/5aa90a84589282b87666f92b6c3c917c8080a9bf/arch/x86/include/asm/processor.h#L864
/*
* User space process size. This is the first address outside the user range.
* There are a few constraints that determine this:
*
* 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.
*
* With page table isolation enabled, we map the LDT in ... [stay tuned]
*/

>> No.64123984

>>64123890
>RyZen family
So not EPYC and not Threadripper. Server crowd will be massively pleased, then. And as for mainstream segment, which uses RyZen, they won't care as they don't use RyZen for the tasks mentioned, so they won't encounter any problems.

Either way, Linus was confirmed for being a bribed Inturd shiller.

>> No.64124089

>>64123984
Epyc and threadripper are based on the same core. So it is affected.

>>64123890
This is a different bug

>> No.64124175

>>64124089
>Epyc and threadripper are based on the same core
Are you a newfag? RyZen is Ryzen, Threadripper is cut EPYC, and EPYC is Zeppelin.

>> No.64124185

>>64123890

Canonical ubuntu btfo

:^)

>> No.64124222

>>64119134
This shows, x86_64 architecture is past, and for looking at homosexual porn, ARM is enought, other computation are done by shady corporations, which you just don't get to use your code anyway.

>> No.64124247

Also, to be vulnerable to this bug, you need to run something, that runs...

That's why PHP Balls was better choice for delivering application, thus you cannot do syscall on it, but GTFO you nonlistening shit.

>> No.64124267

>>64119134
It is time to fork a Linux.
Ginux, /g/ edition of botnet-free Linux kernel.

>> No.64124295

>>64124175
And what is the core? All zen.

>> No.64124303

>>64124267
https://fsfla.org/svnwiki/selibre/linux-libre/index.en.html

>> No.64124455

>>64119228
You can request a new processor from AMD.

>> No.64124612

>>64119134
Wow, what a shitty article. The AMD patch was not overwritten, they just merged previous patches first.

>> No.64124818
File: 112 KB, 691x771, 1499963016439.jpg [View same] [iqdb] [saucenao] [google] [report]
64124818

>>64124612

>> No.64124833

>>64119134
>>AMD is immune to the VT flaw
If they was certainty of it they would accept the patch.
It's still labelled as insecure therefore AMD gets hit too

>> No.64124916

>>64124833
>If they was
See >>64119645. Very structure of Zen architecture doesn't allow such inane holes in security. It's literally flawless. Unlike pooducts of those blue FUCKWITs.

>> No.64124960

>>64124916
>A commercial proves that something is impervious to a bug discovered a month ago
Kill yourself my man

>> No.64124999

>>64124960
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.

>> No.64125013

>>64124833
>>64124916
>>64124999

Look like ryzen has a different bug that is worked around by the same patch
>>64123890

The one gets rammed in ass is Bulldozer again, it dindu nuffin

>> No.64125035
File: 277 KB, 1053x1497, SmartSelectImage_2018-01-03-10-17-17.png [View same] [iqdb] [saucenao] [google] [report]
64125035

>amd is such shit
>Intel handicapped and still beats amd

>> No.64125062

>>64125035
Micron better than intel confirmed!!!!!!!!!!!!!!!!!111!!!!!!!!!

>> No.64125086

>>64124818
How was my post an Intel shill? I'm clearly saying that the patch excluding AMD from PTI can still be merged.

>> No.64125117
File: 944 KB, 1228x1502, IFHFASGFM.png [View same] [iqdb] [saucenao] [google] [report]
64125117

>>64124960
>>64125013
>>64125035

>> No.64125149

Anyone know the flag to disable the patch. 4.14.11 makes booting and opening apps slow. I want to benchmark it. I am open to IO benchmark program suggestions.

>> No.64125152

>>64123890
This is a different bug, look at the diff and you will see that the comment was there before the whole PTI stuff, now they just extended it to Ryzen and added some code for handling PTI.

>> No.64125209

>>64119134
Good, it's only fair if everyone gets it

>> No.64125399

>>64125152
Different bug but it's merged by the same commit from branch
https://github.com/torvalds/linux/commit/5aa90a84

From the patchwork
https://patchwork.kernel.org/patch/10104281/

>Dec. 11, 2017
Looks like it's patched during the same PTI stuff.

>> No.64125451

Just benchmarked.

Intel® Core™ i3-4005U CPU @ 1.70GHz × 4

Linux: 4.14.11-041411-generic

nopti: boot time 137 seconds
pti: boot time 95 seconds

nopti:

successful run completed in 60.52s (1 min, 0.52 secs)
stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
(secs) (secs) (secs) (real time) (usr+sys time)
cpu 21321 60.15 236.62 0.15 354.46 90.05
cpu:
379.972.649.584 CPU Cycles 6,28 B/sec
446.048.775.672 Instructions 7,37 B/sec (1,174 instr. per cycle)
1.592.473.856 Cache References 26,31 M/sec
11.536.520 Cache Misses 0,19 M/sec ( 0,72%)
82.844.588.008 Branch Instructions 1,37 B/sec
433.371.424 Branch Misses 7,16 M/sec ( 0,52%)
23.750.243.580 Bus Cycles 0,39 B/sec
403.750.523.920 Total Cycles 6,67 B/sec


pti:

successful run completed in 60.59s (1 min, 0.59 secs)
stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
(secs) (secs) (secs) (real time) (usr+sys time)
cpu 20970 60.21 234.21 0.19 348.27 89.46
cpu:
375.704.108.204 CPU Cycles 6,20 B/sec
438.968.880.784 Instructions 7,25 B/sec (1,168 instr. per cycle)
1.399.870.452 Cache References 23,11 M/sec
19.394.300 Cache Misses 0,32 M/sec ( 1,39%)
81.570.494.916 Branch Instructions 1,35 B/sec
413.375.336 Branch Misses 6,82 M/sec ( 0,51%)
23.484.139.756 Bus Cycles 0,39 B/sec
399.226.479.212 Total Cycles 6,59 B/sec

>> No.64125497

>>64125451
nopti still have some performance penalty. If you can revert to a previous kernel and run test again?

>> No.64125499
File: 4 KB, 300x57, 1497630852667.jpg [View same] [iqdb] [saucenao] [google] [report]
64125499

>>64125451
boot thing is accidentally reversed.

PTI boot is 137 seconds.

I also benchmarked with cryptsetup sha. Almost difference.

>> No.64125635
File: 422 KB, 672x794, 052.png [View same] [iqdb] [saucenao] [google] [report]
64125635

>>64125209

>> No.64125643

>>64125399
Exclusion patch suggested by AMD engineer was merged in a WIP branch

https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip/tip/+/694d99d

https://patchwork.kernel.org/patch/10133447/

I would say they will merge to release after disclosure.
>... [stay tuned]

>> No.64125746
File: 154 KB, 600x600, 179.png [View same] [iqdb] [saucenao] [google] [report]
64125746

>>64122248

>> No.64125754

>>64119467
>if intel_genuine use fast_path
>if not intel_genuine use slow path


this nothing new to (((them)))

>> No.64125776

>>64125643
>if (c->x86_vendor != X86_VENDOR_AMD)
Why does nobody care about VIA?

>> No.64125779

>>64119475
you can disable it, but it comes enabled by default

>> No.64125843

what's going on? will my sandy bridge be effected?

>> No.64125857

>>64125776
Because NOT YET. Let for Intel to fall off and fucking die first, then AMD becomes new Intel and VIA becomes new AMD. There's also Loongson, Qualcomm, Nvidia, Huawei and ARM coming up. Intel's one-polar dominance is coming to an end.

>> No.64125880

>>64125497
4.14.10

boot time 93 seconds

sysbench
CPU speed:
events per second: 460.33

General statistics:
total time: 10.0006s
total number of events: 4605


Threads fairness:
events (avg/stddev): 4605.0000/0.00
execution time (avg/stddev): 9.9976/0.00


successful run completed in 60.45s (1 min, 0.45 secs)
stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
(secs) (secs) (secs) (real time) (usr+sys time)
cpu 21291 60.13 236.60 0.14 354.08 89.93
cpu:
374.872.339.096 CPU Cycles 6,20 B/sec
439.679.696.268 Instructions 7,27 B/sec (1,173 instr. per cycle)
1.397.802.984 Cache References 23,12 M/sec
18.394.176 Cache Misses 0,30 M/sec ( 1,32%)
81.503.498.788 Branch Instructions 1,35 B/sec
409.405.768 Branch Misses 6,77 M/sec ( 0,50%)
23.431.702.468 Bus Cycles 0,39 B/sec
398.334.924.432 Total Cycles 6,59 B/sec


4.14.11 nopti

CPU speed:
events per second: 460.52

General statistics:
total time: 10.0008s
total number of events: 4607


Threads fairness:
events (avg/stddev): 4607.0000/0.00
execution time (avg/stddev): 9.9977/0.00

>> No.64125886

>>64125857
Also forgot to add Russian MCST and their Elbrus. Literal good guys right now.

>> No.64125941

>>64125880
Looks about right, they talked about ~2-5% hit for nopti

>> No.64125977

>>64125880
fuck. Ignore 4.14.10 benchmarks. I forgot to chose 4.14.10 so grub defaulted to 4.14.11 pti. Take it that way. I am retired I guess.

>> No.64126025

>>64119839
it's a flag. it disables it.

>> No.64126071

>Fedora rawhide released a PTI enabled kernel (4.15.0-0.rc6.git0.1.fc28.x86_64). I did some test with it. Syscalls are much slower with PTI enabled.

>bench_03_getpid_vdso 2.7x slower
>bench_11_read_vdso 2.0x slower
>bench_21_write_vdso 2.3x slower

> ((("only 30% slower")))

>> No.64126084
File: 2.12 MB, 200x180, 1488940391261.gif [View same] [iqdb] [saucenao] [google] [report]
64126084

OP here.
We won, mateys.
We fucking won.
Linus and Stallman gave up.
AMD's going to be freed from it's custody and Intel's fucked big-time now, as Intel won't be cut any slack on this. Literally best timeline to be alive. Intel's stock going under 20$ in a couple days now, just watch.

>> No.64126118

>>64126025
https://twitter.com/grsecurity/status/947260475305213953

>Even with 'nopti' on the kernel commandline, you'd be paying the cost of switching between a second kernel stack on each syscall, etc

>> No.64126144

This is what AMD deserves for not pouring money into diversity programs.

>> No.64126145

>>64125880
wtf what shitty computer takes 90 seconds to boot??? i have a c2d laptop that takes 20 secs

>> No.64126200

>>64126118
>2018
>posting grsecurity shills

>> No.64126208

>>64126145
My c2d boots in 6 seconds. You can't compare CPU with different boxes.

>> No.64126227
File: 103 KB, 639x634, Autistic Screeching.jpg [View same] [iqdb] [saucenao] [google] [report]
64126227

>>64126200

>> No.64126256

>>64125857
>Loongson
Wake me when they get more than 2.0GHz. I would really like to get and use that stuff, but not with the performance being only a small step above your average Raspberry Pi clone.

Although you do make a good point about ARM
https://www.cavium.com/product-thunderx-arm-processors.html

>> No.64126326

>>64119134
Doesn't surprise me much, the kernel has lots of intel shills probably because intel more involved and a bigger contributor money wise than AMD

>> No.64126355

>>64126326
Doesn't matter now. We've already won. Linus going to free AMD from the cell. Intel, however, is fucked.

>> No.64126478

>>64123890
Is that segfault bug on early ryzens, no?

>> No.64126556

>>64126478
The Early ryzen segfault bug was a crash on extremely specific workloads that was patchable with no performance hit.
This intel one is a category 10/10 security flaw of the most extreme kind to exist (it could only be worse if it was arbitrary read AND write) that affects every processor made in the last 10 years and patching it causes a performance hit. A severe hit in server type workloads

>> No.64126582

>>64126478
Looks like it? Same "canonical page" referenced

>Matt Dillon paraphrasing AMD’s comments on the Ryzen DragonFlyBSD workaround commit:
>"Ryzen has an issue when the instruction pre-fetcher crosses from canonical to non-canonical address space. […] AMD validated the bug and determined that unmapping the boundary page completely solves the issue."
http://lists.dragonflybsd.org/pipermail/commits/2017-August/626190.html8

>> No.64126641

>>64126478
Segfault was fixed long time ago. Zen is literally flawless, fucking perfect for compiling and other Linux shit now.

>> No.64126668

Looks like many datacenters will have to upgrade to EPYC ahead of schedule :^)

>> No.64126680

>>64126641
Well, that's the point. It seems like those fucktards using those early ryzens bug for justifying crippling performance on every amd cpu.

>> No.64126681
File: 999 KB, 2000x1333, Lisa-Su-AMD-MIT-00_0.jpg [View same] [iqdb] [saucenao] [google] [report]
64126681

>>64126668
>t.

>> No.64126688

>>64126478
>>64126582
Yes, they both had the issue and both were fixed in the same way.

>> No.64126705

>>64126668
Even mid-tier Threadripper 1920X on stock clocks will be more effective in servers than Golden Zionist Inturd OverClocked to nuclear temps now, lol.

>> No.64126720

>>64126641
>Segfault was fixed long time ago.
It was fixed in Dragonflybsd, I don't recall a fix for linux before this. AMD said we fixed hw in new batches if you hit the bug we'll send you a new CPU.

>> No.64126743

>>64126681
http://www.youtube.com/watch?v=SPSlj-OGjFI

>> No.64126759

>>64119154
you have to turn off the feature manually by commenting out a few lines of code.

>> No.64126803

>>64126668
>replacing x86 with more x86
you are doing it wrong, anon.
https://blog.cloudflare.com/arm-takes-wing/

>> No.64126819
File: 17 KB, 400x400, 1488482796138.png [View same] [iqdb] [saucenao] [google] [report]
64126819

>>64126803
>irrelevant ARM memery from not a Super Seven Plus One member
Ayy.

>> No.64126831

>>64126803
>FUTURE
>28NM
Yeh nah

>> No.64126847

>>64126831
Centriq is 10LPE though.

>> No.64126859

>>64126831
huh? centriq is the first 10nm cpu.

>> No.64126891

>>64126859
It's the first "10nm" server SoC, but definitely not *the* first one.

>> No.64126925

>>64119134
>FOSS community
The POZZ community

>> No.64126999
File: 518 KB, 2416x1265, Cavium-ThunderX-2-in-Microsoft-OCP-Project-Olympus-Server.jpg [View same] [iqdb] [saucenao] [google] [report]
64126999

>>64126803
I wouldn't mind ARM servers taking off since k12 might see the light of day then

>> No.64127026

>>64126831
Thunder X2 is 14nm

>> No.64127510
File: 3.49 MB, 4667x3106, 6-JIDCnZG2E.jpg [View same] [iqdb] [saucenao] [google] [report]
64127510

>> No.64127589

Just because AMD isn't effected doesn't mean this isn't a security enhancement. Based Linus

>> No.64127662

>>64127510
Tanks, shaved. The Red bird is free now. See here >>64126084.

>> No.64127932

>>64122248
TJ """"""""""""""""Henry """"""""""""""""" Yoshi

>> No.64128002

>>64119218
If there is no issue with AMD, admins could just not update their kernels.

>> No.64128085

>>64128002
That wasn't the point, though. It happened literally only because Linus and Stallman wasn't expecting such events at all and got massively butthurt because they're Inturd shillers. But under massive pressure from outside world they've gave up. Especially after thoroughly inspecting AMD and not finding even one slightest flaw. Absolute perfection which they absolutely couldn't deny. So, therefore, AMD was freed. And Inturd is fucked.

>> No.64128126

>>64128002
In addition, if any distributions think AMD shops will take this lying down, they've got another thing coming.

>Hey, this bug doesn't affect your hardware, but take this performance hit anyway because Intel paid us.
>Suck my dick, bitch. Come up with a workaround, or I will go somewhere else.

>> No.64128216

>>64128085
I highly doubt Stallman supports Intel at all. Even if Linus is in Intel's pocket, smart distributions will come up with workarounds for AMD because they want to keep their money.

>> No.64128248

>>64128216
>I highly doubt Stallman supports Intel at all
He's not, but he's together in with Linus on this, hence automatically a buttblasted Inturd shill. An accomplice.

>> No.64128262
File: 350 KB, 672x794, 1514985526248.png [View same] [iqdb] [saucenao] [google] [report]
64128262

https://www.phoronix.com/scan.php?page=news_item&px=Linux-Tip-Git-Disable-x86-PTI
fuck off OP and intelcucks

>> No.64128272

>>64128216
>smart distributions will come up with workarounds for AMD
No need to now, as Linus gave up and will set AMD free. The ransom attempt didn't work out jack shit for him.

>> No.64128293

>>64119134
Fork the kernel

>> No.64128319

>>64128262
>PTI was intended to isolate kernel from user space. But thanks to zen's design it does seem like it is a non issue. Zen fixes the issue that was the sole motivation of PTI and renders it obsolete and unnecessary. There is absolutely no good reason to enable PTI on zen chips.

>> No.64128403

>>64128085
>Stallman
>Inturd shiller

>> No.64128434

>>64128403
Stallman -> Linus' fuckbuddy = accomplice at being a shiller

>> No.64128684

>>64124999
>Research has confirmed the bug is an issue with the processors architecture and so cannot be fixed simply with a bios update.
what "research" are you citing? this whole thing became public knowledge yesterday. there has been no research. we only know what Intel said in a press release. This going to change the way CPU architecture is audited from now on. if anyone's looking for a thesis project, this is it.

>> No.64128737

>>64128085
so you're implying that a couple of, albeit, pretty good programmers are experts on CPU architecture to such a degree that they are competent in auditing 50 years worth of development by 2 massive corporations worth of people, funded by trillions of dollars, equating to millions of man-hours of work, all in just a few weeks?

>> No.64128763
File: 98 KB, 397x295, 14958027442730.jpg [View same] [iqdb] [saucenao] [google] [report]
64128763

>>64128737

>> No.64128793

>>64120126
Well, honestly, it would be quite stupid to not at least pretend all brands were affected because it would make it easier to determine what bug they are going after. I think you could consider this their "poker face" until they know for certain that they have fixed things with the Intels.

>> No.64129108

>>64121192
underage b&

>> No.64129221
File: 1.12 MB, 500x584, 6r7u56tg5756867.png [View same] [iqdb] [saucenao] [google] [report]
64129221

>>64129108

>>
Name (leave empty)
Comment (leave empty)
Name
E-mail
Subject
Comment
Password [?]Password used for file deletion.
Captcha
Action