OSDev.org

The Place to Start for Operating System Developers
It is currently Mon Aug 03, 2020 10:08 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 143 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10
Author Message
 Post subject: Re: CPU bug makes virtually all chips vulnerable
PostPosted: Sat Jan 27, 2018 3:16 pm 
Offline

Joined: Sat Jan 27, 2018 1:23 pm
Posts: 4
what about this code ?
Code:
lea   rax, [@f]
lea   rcx, [target]
cmp   value1, value2
cmova rax, rcx
push  rax
mfence
ret
@@:

I have definately seen smth about this about 4 years ago on an assembly forum.

I believe cmovCC doesn't pair with anything really, but what about condition predition - i don't know.


Last edited by gprs on Sat Jan 27, 2018 3:21 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: CPU bug makes virtually all chips vulnerable
PostPosted: Sat Jan 27, 2018 3:20 pm 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 739
The nice thing about retpoline (the code I posted earlier) is that lfence is not actually executed. It is only executed speculatively and thus the cost of retpoline is just the cost of two static branches, which is much lower than the cost of a real barrier.

_________________
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].


Top
 Profile  
 
 Post subject: Re: CPU bug makes virtually all chips vulnerable
PostPosted: Sat Jan 27, 2018 3:22 pm 
Offline

Joined: Sat Jan 27, 2018 1:23 pm
Posts: 4
thanks Korona


Top
 Profile  
 
 Post subject: Re: CPU bug makes virtually all chips vulnerable
PostPosted: Thu Feb 01, 2018 7:03 pm 
Offline
Member
Member

Joined: Sun Jun 16, 2013 4:09 am
Posts: 333
Has anyone done testing on performance?

My queue was running at 17.6 million per second per core.
To get around the hardware issue I set cr3 on a system call, to make the kernel pages visible.
Then before returning back to userspace I had to set cr3 again to hide kernel pages.
My queue dropped to 2.2 million.
This is a drop of over 80%

The next step is to test with Page Present, then CPID

Anyone else have some results?

Ali


Top
 Profile  
 
 Post subject: Re: CPU bug makes virtually all chips vulnerable
PostPosted: Sun Dec 15, 2019 1:43 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 2249
If I understand the issue correctly it is TLB entries that is the issue and thus it is the reading of a kernel address from userspace speculatively that leaves the address in the TLB even if it is not allowed. Thus, a 32 bit operating system that has usermode selectors that don't allow access to kernel space will not be vulnerable to these exploits. Which means I don't need any fixes for this at all.


Top
 Profile  
 
 Post subject: Re: CPU bug makes virtually all chips vulnerable
PostPosted: Sun Dec 15, 2019 2:49 am 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 739
The issue (for Meltdown) is that those selector CPL vs. PTE checks were not done during speculative execution. I don't know if anyone tested whether segment limit checks are done during speculative execution. So unless that's tested, it's not clear whether segmentation can mitigate the issue or not. (If you test it, feel free to post the results here, would be interesting to know.)

_________________
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].


Top
 Profile  
 
 Post subject: Re: CPU bug makes virtually all chips vulnerable
PostPosted: Sun Dec 15, 2019 3:15 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 2249
Korona wrote:
The issue (for Meltdown) is that those selector CPL vs. PTE checks were not done during speculative execution. I don't know if anyone tested whether segment limit checks are done during speculative execution. So unless that's tested, it's not clear whether segmentation can mitigate the issue or not. (If you test it, feel free to post the results here, would be interesting to know.)


I'm not sure how to do that. Intel processors had penalties for not using 4G flat selectors which related to adding the base to form a linear address, which indicates that segmentation checks cannot be skipped with speculative execution. My guess is that Intel would only skjp those checks if 4G flat selectors are used, which both Windows and Linux use.


Top
 Profile  
 
 Post subject: Re: CPU bug makes virtually all chips vulnerable
PostPosted: Tue Dec 17, 2019 3:59 am 
Offline
Member
Member
User avatar

Joined: Tue Oct 17, 2006 11:33 pm
Posts: 3879
Location: Eindhoven
Korona wrote:
The issue (for Meltdown) is that those selector CPL vs. PTE checks were not done during speculative execution. I don't know if anyone tested whether segment limit checks are done during speculative execution. So unless that's tested, it's not clear whether segmentation can mitigate the issue or not. (If you test it, feel free to post the results here, would be interesting to know.)


Meltdown is that these checks, which do happen on all CPUs (and which would be a huge bug if they didn't!), happened on the speculative path only to trigger the error if that case was actually executed. They were not used to determine whether to speculate further. That meant that you could leak the data loaded with the invalid load through a side-channel if you have one.

This is a 'simple' thing to fix - just stop speculative execution if an error has occurred. Not easy to retrofit, but easy enough for new machines, and of course AMD and other AMD64/X86_64 vendors don't have this problem because they didn't make that mistake to start with.

Spectre is much harder as it revolves around mistraining a BPB, BTB or similar structure to cause a wrong branch to be taken with sensitive data on another process, which the wrong branch then leaks through a side channel. Harder to abuse, but just about impossible to fix.

Retpoline locally disables the BTB. So you can't poison the BTB any more effectively, because it doesn't use it any more.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 143 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10

All times are UTC - 6 hours


Who is online

Users browsing this forum: isaacwoods and 2 guests


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 post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group