On Sun, 24 May 2020 22:26:44 +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 ?
If that is what the kernel configuration does, yes.
> > In the end, the
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
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
On Mon, 18 May 2020 01:19:12 +0530
Sreyan Chakravarty 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
On Mon, 18 May 2020 01:21:41 +0530
Sreyan Chakravarty 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
>
> 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
>
> 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@lists.fedoraproject.org> wrote:
> On Fri, 15 May 2020 17:32:10 +0530
> Sreyan Chakravarty wrote:
>
> > On 5/15/20 1:32 AM, stan
On 5/15/20 4:55 AM, Sreyan Chakravarty wrote:
I am just curious, but how many of these vulnerabilities do you find on
AMD CPUs ?
Very few.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to
On Fri, 2020-05-15 at 17:37 +0530, Sreyan Chakravarty wrote:
> On 5/14/20 11:32 PM, Joe Zeff wrote:
> > On 05/14/2020 11:45 AM, Sreyan Chakravarty wrote:
> > > > Why? Just for asking a question about a potential problem you've
> > > > discovered on your machine?
> > > Have you seen how Linus
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
On Fri, 15 May 2020 17:29:31 +0530
Sreyan Chakravarty 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
On Fri, 15 May 2020 17:32:10 +0530
Sreyan Chakravarty 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
On Fri, 15 May 2020 17:34:43 +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
>
On Fri, 15 May 2020 at 09:12, Sreyan Chakravarty 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
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
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
On 5/14/20 11:32 PM, Joe Zeff wrote:
On 05/14/2020 11:45 AM, Sreyan Chakravarty wrote:
Why? Just for asking a question about a potential problem you've
discovered on your machine?
Have you seen how Linus and others responds to n00b mails ?
I don't follow such things, but I bet that how
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
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
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
On Thu, 14 May 2020 12:33:59 -0700
stan via users 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
On Thu, 14 May 2020 15:53:52 -0400
Tom Horsley 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.
>
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
On Thu, 14 May 2020 23:01:04 +0530
Sreyan Chakravarty 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
On Thu, May 14, 2020 at 7:31 PM Sreyan Chakravarty 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
On Thu, 14 May 2020 23:01:04 +0530
Sreyan Chakravarty wrote:
> Meanwhile, I wanted to know if any one here has the same problem and
> what they did for mitigations.
I mitigate by ignoring it :-). (Seeing as how there I nothing I can do
about it).
___
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
27 matches
Mail list logo