Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Meltdown/Spectre: Unauthorized Disclosure of Kernel Memory
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 9, 10, 11 ... 21, 22, 23  Next  
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
tholin
Apprentice
Apprentice


Joined: 04 Oct 2008
Posts: 176

PostPosted: Mon Jan 08, 2018 2:11 pm    Post subject: Reply with quote

Naib wrote:
NeddySeagoon wrote:
That will be another
Code:
emerge -e @world
when the new gcc is out.
Will it? or will it just be the kernel? I would have thought it would just be the kernel that needs to be rebuild with the new speculative branching mitigation (ie poisoning it)

Here is the way I see it, and I could be totally wrong. The information is spread over a lot of sites and patches.

To mitigate variant 2 you need to either recompile everything without indirect branches (retpolines solution) or update your kernel so it will flush the branch predictor on each context switch. Branch predictor flushing requires updated microcode. The needed microcode might be released but the upstream kernel support is not ready yet. Redhat and possible other vendors have rushed out patches already.

Retpolines doesn't work on recent intel cpus like Skylake so the only solution there is microcode. Intel said they released microcode update for cpus released within the last 5 year but what about older cpus? Unless there is a microcode update the only solution is retpolines afaik. Unfortunately rebuilding everything really means everything including the UEFI code. An attacker could play around with the branch predictor and then do something that causes UEFI to run. Since UEFI has access to all memory that could still leak everything.

Booting in legacy mode does not prevent UEFI from running but it might make it more difficult for an attacker to selectively run UEFI code. I'm not sure about that. Something else I'm not sure about is if the operating system can always guarantee that the branch predictor will be flushed before firmware code is run. When the operating system makes UEFI calls it can flush the branch predictor before but UEFI can also run because of obscure hardware interrupts. In that case you would need an update to the bios, not just microcode.

In any case the variant 2 is difficult to exploit. The attacker needs know the layout and some content of the address space it wants to attack. As gentoo users we are lucky because the code we run is mostly unique to our systems. The firmware code is something an attacker could easily get from the vendors website but the attacker would have to create a separate exploit for each mobo/bios version combo. That's a lot of work so I don't think most home users have a lot to fear from variant 2 if the retpolines workaround is used alone. In the future the attack might be improved so I can't tell how long this will be true.
Back to top
View user's profile Send private message
PrSo
Tux's lil' helper
Tux's lil' helper


Joined: 01 Jun 2017
Posts: 129

PostPosted: Mon Jan 08, 2018 3:09 pm    Post subject: Reply with quote

Ant P. wrote:

I wonder if that's a side effect of Gentoo kernels not compiling in thousands of useless drivers. Maybe we're fine there.


Please correct me if I am wrong, but with assumption that the kernel is crafted to my needs, and in accordance to:

- that the alternative to "legit retpoline" and "IBRS" on AMD cpu - "lfence" solution could be used:
https://lkml.org/lkml/2018/1/4/742;

- and migration in MSR was not fully implemented yet:
https://patchwork.kernel.org/patch/10146709/;

- PoC executed on my netbook says that its vulnerable to Spectre:
https://github.com/Eugnis/spectre-attack

in this perspective I think that we are not save yet but I wish I was wrong.

My intel NAS is another story touhg...



EDIT:

Above applies to spectre v2.

I have problems with LKML.org and could not read treads earlier.

There is a hot discussion about not to rely on "lfence" solution in resolving Spectre v1 problem on AMD cpu cause of slowdown impact.

https://www.spinics.net/lists/netdev/msg476433.html

I am starting to worry about performance downgrade.


Last edited by PrSo on Mon Jan 08, 2018 9:27 pm; edited 1 time in total
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3194
Location: Illinois, USA

PostPosted: Mon Jan 08, 2018 3:17 pm    Post subject: Reply with quote

It gets worse. Trust Wintel to take advantage:
It gets worse: Microsoft’s Spectre-fixer bricks some AMD PCs
Back to top
View user's profile Send private message
tholin
Apprentice
Apprentice


Joined: 04 Oct 2008
Posts: 176

PostPosted: Mon Jan 08, 2018 3:20 pm    Post subject: Reply with quote

Naib wrote:
krinn wrote:
latest microcode will be mark stable in a few, you can get it there if you don't want wait :
https://gitweb.gentoo.org/repo/gentoo.git/plain/sys-firmware/intel-microcode/intel-microcode-20171117_p20171215-r1.ebuild?id=fe65cc7bc14f41f05bb9c41f7318f280a1a31b5e
Thats not new enough. That is Intels microcode from nov 2017... they have not made avail microcode for spectre ( well maybe to vendors for BIOS updates)

Let's try checking that.
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1578797.html

Assuming what is reported here is correct then "cpuid ax=0x7, return rdx bit 26 to indicate presence of this feature
IA32_SPEC_CTRL ... { X86_FEATURE_SPEC_CTRL, CPUID_EDX, 26, 0x00000007, 0 }"

sys-apps/cpuid can be used to read the cpuid.
Code:

$ dmesg |grep -m 1 microcode
microcode: CPU0 microcode updated early to revision 0x22, date = 2017-01-27
$ cpuid -1r
...
0x00000007 0x00: eax=0x00000000 ebx=0x000027ab ecx=0x00000000 edx=0x00000000
...

So EDX is all zero and the needed feature is not in this microcode. Lets try the new version.
Code:

$ dmesg |grep -m 1 microcode
microcode: CPU0 microcode updated early to revision 0x23, date = 2017-11-20
$ cpuid -1r
...
   0x00000007 0x00: eax=0x00000000 ebx=0x000027ab ecx=0x00000000 edx=0x0c000000
...

EDX is now 0x0c000000 with bit 26 set so the microcode from November appears to have the needed feature at least on my i7-4790K Haswell.
Back to top
View user's profile Send private message
transsib
l33t
l33t


Joined: 26 Jul 2003
Posts: 869

PostPosted: Mon Jan 08, 2018 3:36 pm    Post subject: Reply with quote

Code:
./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.13

Checking vulnerabilities against Linux 4.14.11-gentoo-r2 #2 SMP Sun Jan 7 10:09:37 CET 2018 x86_64

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Kernel compiled with LFENCE opcode inserted at the proper places:  NO  (only 27 opcodes found, should be >= 70)
> STATUS:  VULNERABLE

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO
*   Kernel support for IBRS:  NO
*   IBRS enabled for Kernel space:  NO
*   IBRS enabled for User space:  NO
* Mitigation 2
*   Kernel compiled with retpolines:  NO
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpolines are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES
* PTI enabled and active:  YES
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)


Uh-Hu
Back to top
View user's profile Send private message
Thistled
Guru
Guru


Joined: 06 Jan 2011
Posts: 548
Location: Scotland

PostPosted: Mon Jan 08, 2018 5:57 pm    Post subject: Reply with quote

I'm really confused here, because although Intel say they no longer support my CPU, they are still offering a microcode update from late 2017,
and yet even after applying the update via Portage, I am still on a 2010 microcode update.
??
Intel® Pentium® Processor E5400 (2M Cache, 2.70 GHz, 800 MHz FSB) is in the list.
_________________
Whatever you do, do it properly!
Back to top
View user's profile Send private message
albright
Advocate
Advocate


Joined: 16 Nov 2003
Posts: 2548
Location: Near Toronto

PostPosted: Mon Jan 08, 2018 6:09 pm    Post subject: Reply with quote

I have three intel computers running gentoo with
these cpus:

i7-6700
i5-4300U
i7-6600U

the latter two are thinkpads

Loading the new intel microcode worked on the thinkpads:

for the 4300U:

Code:
dmesg | grep microco
[    0.000000] microcode: microcode updated early to revision 0x21, date = 2017-11-20
[    0.204333] microcode: sig=0x40651, pf=0x40, revision=0x21


for the 6700U:

Code:
dmesg | grep microco
[    0.000000] microcode: microcode updated early to revision 0xc2, date = 2017-11-16
[    0.262780] microcode: sig=0x406e3, pf=0x80, revision=0xc2


these two both show:

Code:
cpuid -1r:
edx=0x0c000000


But the 6700 does not seem to take the update:

Code:
grep microco dmesg
[    0.000000] microcode: microcode updated early to revision 0xba, date = 2017-04-09
[    0.324397] microcode: sig=0x506e3, pf=0x2, revision=0xba


and here:

Code:
cpuid -1r:
edx=0x00000000


Is there something about this chip - it did not get upated microcode, or what?

EDIT: I should add, all running kernel 4.14.12
_________________
.... there is nothing - absolutely nothing - half so much worth
doing as simply messing about with Linux ...
(apologies to Kenneth Graeme)
Back to top
View user's profile Send private message
Thistled
Guru
Guru


Joined: 06 Jan 2011
Posts: 548
Location: Scotland

PostPosted: Mon Jan 08, 2018 7:19 pm    Post subject: Reply with quote

It seems they will be rolling out in batches all the microcode updates.
Seems applicable to all CPUs manufactured in the last 5 years.
The i7-6700 was produced in Q3-2015 so you will get the update sooner or later.
Just today there is another update to the microcode in Portage.
Suppose you just have to keep an eye out for it.
_________________
Whatever you do, do it properly!
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7167

PostPosted: Mon Jan 08, 2018 11:50 pm    Post subject: Reply with quote

albright wrote:
But the 6700 does not seem to take the update:
Code:
grep microco dmesg
[    0.000000] microcode: microcode updated early to revision 0xba, date = 2017-04-09
[    0.324397] microcode: sig=0x506e3, pf=0x2, revision=[color=red]0xba[/color]

and here:

Is there something about this chip - it did not get upated microcode, or what?

Look again more: https://wiki.gentoo.org/wiki/Project:Security/Vulnerabilities/Meltdown_and_Spectre
Quote:
Skylake H/S 000506E3 0xc2

So it mean you use correct microcode for the two other, but as the link show you, the correct one should be 0xc2. Forget to emerge latest one?
Back to top
View user's profile Send private message
albright
Advocate
Advocate


Joined: 16 Nov 2003
Posts: 2548
Location: Near Toronto

PostPosted: Tue Jan 09, 2018 1:08 am    Post subject: Reply with quote

Quote:
eix -I intel-microcode
[I] sys-firmware/intel-microcode
Available versions: 20140430 (~)20140624 (~)20140913 20150121 (~)20150121-r1 20151106 (~)20160607 (~)20160714 20161104 20170511 20170707 (~)20171117 20171117_p20171215 20171117_p20171215-r1 {initramfs monolithic +split-ucode}
Installed versions: 20171117_p20171215-r1(08:36:10 AM 01/08/2018)(split-ucode -initramfs)
Homepage: http://inertiawar.com/microcode/ https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=27337
Description: Intel IA32/IA64 microcode update data


looks like the latest to me ... (I could try the initrd route I guess ...)
_________________
.... there is nothing - absolutely nothing - half so much worth
doing as simply messing about with Linux ...
(apologies to Kenneth Graeme)
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7167

PostPosted: Tue Jan 09, 2018 2:10 am    Post subject: Reply with quote

albright: you are right, the wiki page seems incorrect with 0xc2
Code:
iucode_tool  -l /lib/firmware/intel-ucode/* | grep 506e3
  066/001: sig 0x000506e3, pf_mask 0x36, 2017-04-09, rev 0x00ba, size 98304
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 7236
Location: almost Mile High in the USA

PostPosted: Tue Jan 09, 2018 4:25 am    Post subject: Reply with quote

BTW, in case it's not clear, x86 32-bit currently has no fix. Upgrading to 4.14.12 will not protect from meltdown.

There was a comment about the "4GB/4GB memsplit" doing something to mitigate, alluded to in a twitter comment. I also wonder if PAE does the 4GB/4GB split due to the nature of what is entailed getting PAE to work...

Due to instruction lack (clflush) of the old cpus, it may be harder to exploit this bug. If you have SSE2, then you're still on the hook.

I suspect for those who are running 32-bit and have:

486, p5, p5mmx, atom N-series ... probably safe, carry on
ppro; p2; p3 ... continue the course, harder to exploit due to missing instructions for cache timing exploitation (see if you can run PAE if not already doing so)
p-m (banias, dothan) ... worry more (problems with PAE, might be SOL)
p4 (willamette, northwood)... worry more due to deep pipes (try running PAE)
p4 (prescott)... try to migrate to 64-bit if you can, else try running PAE
Core solo, core duo... try to migrate to 64-bit
atom D,Z-series (silvermont)... Try to migrate to 64-bit!

I don't know if it's valid to run 32-in-64... that would be another interesting situation...
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
fedeliallalinea
Bodhisattva
Bodhisattva


Joined: 08 Mar 2003
Posts: 22325
Location: here

PostPosted: Tue Jan 09, 2018 7:20 am    Post subject: Reply with quote

krinn wrote:
albright: you are right, the wiki page seems incorrect with 0xc2
Code:
iucode_tool  -l /lib/firmware/intel-ucode/* | grep 506e3
  066/001: sig 0x000506e3, pf_mask 0x36, 2017-04-09, rev 0x00ba, size 98304

I don't understand anymore, my Ivybridge (306e4) must be revision 0x42a from wiki page but
Code:
iucode_tool  -l /lib/firmware/intel-ucode/* | grep 306e4
  051/001: sig 0x000306e4, pf_mask 0xed, 2014-05-29, rev 0x0428, size 13312

with latest microcode 20171117_p20171215-r1
_________________
Questions are guaranteed in life; Answers aren't.
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 7236
Location: almost Mile High in the USA

PostPosted: Tue Jan 09, 2018 11:06 am    Post subject: Reply with quote

Allright, I think I found more information about the 4GB/4GB split.

Apparently, unfortunately, the current incarnation of PAE does not have the so-called 4GB/4GB split. This patch was suggested to kernel devs but not integrated. The patch was introduced during the 2.5.X series and jettisoned before it made it into the kernel.

It completely maps out kernel space so that user programs can access the whole 4GB of address space, so your programs can fully use 4GB of RAM per process instead of running out of RAM at 3GB per process. This has the side effect of preventing Meltdown.

So... 32-bit continues to be vulnerable with no solutions as of now, unless you happen to still use the experimental 4G/4G patch on an ancient kernel.
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7167

PostPosted: Tue Jan 09, 2018 12:42 pm    Post subject: Reply with quote

fedeliallalinea wrote:
I don't understand anymore, my Ivybridge (306e4) must be revision 0x42a from wiki page but
Code:
iucode_tool  -l /lib/firmware/intel-ucode/* | grep 306e4
  051/001: sig 0x000306e4, pf_mask 0xed, 2014-05-29, rev 0x0428, size 13312

with latest microcode 20171117_p20171215-r1

intel latest provide microcode is https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File?product=122139
Which is the "already" too old file that is use by 20171117_p20171215.
20171117_p20171215 -r1 have some microcode update, and that file comes from debian that took it from redhat.

You can see that file has "some update", here's the list from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886367
Code:
     + Updated Microcodes:
       sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552
       sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432
       sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792
       sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528
       sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328
       sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648
       sig 0x00050654, pf_mask 0xb7, 2017-11-21, rev 0x200003a, size 27648
       sig 0x000506c9, pf_mask 0x03, 2017-11-22, rev 0x002e, size 16384
       sig 0x000806e9, pf_mask 0xc0, 2017-12-03, rev 0x007c, size 98304
       sig 0x000906e9, pf_mask 0x2a, 2017-12-03, rev 0x007c, size 98304

As you see, no update for 306e4 cpu, so i suppose the version gentoo speak in the wiki, is a not yet release version that will have the fix.

So for now, if your cpu is in that list, you have an update.
Back to top
View user's profile Send private message
fedeliallalinea
Bodhisattva
Bodhisattva


Joined: 08 Mar 2003
Posts: 22325
Location: here

PostPosted: Tue Jan 09, 2018 1:11 pm    Post subject: Reply with quote

krinn wrote:
As you see, no update for 306e4 cpu, so i suppose the version gentoo speak in the wiki, is a not yet release version that will have the fix.

So for now, if your cpu is in that list, you have an update.

Thank you krinn, now is clear!
_________________
Questions are guaranteed in life; Answers aren't.
Back to top
View user's profile Send private message
kajzer
Guru
Guru


Joined: 27 Nov 2014
Posts: 468

PostPosted: Tue Jan 09, 2018 1:39 pm    Post subject: Reply with quote

Thistled wrote:
I'm really confused here, because although Intel say they no longer support my CPU, they are still offering a microcode update from late 2017,
and yet even after applying the update via Portage, I am still on a 2010 microcode update.
??
Intel® Pentium® Processor E5400 (2M Cache, 2.70 GHz, 800 MHz FSB) is in the list.


I think that's because they just say here's the latest archive for download with all cpu's microcode files inside, your cpu is on the list (like any that has microcode produced ever) but it doesn't matter that the date is 2017, for your cpu the microcode file date is 2010, they just pack all microcode files inside no matter if only one file was actually updated in that archive.
That's how I see it, could be wrong though.
Back to top
View user's profile Send private message
Myu
Apprentice
Apprentice


Joined: 22 Oct 2014
Posts: 164
Location: Belgium

PostPosted: Tue Jan 09, 2018 2:22 pm    Post subject: Reply with quote

So looking at this page, there's no microcode update for Sandy Bridge ? Thanks Intel ... :evil:
_________________
Gentoo stable with bits of ~amd64 // Xfce 4.13 + Compiz Reloaded.
Back to top
View user's profile Send private message
Thistled
Guru
Guru


Joined: 06 Jan 2011
Posts: 548
Location: Scotland

PostPosted: Tue Jan 09, 2018 2:53 pm    Post subject: Reply with quote

Forgive me for the conspiracy theory, but by Intel refusing to update microcode for older CPU's, and as a result forcing the user
to update to a newer CPU, is this not worthy of what Americans call a class action lawsuit?
Why should I be forced to buy a newer more expensive CPU when the current one I am using is fine and doing a great job? Albeit vulnerable
due to its age. Which could surely be mitigated by UPDATING the microcode?
Or am I missing something here, such as the age of the CPU means I DO have some level of mitigation?
This is a mess. Especially when the intel site states my CPU is covered by the latest microcode update. It clearly isn't.
I do know however that the TSX instruction set is not available in my CPU, so maybe Wolfdales are OK?
_________________
Whatever you do, do it properly!
Back to top
View user's profile Send private message
Myu
Apprentice
Apprentice


Joined: 22 Oct 2014
Posts: 164
Location: Belgium

PostPosted: Tue Jan 09, 2018 3:03 pm    Post subject: Reply with quote

Quote:
Forgive me for the conspiracy theory, but by Intel refusing to update microcode for older CPU's, and as a result forcing the user
to update to a newer CPU, is this not worthy of what Americans call a class action lawsuit?


Could be, not in the US anyway but I'll be voting with my wallet if I need to purchase a new CPU and it's gonna be AMD.

Quote:
Why should I be forced to buy a newer more expensive CPU when the current one I am using is fine and doing a great job? Albeit vulnerable
due to its age. Which could surely be mitigated by UPDATING the microcode?


I'm still holding up but like you, I would be really disappointed if there's no microcode update for older CPU's, my CPU is doing FINE, my OS of choice is already patched against meltdown, AFAIK all I need is the Microcode by now (and some other mitigations from GCC8/LLVM and other programs)
_________________
Gentoo stable with bits of ~amd64 // Xfce 4.13 + Compiz Reloaded.
Back to top
View user's profile Send private message
PrSo
Tux's lil' helper
Tux's lil' helper


Joined: 01 Jun 2017
Posts: 129

PostPosted: Tue Jan 09, 2018 3:05 pm    Post subject: Reply with quote

Myu wrote:
So looking at this page, there's no microcode update for Sandy Bridge ? Thanks Intel ... :evil:


I think that intel will upgrade cpu microcode in waves.

I have ThinkPad t530 (sandy bridge) with Windoze and Lenovo support page about Meltdown vulnerability stays that the new bios will be available from 2/2/2018. So there is a big probability that they will be sending microcodes for older families.

https://support.lenovo.com/us/en/solutions/len-18282


Last edited by PrSo on Tue Jan 09, 2018 6:26 pm; edited 1 time in total
Back to top
View user's profile Send private message
Myu
Apprentice
Apprentice


Joined: 22 Oct 2014
Posts: 164
Location: Belgium

PostPosted: Tue Jan 09, 2018 3:08 pm    Post subject: Reply with quote

Quote:
I think that intel will upgrade cpu microcode in waves.

I have ThinkPad t530 (sandy bridge) with Windoze and Lenovo support page about Meltdown vulnerability stays that new bios will be available from 2/2/2018. So there is big probability that they will be sending microcodes for older families.

https://support.lenovo.com/us/en/solutions/len-18282


That's some valuable intel (ha!) you brought here PrSo, thanks, will keep an eye on this, all hope may not be lost.
_________________
Gentoo stable with bits of ~amd64 // Xfce 4.13 + Compiz Reloaded.
Back to top
View user's profile Send private message
Pearlseattle
Apprentice
Apprentice


Joined: 04 Oct 2007
Posts: 162
Location: Switzerland

PostPosted: Tue Jan 09, 2018 7:44 pm    Post subject: Reply with quote

PrSo wrote:
Myu wrote:
So looking at this page, there's no microcode update for Sandy Bridge ? Thanks Intel ... :evil:


I think that intel will upgrade cpu microcode in waves.

I have ThinkPad t530 (sandy bridge) with Windoze and Lenovo support page about Meltdown vulnerability stays that the new bios will be available from 2/2/2018. So there is a big probability that they will be sending microcodes for older families.

https://support.lenovo.com/us/en/solutions/len-18282


This is as well my understanding.
More precisely, the promise is that by Sunday 14.Jan "Intel expects to have issued updates for more than 90 percent of processor products introduced within the past five years" (stated here).
E.g. my "Xeon(R) CPU E3-1260L v5" hasn't been patched yet :cry:
Back to top
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 2537
Location: Canada

PostPosted: Tue Jan 09, 2018 9:36 pm    Post subject: So how is the performance after patches ? Reply with quote

To those of you who have patched/upgraded everything - can you comment on the performance, is there a noticable hit ?
Back to top
View user's profile Send private message
saboya
Guru
Guru


Joined: 28 Nov 2006
Posts: 469
Location: Brazil

PostPosted: Tue Jan 09, 2018 11:08 pm    Post subject: Re: So how is the performance after patches ? Reply with quote

dmpogo wrote:
To those of you who have patched/upgraded everything - can you comment on the performance, is there a noticable hit ?

Unnoticeable outside synthetic benchmarks / very specific server usage.
Back to top
View user's profile Send private message
Display posts from previous:   
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3 ... 9, 10, 11 ... 21, 22, 23  Next
Page 10 of 23

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum