12:31 p.m.
Hi guys,
While booting up I get a scary message saying:
L1TF CPU bug present and SMT on, data leak possible.
Yup you guessed it, I am on an Intel processor, which is in fact quiet old:
Intel(R) Core(TM) i5-6200U CPU
Vulnerability info from the kernel:
cat /sys/devices/system/cpu/vulnerabilities/l1tf
Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
I am in the process of reading this detailed article about the bug:
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html
Meanwhile, I wanted to know if any one here has the same problem and
what they did for mitigations.
The scariest thing about this bug, specifically, is that even malicious
VMs pose a threat. May speculative execution burn in hell.
I am no expert on hardware or these types of obscure vulnerabilities so
any advice/tips/help is greatly appreciated.
PS: I thought of going to a kernel mailing list, but am worried that
those "geniuses" would just flame me.
--
Regards,
Sreyan
7:09 a.m.
On 5/14/20 11:23 PM, Tom Horsley wrote:
I mitigate by ignoring it:-). (Seeing as how there I nothing I can
do
about it).
It scares me to think that you might be right. Intel has really done
downhill.
It is no longer possible to use their processors at maximum throughput
while ensuring data security.
--
Regards,
Sreyan
7:56 a.m.
On Fri, 15 May 2020 at 09:12, Sreyan Chakravarty <sreyan32(a)gmail.com> wrote:
On 5/14/20 11:23 PM, Tom Horsley wrote:
> I mitigate by ignoring it:-). (Seeing as how there I nothing I can do
> about it).
It scares me to think that you might be right. Intel has really done
downhill.
Racing for the bottom against Boeing, except Intel has a longer history
of screwups https://en.wikipedia.org/wiki/Pentium_FDIV_bug
Thunderspy negates a big Intel effort to secure Thunderbolt DMA access by
external devices:
https://arstechnica.com/information-technology/2020/05/thunderspy-what-is...
According to security research Ken White [no relation]:
... both Apple and Google have managed to implement settings that block
many Thunderspy type physical DMA attacks, including USB-C, from working
against Macs and Pixelbooks, respectively. “Apple and Google device
engineers seem to have anticipated this issue and have stronger IOMMU
defaults and therefore expose their users to less risk.”
It is no longer possible to use their processors at maximum
throughput
while ensuring data security.
Speculative (out-of-order) execution is hard. RISC-V doesn't use it.
https://hardware.slashdot.org/story/18/12/01/037236/risc-v-and-linux-foun...
Apple is expected to start selling laptops using their own chip designs.
There are chip design groups at Google and Amazon.
Linux and MacOS have a big advantage in support for non-Intel
architectures. The future seems to lie with many
simpler cores and GPU/vector processing units.
--
George N. White III
2:06 p.m.
On Thu, May 14, 2020 at 7:31 PM Sreyan Chakravarty <sreyan32(a)gmail.com> wrote:
I am in the process of reading this detailed article about the bug:
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html
Meanwhile, I wanted to know if any one here has the same problem and
what they did for mitigations.
Your linked document [1] describes in detail how to mitigate and also
lists the associated performance degradation.
LWN also provides a good summary for L1TF [2].
On my private machines with older CPUs, I tend to use mitigations=off
to disable all CPU mitigation techniques introduced since Meltdown in
order to gain some performance back. I/O and context switches in
general are really slow with enabled mitigations on Sandy and Ivy
Bridge, so I am willing to take some risks on these platforms, which
is of course not recommended and possibly a really bad idea :-)
$ grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Vulnerable
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE
Inversion; VMX: vulnerable
/sys/devices/system/cpu/vulnerabilities/mds:Vulnerable; SMT vulnerable
/sys/devices/system/cpu/vulnerabilities/meltdown:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable: __user
pointer sanitization and usercopy barriers only; no swapgs barriers
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable, IBPB:
disabled, STIBP: disabled
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected
[1]
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html#miti...
[2] https://lwn.net/Articles/762570/
6:55 a.m.
On 5/15/20 12:36 AM, Thorsten Schubert wrote:
Your linked document [1] describes in detail how to mitigate and
also
lists the associated performance degradation.
LWN also provides a good summary for L1TF [2].
Yeah, I am reading up on that. But I
am not a kernel developer or a
kernel administrator, hence I was hoping to get some info from here.
On my private machines with older CPUs, I tend to use mitigations=off
to disable all CPU mitigation techniques introduced since Meltdown in
order to gain some performance back.
I see. This is really annoying. I hate having
to sacrifice speed for
security. My PC is slow as it is.
I/O and context switches in
general are really slow with enabled mitigations on Sandy and Ivy
Bridge, so I am willing to take some risks on these platforms, which
is of course not recommended and possibly a really bad idea:-)
Exactly what I am
afraid of. I run a lot of VMs to test out untrusted
software and practice for CTFs. Basically what this bug does is break
sanboxing completely AFAIK.
$ grep ./sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Vulnerable
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE
Inversion; VMX: vulnerable
/sys/devices/system/cpu/vulnerabilities/mds:Vulnerable; SMT vulnerable
/sys/devices/system/cpu/vulnerabilities/meltdown:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable: __user
pointer sanitization and usercopy barriers only; no swapgs barriers
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable, IBPB:
disabled, STIBP: disabled
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected
I am just
curious, but how many of these vulnerabilities do you find on
AMD CPUs ?
--
Regards,
Sreyan
2:33 p.m.
On Thu, 14 May 2020 23:01:04 +0530
Sreyan Chakravarty <sreyan32(a)gmail.com> wrote:
While booting up I get a scary message saying:
L1TF CPU bug present and SMT on, data leak possible.
The scariest thing about this bug, specifically, is that even
malicious VMs pose a threat. May speculative execution burn in hell.
I am no expert on hardware or these types of obscure vulnerabilities
so any advice/tips/help is greatly appreciated.
If you are the only user on your machine, you almost certainly don't
have to worry about this. It requires that the process to perform this
attack be running on your machine at the same time as the process that
is being attacked, and running on the same cpu / core.
If you go here,
https://www.intel.com/content/www/us/en/architecture-and-technology/l1tf....
you will see that there are no known examples of a real world
exploit as far as intel knows. If it were to be carried out by a
malicious program with no person present, it would have to save the
data, and mail it home in some way. It is possible that a program that
you installed by rpm would have this, but very unlikely.
The main threat of this attack was on cloud servers where many
different users are running under virtual machines. These are meant to
be silos, but this attack would allow someone on one virtual machine to
capture data of another virtual machine running on the same core.
I think for single use systems, Tom's response is the correct one, but
you can worry if you want. :-)
2:53 p.m.
On Thu, 14 May 2020 12:33:59 -0700
stan via users wrote:
These are meant to
be silos, but this attack would allow someone on one virtual machine to
capture data of another virtual machine running on the same core.
Reminds me of the very early days of KVM virtualization where I
discovered that the debug registers weren't being properly
context switched and you could set a watch on a memory address in a program
running in one VM and get programs in other VMs to be
interrupted as though they hit the watch (they fixed it :-).
2:59 p.m.
On Thu, 14 May 2020 15:53:52 -0400
Tom Horsley <horsley1953(a)gmail.com> wrote:
On Thu, 14 May 2020 12:33:59 -0700
stan via users wrote:
> These are meant to
> be silos, but this attack would allow someone on one virtual
> machine to capture data of another virtual machine running on the
> same core.
Reminds me of the very early days of KVM virtualization where I
discovered that the debug registers weren't being properly
context switched and you could set a watch on a memory address in a
program running in one VM and get programs in other VMs to be
interrupted as though they hit the watch (they fixed it :-).
Yes, meltdown is much more sophisticated, but the same idea. When I
first read the description, I was astonished that someone had the
ingenuity to come up with it.
7:04 a.m.
On Thu, 14 May 2020 12:33:59 -0700
stan via users wrote:
> These are meant to
> be silos, but this attack would allow someone on one virtual machine to
> capture data of another virtual machine running on the same core.
This gives me a naive idea.
Is there any way to force the VMs to run on an isolated core ? The VM
and OS must not run on the same core, if this is enforced, then
according to what you say there might be sufficient containment of the
breach.
Am I correct ? Or am I speaking nonsense ?
--
Regards,
Sreyan
8:09 a.m.
On Fri, 15 May 2020 17:34:43 +0530
Sreyan Chakravarty <sreyan32(a)gmail.com> wrote:
> On Thu, 14 May 2020 12:33:59 -0700
> stan via users wrote:
>
>> These are meant to
>> be silos, but this attack would allow someone on one virtual
>> machine to capture data of another virtual machine running on the
>> same core.
This gives me a naive idea.
Is there any way to force the VMs to run on an isolated core ? The VM
and OS must not run on the same core, if this is enforced, then
according to what you say there might be sufficient containment of
the breach.
Am I correct ? Or am I speaking nonsense ?
You are correct. I'm not sure of the method to do that though.
10:30 a.m.
On Fri, 2020-05-15 at 17:34 +0530, Sreyan Chakravarty wrote:
> On Thu, 14 May 2020 12:33:59 -0700
> stan via users wrote:
>
> > These are meant to
> > be silos, but this attack would allow someone on one virtual machine to
> > capture data of another virtual machine running on the same core.
This gives me a naive idea.
Is there any way to force the VMs to run on an isolated core ? The VM
and OS must not run on the same core, if this is enforced, then
according to what you say there might be sufficient containment of the
breach.
Am I correct ? Or am I speaking nonsense ?
QEMU/KVM allows you to pin a VM to a specific set of cores by inserting
a block into the XML file. This is mine, using 4 threads (2 cores) on a
4-core, 8-thread, i7 (the numbers will vary according to your CPU
model):
<cputune>
<vcpupin vcpu='0' cpuset='2'/>
<vcpupin vcpu='1' cpuset='3'/>
<vcpupin vcpu='2' cpuset='6'/>
<vcpupin vcpu='3' cpuset='7'/>
</cputune>
I do this with my Windows VM for performance reasons. However I don't
think this is going to help with a speculative execution bug.
poc
3:02 p.m.
On Thu, 14 May 2020 12:33:59 -0700
stan via users <users(a)lists.fedoraproject.org> wrote:
I think for single use systems, Tom's response is the correct
one, but
you can worry if you want. :-)
After posting, I vaguely recalled that there was a javascript
implementation of the sample exploit code. So, that is another thing
to worry about; be careful of what javascript you allow to run in your
browser. Probably the main attack vector for single use systems.
7:02 a.m.
On 5/15/20 1:32 AM, stan via users wrote:
After posting, I vaguely recalled that there was a javascript
implementation of the sample exploit code.
Now this is really scary.
This makes it a potential web attack. I can't obviously live like a
hermit and visit only sites that have no javascript in it, can I ?
--
Regards,
Sreyan
8:16 a.m.
On Fri, 15 May 2020 17:32:10 +0530
Sreyan Chakravarty <sreyan32(a)gmail.com> wrote:
On 5/15/20 1:32 AM, stan via users wrote:
> After posting, I vaguely recalled that there was a javascript
> implementation of the sample exploit code.
Now this is really scary.
This makes it a potential web attack. I can't obviously live like a
hermit and visit only sites that have no javascript in it, can I ?
Because the attack is so sophisticated, it depends on very precise
timing. I *think* I read that firefox, at least, changed their
javascript so the timing accuracy was too fuzzy for the attack to work.
This would only have required changing accuracy to millisecond (or
tenths (hundredths?) of millisecond) timing rather than nanosecond
timing.
Also, firefox has sandboxing on javascript plugins. So, if the
javascript is restricted from sending anything over the web, it would
be impotent because it would have no way of communicating its results.
Plugins also only get access to the components they need to perform
their function, so might not have access to the necessary system calls
to allow the attack.
2:49 p.m.
Also, firefox has sandboxing on javascript plugins.
Would running Firefox in Firejail help in this case ?
On Fri, May 15, 2020 at 6:47 PM stan via users <
users(a)lists.fedoraproject.org> wrote:
On Fri, 15 May 2020 17:32:10 +0530
Sreyan Chakravarty <sreyan32(a)gmail.com> wrote:
> On 5/15/20 1:32 AM, stan via users wrote:
> > After posting, I vaguely recalled that there was a javascript
> > implementation of the sample exploit code.
>
> Now this is really scary.
>
> This makes it a potential web attack. I can't obviously live like a
> hermit and visit only sites that have no javascript in it, can I ?
>
Because the attack is so sophisticated, it depends on very precise
timing. I *think* I read that firefox, at least, changed their
javascript so the timing accuracy was too fuzzy for the attack to work.
This would only have required changing accuracy to millisecond (or
tenths (hundredths?) of millisecond) timing rather than nanosecond
timing.
Also, firefox has sandboxing on javascript plugins. So, if the
javascript is restricted from sending anything over the web, it would
be impotent because it would have no way of communicating its results.
Plugins also only get access to the components they need to perform
their function, so might not have access to the necessary system calls
to allow the attack.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
--
Regards,
Sreyan Chakravarty
1:24 a.m.
On Mon, 18 May 2020 01:19:12 +0530
Sreyan Chakravarty <sreyan32(a)gmail.com> wrote:
>
> Also, firefox has sandboxing on javascript plugins.
Would running Firefox in Firejail help in this case ?
I'm unfamiliar with Firejail so I don't know. If it is what it sounds
like, a chroot for plugins, yes, that would help if network access can
be restricted. If you are using approved firefox plugins, though, it is
unlikely that they have the attack code in them.
You should check if it is possible to enable and disable the kernel smt
fix. If you can, you could enable the fix when you are running potential
threats, and disable it otherwise.
In the end, the kernel guys are right. If you always want to be safe,
you have to take the hit to processing by always running the smt fix.
How often do you max out all the cores on your system? That is, is the
reduction in processing a big deal for your use case?
11:56 a.m.
On 5/18/20 11:54 AM, stan via users wrote:
You should check if it is possible to enable and disable the kernel
smt
fix.
You mean disabling SMT ?
In the end, the kernel guys are right. If you always want to be safe,
you have to take the hit to processing by always running the smt fix.
How often do you max out all the cores on your system? That is, is the
reduction in processing a big deal for your use case?
I run VMs pretty often so
performance is kind of a big deal for me.
--
Regards,
Sreyan
12:22 p.m.
On Sun, 2020-05-24 at 22:26 +0530, Sreyan Chakravarty wrote:
On 5/18/20 11:54 AM, stan via users wrote:
> You should check if it is possible to enable and disable the kernel smt
> fix.
You mean disabling SMT ?
>
> In the end, the kernel guys are right. If you always want to be safe,
> you have to take the hit to processing by always running the smt fix.
> How often do you max out all the cores on your system? That is, is the
> reduction in processing a big deal for your use case?
I run VMs pretty often so performance is kind of a big deal for me.
I only run VMs for myself, not as a service, so I'm OK with the
potential risk, which I think is pretty remote. YMMV of course.
poc
1:27 p.m.
On Sun, 24 May 2020 22:26:44 +0530
Sreyan Chakravarty <sreyan32(a)gmail.com> wrote:
On 5/18/20 11:54 AM, stan via users wrote:
> You should check if it is possible to enable and disable the kernel
> smt fix.
You mean disabling SMT ?
If that is what the kernel configuration does, yes.
> In the end, the kernel guys are right. If you always want to
be
> safe, you have to take the hit to processing by always running the
> smt fix. How often do you max out all the cores on your system?
> That is, is the reduction in processing a big deal for your use
> case?
I run VMs pretty often so performance is kind of a big deal for me.
performance =><= risk
To put it simply: You can have zero risk with lower performance, or you
can have some level of risk with higher performance, but you cannot
have higher performance with zero risk.
You decide what you are comfortable with. In your situation, I would
take a few simple precautions that I described already, and run without
the kernel config. i.e. I would choose performance with some level of
risk. For what it is worth, I also think your risk is a lot less than
you think it is.
Below is tangential to the topic.
A psychological aside: We see in the covid19 pandemic that human beings
are very poor at evaluating comparative risk. By that, I mean that the
dollar value being placed on lives saved is very different for different
risks. Think automobile accident versus nuclear accident. Because of
the emotional (and political) response to the pandemic, we have placed
an especially high value for lives lost to it. I think you might be
exhibiting that human shortcoming in your response to this issue of
risk; there are probably higher risks in your life that you expose
yourself to without thought.
For anyone who thinks we can't place a dollar value on a human life, we
do it every day, and with our every decision, for ourselves. Search on
'cost of human life saved' for how it is officially done.
6:59 a.m.
On 5/15/20 1:03 AM, stan via users wrote:
If you are the only user on your machine, you almost certainly
don't
have to worry about this.
That is good to hear.
The main threat of this attack was on cloud servers where many
different users are running under virtual machines.
This is the problem. I do some CTF practice from Kali Linux and I also
have a Windows 10 VM to try out various untrusted or malicious software.
The main problem of this bug is that is breaks sandboxing. If it was
just a problem in the main OS, then it would be have been less alarming.
think for single use systems, Tom's response is the correct
one, but
you can worry if you want.
Yeah, but what about single user systems that run a fair
number of VMs ?
--
Regards,
Sreyan
8:30 a.m.
On Fri, 15 May 2020 17:29:31 +0530
Sreyan Chakravarty <sreyan32(a)gmail.com> wrote:
On 5/15/20 1:03 AM, stan via users wrote:
> If you are the only user on your machine, you almost certainly don't
> have to worry about this.
That is good to hear.
> The main threat of this attack was on cloud servers where many
> different users are running under virtual machines.
This is the problem. I do some CTF practice from Kali Linux and I
also have a Windows 10 VM to try out various untrusted or malicious
software.
Do those VMs have access to the internet? If they don't, they can't
communicate their results even if they do perform the attack. When the
VM closes, they lose all their results.
> think for single use systems, Tom's response is the
correct one,
> but you can worry if you want.
Yeah, but what about single user systems that run a fair number of
VMs ?
Well, unless you are the malicious attacker, they are still contained.
You have control of the VM.
And, if you don't run sensitive processes on the main machine while the
VM is running and testing, then there is no sensitive data for any
malicious attack to gather.
It can only gather data from a process running on the same core at the
same time. If your main system is idle while you are testing in the
virtual machine, there is nothing for it to gather.
To put your mind to rest, you will have to read the description of the
exploit, determine for yourself the conditions that allow it, and
prevent those conditions from occurring on your system. The simplest
way is to do as I describe above, only run software that might be
malicious in a VM (or on the main OS) while you are not doing sensitive
operations on the main OS or on another VM on the same core; sensitive
will primarily be surfing the web where you enter passwords for access.
2:51 p.m.
Do those VMs have access to the internet?
Yes they do.
And, if you don't run sensitive processes on the main machine while the
VM is running and testing, then there is no sensitive data for any
malicious attack to gather.
What about OS encryption keys related to LUKS ? And other things that are
in memory, like Thunderbird obviously stores my Gmail username and
password.
To put your mind to rest, you will have to read the description of the
exploit, determine for yourself the conditions that allow it, and
prevent those conditions from occurring on your system.
I am truing to learn as much as I can about the problem.
On Fri, May 15, 2020 at 7:01 PM stan via users <
users(a)lists.fedoraproject.org> wrote:
> On Fri, 15 May 2020 17:29:31 +0530
> Sreyan Chakravarty <sreyan32(a)gmail.com> wrote:
>
> > On 5/15/20 1:03 AM, stan via users wrote:
> > > If you are the only user on your machine, you almost certainly don't
> > > have to worry about this.
> > That is good to hear.
> > > The main threat of this attack was on cloud servers where many
> > > different users are running under virtual machines.
> >
> > This is the problem. I do some CTF practice from Kali Linux and I
> > also have a Windows 10 VM to try out various untrusted or malicious
> > software.
>
> Do those VMs have access to the internet? If they don't, they can't
> communicate their results even if they do perform the attack. When the
> VM closes, they lose all their results.
>
> > > think for single use systems, Tom's response is the correct one,
> > > but you can worry if you want.
> > Yeah, but what about single user systems that run a fair number of
> > VMs ?
>
> Well, unless you are the malicious attacker, they are still contained.
> You have control of the VM.
>
> And, if you don't run sensitive processes on the main machine while the
VM is running and testing, then there is no sensitive data for any
malicious attack to gather.
>
> It can only gather data from a process running on the same core at the
> same time. If your main system is idle while you are testing in the
> virtual machine, there is nothing for it to gather.
>
> To put your mind to rest, you will have to read the description of the
> exploit, determine for yourself the conditions that allow it, and
> prevent those conditions from occurring on your system. The simplest
> way is to do as I describe above, only run software that might be
> malicious in a VM (or on the main OS) while you are not doing sensitive
> operations on the main OS or on another VM on the same core; sensitive
> will primarily be surfing the web where you enter passwords for access.
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
>
--
Regards,
Sreyan Chakravarty
1:08 a.m.
On Mon, 18 May 2020 01:21:41 +0530
Sreyan Chakravarty <sreyan32(a)gmail.com> wrote:
What about OS encryption keys related to LUKS ? And other things
that
are in memory, like Thunderbird obviously stores my Gmail username and
password.
The attack only accesses things that pass through the L1 cache, so
things that are processed by the CPU while the attack is running.
The cache is small, so things don't hang around there, they are quickly
displaced by the running process. Unless you invoke something that
processes the information you ask about while the attack is running, it
won't be there.
1432
days inactive
1442
days old
24 comments
7 participants
participants (7)
-
George N. White III -
Patrick O'Callaghan -
Samuel Sieb -
Sreyan Chakravarty -
stan -
Thorsten Schubert -
Tom Horsley