Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Meltdown and Spectre for Noobs
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 42560
Location: 56N 3W

PostPosted: Sun Jan 14, 2018 7:08 pm    Post subject: Reply with quote

while true,

The microcode for meltdown/spectre for your CPU may not be out yet.
Look at
Code:
ls /lib/firmware/amd-ucode/
to see what is available.

Look at
Code:
$ grep 'cpu fam' /proc/cpuinfo
to see what you need.

With a cpu family : 16 CPU you would need to add
Code:
amd-ucode/microcode_amd.bin amd-ucode/microcode_amd_fam15h.bin amd-ucode/microcode_amd_fam16h.bin
to your
(radeon/<YOUR-MODEL>.bin)

Its all the .bin files up to and including your cpu family. Do not remove the existing files or your video will not work any more.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
while true
Guru
Guru


Joined: 07 Apr 2010
Posts: 454
Location: Ljubljana, Slovenia

PostPosted: Sun Jan 14, 2018 7:25 pm    Post subject: Reply with quote

oi oi, so:
Code:
$ ls /lib/firmware/amd-ucode/
microcode_amd.bin  microcode_amd.bin.asc  microcode_amd_fam15h.bin  microcode_amd_fam15h.bin.asc  microcode_amd_fam16h.bin  microcode_amd_fam16h.bin.asc  microcode_amd_fam17h.bin
$ grep 'cpu fam' /proc/cpuinfo
cpu family      : 21
cpu family      : 21
cpu family      : 21
cpu family      : 21
cpu family      : 21
cpu family      : 21
cpu family      : 21
cpu family      : 21

so my family is 21, and updates are up to 17? I still have to wait for my family? I will keep an eye on that.
_________________
Kind regards, Goran Mitic

alive
while true
kick ass
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 17759

PostPosted: Mon Jan 15, 2018 5:20 am    Post subject: Reply with quote

krinn wrote:
you should just disable KPTI, it's not use because of your cpu,
NeddySeagoon wrote:
PTI is in your kernel but its not needed on your CPU, so its not used.
Is disabling it completely correct? See Hu's response to an inquiry of mine earlier in that thread.
_________________
I honestly think you ought to sit down calmly, take a stress pill, and think things over.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 17759

PostPosted: Mon Jan 15, 2018 5:35 am    Post subject: Reply with quote

NeddySeagoon wrote:
With a cpu family : 16 CPU you would need to add
Code:
amd-ucode/microcode_amd.bin amd-ucode/microcode_amd_fam15h.bin amd-ucode/microcode_amd_fam16h.bin
to your
(radeon/<YOUR-MODEL>.bin)

Its all the .bin files up to and including your cpu family. Do not remove the existing files or your video will not work any more.
If you don't mind, would you help educate me on this? I didn't even realize microcode updates existed until these vulnerabilities.

In reading the microcode table from the Gentoo AMD microcode wiki, I see CPU family decimal values (from 'grep -m1 family /proc/cpuinfo') as 16, 17, 18 and 20 using microcode_amd.bin. With cpu family decimal 21 using microcode_amd_fam15h.bin and cpu family decimal 22 using microcode_amd_fam16h.bin.

That appears to tell me that "fam15h.bin" and "fam16h.bin" would not be appropriate for a decimal value cpu family of 16.

Code:
grep -m1 family /proc/cpuinfo
cpu family      : 16


Maybe they could have made it easier by mixing in octal as well :D

Thanks.
_________________
I honestly think you ought to sit down calmly, take a stress pill, and think things over.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 42560
Location: 56N 3W

PostPosted: Mon Jan 15, 2018 10:27 am    Post subject: Reply with quote

pjp,

It looks like you are educating me. :)

For many years, I've had the AMD microcode update option in my kernel but no microcode file. :(
Now I've added the microcode file(s) it looks like I've made a pigs ear of it.
I do have a newer microcode than the one shipped in the CPU though.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5586
Location: Removed by Neddy

PostPosted: Mon Jan 15, 2018 10:56 am    Post subject: Reply with quote

NeddySeagoon wrote:
pjp,

It looks like you are educating me. :)

For many years, I've had the AMD microcode update option in my kernel but no microcode file. :(
Now I've added the microcode file(s) it looks like I've made a pigs ear of it.
I do have a newer microcode than the one shipped in the CPU though.
Or BIOS
The BIOS applies a uCode to the CPU while it POST's (or whatever the UEFI calls it these days). This is the usual way uCode is updated for PC's and considering BIOS updates are traditionally windows-only applications this was the way.
Being able to on-the-fly update the uCode was added to make life easier for linux users and is the preferred way to update the uCode *IF* said files are available.

Even if you have never updated your BIOS, you will still have a uCode provided by it
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 6960

PostPosted: Mon Jan 15, 2018 2:02 pm    Post subject: Reply with quote

pjp wrote:
krinn wrote:
you should just disable KPTI, it's not use because of your cpu,
NeddySeagoon wrote:
PTI is in your kernel but its not needed on your CPU, so its not used.
Is disabling it completely correct? See Hu's response to an inquiry of mine earlier in that thread.

thanks for pointing this, however i disagree with Hu:
while the technique he describe could be use to actually know if the memory match a kernel area ; the real issue is that your cpu cache is fillled with that memory area.
To me they do (ok make it really clear, it's my own understanding of the issue, not actually real explains), but just how i think the meldown issue is:
- Execution instruction toward a memory area
- Cpu speculate on next instruction, and fill its cache with "what will be result of the next instruction" ; so you instruct cpu to access memory location, and cpu speculate that your next instruction will be fetch the content of that location.
-> if the next instruction is then the one the cpu has bet you will use, the cpu then check if you have rights to do so, and if not, cache clear.
-> if you pass the rights check, the result is already there because run previously -> speed increase, you are asking something and the cpu has already compute it and you get the result from its cache.
-> if the next instruction is not the one the cpu has bet you will use, drop cache result

I think that the idea of meltdown is:
force cpu to speculative execute an instruction, the execution fill cpu cache with result ; and instead of execute another instruction that would let cpu speculated on something else (as it would fill cache with result of this one), instead of doing the instruction the cpu has bet you would do next (that would trigger rights check), you directly fetch the cpu cache to read the result of the speculative run.

But you are only aware you have succeed at reading the cache result, you don't know the value of that result.
To make sure, the given address was a valid one, and that indeed the cpu has execute a real instruction speculatively for you, you should do that twice to check if the first and second execution speed match.

And i think Hu is showing that amd cpu are still affect by the "check twice" to see if you have use a real memory area or not.
Tom Lendacky wrote:
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.

And to me the amd guy is saying: amd cpu do checks prior execute the speculative instruction, and if that result would be pagefault (because you don't have rights to access it), the cpu doesn't execute it.

By doing so on amd cpu : you are still able to tell if the cpu has access a valid kernel memory area (by comparing timing result, you know the address was valid or not), but that's all, you cannot read the result from its cache, because the amd cpu has check if reading that area would end in fault prior execute the instruction, and its cache content is not the result of the instruction, but garbage.

From my understanding (and i'm certainly wrong there!), but backup by the amd guy claims, if i were an amd cpu owner, i would just remove KPTI, even knowing someone can check if a memory location is valid or not.
I'm not quiet sure if i would in real, i tend to be conservative and with my European culture, and as this has prove more than once to be the right thing to do, i may enable KPTI even my cpu would be an amd. You know: better safe than sorry.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 17759

PostPosted: Tue Jan 16, 2018 4:57 am    Post subject: Reply with quote

NeddySeagoon wrote:
pjp,

It looks like you are educating me. :)

For many years, I've had the AMD microcode update option in my kernel but no microcode file. :(
Now I've added the microcode file(s) it looks like I've made a pigs ear of it.
I do have a newer microcode than the one shipped in the CPU though.
Well, passing along information anyway. I thought I had just figured it out, then I saw your post :)
_________________
I honestly think you ought to sit down calmly, take a stress pill, and think things over.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 17759

PostPosted: Tue Jan 16, 2018 5:04 am    Post subject: Reply with quote

krinn wrote:
thanks for pointing this, however i disagree with Hu:
That's fine, I'm just focused on the issue referenced in the wikipedia entry. Just because it is written there doesn't mean it is accurate, but I'm not seeing much that is currently addressing that possible issue.

krinn wrote:
i tend to be conservative and with my European culture, and as this has prove more than once to be the right thing to do, i may enable KPTI even my cpu would be an amd. You know: better safe than sorry.
I tend to be of the type that wants vulnerabilities corrected. At least until I see something more definitive, I'm leaving KPTI enabled in the kernel and turned on via the kernel cmdline. Thanks for the comments.
_________________
I honestly think you ought to sit down calmly, take a stress pill, and think things over.
Back to top
View user's profile Send private message
Azurael
n00b
n00b


Joined: 06 Oct 2013
Posts: 4

PostPosted: Mon Jan 29, 2018 8:36 pm    Post subject: Reply with quote

None of the huge quantity of documentation on these issues makes it clear what exactly is supposed to mitigate Spectre Variant 1 (including Gentoo's own https://wiki.gentoo.org/wiki/Project:Security/Vulnerabilities/Meltdown_and_Spectre - other than to say "This problem is mitigated by adding speculative fencing on affected code paths throughout the Linux kernel.") I've enabled KPTI and Retpoline and I'm building with GCC 7.3.0, what have I missed?!

Code:
azurael@kitsune ~ $ sudo ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.33+

Checking for vulnerabilities on current system
Kernel is Linux 4.15.0-gentoo #1 SMP Mon Jan 29 19:56:44 GMT 2018 x86_64
CPU is Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  NO
    * CPU indicates IBRS capability:  NO
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  NO
    * CPU indicates IBPB capability:  NO
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  NO
    * CPU indicates STIBP capability:  NO
  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability:  NO
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO
  * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):  NO
  * CPU microcode is known to cause stability problems:  NO
* CPU vulnerability to the three speculative execution attacks variants
  * Vulnerable to Variant 1:  YES
  * Vulnerable to Variant 2:  YES
  * Vulnerable to Variant 3:  YES

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface:  NO  (kernel confirms your system is vulnerable)
> STATUS:  VULNERABLE  (Vulnerable)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
* Mitigation 1
  * Kernel is compiled with IBRS/IBPB support:  NO
  * Currently enabled features
    * IBRS enabled for Kernel space:  NO
    * IBRS enabled for User space:  NO
    * IBPB enabled:  NO
* Mitigation 2
  * Kernel compiled with retpoline option:  YES
  * Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports full retpoline compilation)
  * Retpoline enabled:  YES
> STATUS:  NOT VULNERABLE  (Mitigation: Full generic retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
* Kernel supports Page Table Isolation (PTI):  YES
* PTI enabled and active:  YES
* Running as a Xen PV DomU:  NO
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

A false sense of security is worse than no security at all, see --disclaimer


Last edited by Azurael on Mon Jan 29, 2018 10:37 pm; edited 1 time in total
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 42560
Location: 56N 3W

PostPosted: Mon Jan 29, 2018 8:49 pm    Post subject: Reply with quote

Azurael,

Ask the kernel itself.

Code:
# cat /sys/devices/system/cpu/vulnerabilities/*
Not affected
Vulnerable
Vulnerable: Minimal AMD ASM retpoline


With 4.15.0 out now, I'll be updating. That's 4.15.0-rc8 built with gcc-7.2.0 on an AMD Phenom(tm) II X6 1090T
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Azurael
n00b
n00b


Joined: 06 Oct 2013
Posts: 4

PostPosted: Mon Jan 29, 2018 9:11 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Azurael,

Ask the kernel itself.

Code:
# cat /sys/devices/system/cpu/vulnerabilities/*
Not affected
Vulnerable
Vulnerable: Minimal AMD ASM retpoline


With 4.15.0 out now, I'll be updating. That's 4.15.0-rc8 built with gcc-7.2.0 on an AMD Phenom(tm) II X6 1090T


That's why I asked. It just says vulnerable.
Back to top
View user's profile Send private message
manwe_
l33t
l33t


Joined: 01 Feb 2006
Posts: 621
Location: Kraków/Cracow, Poland

PostPosted: Mon Jan 29, 2018 10:30 pm    Post subject: Reply with quote

Lack of information how to deal with all three vulnerabilities is really annoying.

Code:
# grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline


Kernel 4.15.0 (gentoo-sources) with CONFIG_PAGE_TABLE_ISOLATION and CONFIG_RETPOLINE, compiled with gcc 7.3.0. Newest intel-microcode (20180108-r1) and linux firmware (20180119). Microcode update goes fine:
Code:
# dmesg | grep microcode
[    0.000000] microcode: microcode updated early to revision 0x23, date = 2017-11-20
[    0.997562] microcode: sig=0x306c3, pf=0x2, revision=0x23
[    0.997651] microcode: Microcode Update Driver: v2.2.


And still I get "Vulnerable" for "spectre_v1". Did I miss something?
Back to top
View user's profile Send private message
Jaglover
Watchman
Watchman


Joined: 29 May 2005
Posts: 6957
Location: Saint Amant, Acadiana

PostPosted: Mon Jan 29, 2018 10:55 pm    Post subject: Reply with quote

Code:
"-mindirect-branch=thunk"

Did you add it to your CFLAGS?
_________________
Please learn how to denote units correctly!
Back to top
View user's profile Send private message
manwe_
l33t
l33t


Joined: 01 Feb 2006
Posts: 621
Location: Kraków/Cracow, Poland

PostPosted: Mon Jan 29, 2018 11:04 pm    Post subject: Reply with quote

Kernel adds "-mindirect-branch=thunk-extern" to make when CONFIG_RETPOLINE is turned on:

Code:
root     24264  0.0  0.2 178620 35936 pts/4    R+   00:04   0:00 /usr/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1 -quiet -nostdinc -I ./arch/x86/include -I ./arch/x86/include/generated -I ./include -I ./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I ./include/uapi -I ./include/generated/uapi -D __KERNEL__ -D CONFIG_X86_X32_ABI -D CONFIG_AS_CFI=1 -D CONFIG_AS_CFI_SIGNAL_FRAME=1 -D CONFIG_AS_CFI_SECTIONS=1 -D CONFIG_AS_FXSAVEQ=1 -D CONFIG_AS_SSSE3=1 -D CONFIG_AS_CRC32=1 -D CONFIG_AS_AVX=1 -D CONFIG_AS_AVX2=1 -D CONFIG_AS_AVX512=1 -D CONFIG_AS_SHA1_NI=1 -D CONFIG_AS_SHA256_NI=1 -D RETPOLINE -D CC_HAVE_ASM_GOTO -D KBUILD_BASENAME="intel_cacheinfo" -D KBUILD_MODNAME="intel_cacheinfo" -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include -include ./include/linux/kconfig.h -MD arch/x86/kernel/cpu/.intel_cacheinfo.o.d arch/x86/kernel/cpu/intel_cacheinfo.c -march=haswell -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=haswell -quiet -dumpbase intel_cacheinfo.c -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mno-red-zone -mcmodel=kernel -mindirect-branch=thunk-extern -mindirect-branch-register -auxbase-strip arch/x86/kernel/cpu/intel_cacheinfo.o -O2 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -Werror=implicit-function-declaration -Wno-format-security -Wno-sign-compare -Wno-frame-address -Wformat-truncation=0 -Wformat-overflow=0 -Wno-int-in-bool-context -Wframe-larger-than=2048 -Wno-unused-but-set-variable -Wunused-const-variable=0 -Wdeclaration-after-statement -Wno-pointer-sign -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -std=gnu90 -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -falign-jumps=1 -falign-loops=1 -funit-at-a-time -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -fstack-protector -fomit-frame-pointer -fno-var-tracking-assignments -fno-strict-overflow -fstack-check=no -fconserve-stack --param allow-store-data-races=0 -o -
Back to top
View user's profile Send private message
platojones
Veteran
Veteran


Joined: 23 Oct 2002
Posts: 1595
Location: Just over the horizon

PostPosted: Mon Jan 29, 2018 11:14 pm    Post subject: Reply with quote

manwe_ wrote:
Lack of information how to deal with all three vulnerabilities is really annoying.

Code:
# grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline


Kernel 4.15.0 (gentoo-sources) with CONFIG_PAGE_TABLE_ISOLATION and CONFIG_RETPOLINE, compiled with gcc 7.3.0. Newest intel-microcode (20180108-r1) and linux firmware (20180119). Microcode update goes fine:
Code:
# dmesg | grep microcode
[    0.000000] microcode: microcode updated early to revision 0x23, date = 2017-11-20
[    0.997562] microcode: sig=0x306c3, pf=0x2, revision=0x23
[    0.997651] microcode: Microcode Update Driver: v2.2.


And still I get "Vulnerable" for "spectre_v1". Did I miss something?


Sounds like something is coming to mitigate that in 4.16.x:

https://www.phoronix.com/scan.php?page=news_item&px=Spectre-Variant-One-Linux-4.16
Back to top
View user's profile Send private message
manwe_
l33t
l33t


Joined: 01 Feb 2006
Posts: 621
Location: Kraków/Cracow, Poland

PostPosted: Mon Jan 29, 2018 11:20 pm    Post subject: Reply with quote

OK, so for now there's no fix for spectre_v1 (apart from bunch of LFENCES)? I hope this patchset will be backported to 4.15 soon.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 42560
Location: 56N 3W

PostPosted: Mon Jan 29, 2018 11:21 pm    Post subject: Reply with quote

manwe_,

Try 4.16.0-rc1 in a few weeks.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
PrSo
Tux's lil' helper
Tux's lil' helper


Joined: 01 Jun 2017
Posts: 128

PostPosted: Mon Jan 29, 2018 11:42 pm    Post subject: Reply with quote

manwe_ wrote:
OK, so for now there's no fix for spectre_v1 (apart from bunch of LFENCES)? I hope this patchset will be backported to 4.15 soon.


or if you are brave enough:
https://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux.git/?h=nospec-v5
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1691

PostPosted: Sat Feb 03, 2018 6:00 pm    Post subject: Reply with quote

For those interested on performance cost from using mindirect-branch=thunk, here's a benchmark that was done comparing thunk and thunk-inline (it was using gcc-8, so take it with a grain of salt on possible effects).
https://www.phoronix.com/scan.php?page=article&item=gcc8-mindirect-thunk&num=1

Beyond that, reading the gentoo dev mailing list, right now they are not indicating if people should set -mindirect-branch=thunk-extern (or which of the 3 thunks for that matter). The most that is said, is that the kernel will automatically be compiled with thunk-extern if its available.

Start of the message thread:https://archives.gentoo.org/gentoo-user/message/e17aac982002d2bcb75ec9c26b7b21f0

As far as thunk-extern goes, I haven't been seeing much of any information about it, beyond gcc-7.3/8 has it and the kernel will use it. According to the benchmark, it looks like thunk-inline gives a hefty performance hit from using that, where just thunk was minor for performance hit. It would be interesting to see more information between thunk, thunk-inline, and thunk-extern on which gives more protection and maybe also the performance cost for using it.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
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