-
Notifications
You must be signed in to change notification settings - Fork 640
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Protect cross-userspace Spectre attacks (both variant 1 and 2) #86
Comments
Can you elaborate on which platform you would like this for? This is already done for x86. |
@AdrianDanis I did not know that, sorry. I knew the kernel was protected, but I did not know that user programs were protected from each other. |
Be aware that the user space protections are off by default due to their extremely high expense. You can enable them in the menuconfig. |
How expensive are they? How many clock cycles?
…On Wed, Apr 4, 2018, 7:36 PM Adrian Danis ***@***.***> wrote:
Be aware that the user space protections are off by default due to their
extremely high expense. You can enable them in the menuconfig.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#86 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGGWB_0zJLh1DsUDaR2M14gvIliZXrqsks5tlVkNgaJpZM4TFJtJ>
.
|
ARM. Some ARM platforms are vulnerable to Spectre.
…On Tue, Apr 3, 2018, 7:57 PM Adrian Danis ***@***.***> wrote:
Can you elaborate on which platform you would like this for? This is
already done for x86.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#86 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGGWBwVcjlfCK5nANpxrTaoTgO_PjCVWks5tlAxkgaJpZM4TFJtJ>
.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Userspace processes need to be protected against Spectre attacks by other such processes. While the seL4 security claim does not extend to covert channels, timing attacks are a significant threat when untrusted code and trusted code are running on the same system.
Domains, while awesome for high-integrity software development where all trusted code is known a priori, do not suffice for this use case, because they are too strict: the number of domains, and the fraction of the CPU allocated to each, must be set at compile time (at least if I am reading the documentation correctly). As such, e.g. a version of QubesOS on seL4 would not be able to use them.
This issue also applies regarding cross-VM, VM→user, and user→VM attacks.
The text was updated successfully, but these errors were encountered: