Re: [gentoo-user] Re: New Intel CPU flaws discovered

[Dale]

Nikos Chantziaras wrote:
> On 15/05/2019 18:25, Dale wrote:
>> If my system is off, how's it going to play videos?
>
> If your system is on, how is it going to replace vulnerable kernels
> with patched ones?
>
> Anyway, it's your system, not mine. I don't really care if you run
> vulnerable kernels or other software. I just wanted to inform you
> about it. If you choose to ignore well meant advice, that's fine.
> Again, I don't care. I was just trying to help.
>
>
>


I've been running a computer since 2003, mostly 24/7/365.  I've yet to
have anyone hack my system regardless of what kernel I'm using or its
age.  While I try to keep my system up to date when possible, I also
have to consider what my system is doing at the time.  Even doing major
updates or KDE updates requires timing.  Sometimes, I build the packages
but don't install them.  Then when I'm close to a point where I can
logout and back in, I then install the updates, which only takes a few
minutes since it is already compiled, and log out and back in.  Since
kernel updates require more, that takes more planning.

While I want to keep the bad CPU code from being used, they first have
to get past other things.  My DSL modem has protections, my router adds
yet another layer of it.  I use adblock, noscript and such on all my
browsers as well.  While I want to keep the CPU code clean, they still
have to get past all the rest first. 

I might also add, I'm having to use that init thingy since I have /usr
on a separate partition.  If I ever change drives, I'll likely remove
that and put it on /.  As some know, I have a bad history with those
init thingys and to be blunt, I hate the things and I tend to curse at
them quite often.  The only reason I use it is because I'm required to
do so.  Until it was required, I avoided it like it was the plague or
something even worse.  Since rebooting is when those tend to
fail/break/whatever, it is yet another reason I avoid rebooting.  Even
when I have a power fail here, it makes me very nervous to shutdown. 
There is always a chance of hardware problems, such as a fan failing to
spin up, but those don't bother near as much as when I'm watching to see
if that init thingy fails or not.  Even if my system sat idle the
majority of the time, I'd avoid rebooting/shutting down just because of
the init thingy.  My system when idle pulls very little power.  I've got
light bulbs that pull more than my puter.  Most of the time, I just
don't have a good reason to reboot. 

The biggest thing, this system is in use almost all the time.  It's
either playing video on my TV, downloading things or both.  I also check
my email very often since that is how most people contact me, my cell
phone signal is poor at best since I live under a large hill. 

For most people your advice is likely good advice.  For those who don't
protect their systems with other tools, it is very good advice.  I've
compiled the new kernel as suggested and when I reboot, I'll try the new
kernel and see how it does.  It's rare that the kernel itself gives me
issues but there has been a time or two when I've had to go back to a
old one, left out something that has to be there for example.  It's
getting that time of year so a reboot/shutdown will likely happen soon
enough.  I expect a more stormy summer, gut feeling thing.  It's May and
I would not risk even driving the tractor in my garden.  Usually by now,
it is planted and stuff is blooming and about ready to pick.  It's still
full of weeds and VERY wet. 

Now that I'm back from town, let me go see how much it downloaded while
I was shopping.  o_O 

Dale

:-)  :-) 

Re: [gentoo-user] Re: New Intel CPU flaws discovered

[Andrew Savchenko]

On Wed, 15 May 2019 18:42:03 +0300 Nikos Chantziaras wrote:
> On 15/05/2019 18:25, Dale wrote:
> > If my system is off, how's it going to play videos?
> 
> If your system is on, how is it going to replace vulnerable kernels with 
> patched ones?

It is possible to use kernel live patching, see [1] for details.
Most kernel bugfixes are available that way. I have not checked MDS
problem however.

[1] https://wiki.gentoo.org/wiki/Elivepatch

Best regards,
Andrew Savchenko


pgpxo2ldPrmiZ.pgp
Description: PGP signature

[gentoo-user] Re: New Intel CPU flaws discovered

[Nikos Chantziaras]

On 15/05/2019 18:25, Dale wrote:

If my system is off, how's it going to play videos?


If your system is on, how is it going to replace vulnerable kernels with 
patched ones?


Anyway, it's your system, not mine. I don't really care if you run 
vulnerable kernels or other software. I just wanted to inform you about 
it. If you choose to ignore well meant advice, that's fine. Again, I 
don't care. I was just trying to help.

Re: [gentoo-user] Re: New Intel CPU flaws discovered

[Dale]

Nikos Chantziaras wrote:
> On 15/05/2019 13:14, Dale wrote:
>> Thanks much for the info.  That was my thinking but I have been wrong
>> before, more than I may even know about at times.  ;-)  I'll work on
>> updating my kernel but I rarely reboot.
>
> You make it sound like something to be proud of, even though it's just
> foolishness.
>
> Update your software and reboot. Not rebooting is not an achievement
> whatsoever.
>
>
>


It's mostly convenience for me.  My system is almost always doing
something, more than one thing at that.  It's been that way for years. 
Right now, I'm downloading videos which is one thing it is doing a lot
of.  See previous thread about updating my system with larger hard
drives if you are interested.  Right now, according to the download
tool, it will be downloading for the next 4 hours or so.  When it gets
down to about the last 30 minutes or so, I'll start a fresh batch. 
Also, I use my system to watch TV.  If my system is off, how's it going
to play videos? 

What may be foolish to you is not to me.  It's practical.  I use my
computer more than I do anything else.  It's always on because I'm
almost always doing something with it, even if I'm asleep or gone to
town.  So while in your opinion it may be foolish, in mine, it is not. 

I might add, there are threads on forums talking about uptimes, some a
lot longer than mine.  I recall one posting his had been up for years. 
He stuck a old system in a closet, used it but since it was out of
sight, never thought to reboot or even blow the dust out of it.  He
actually was cleaning out the closet, to move if I recall correctly,
when he noticed it.  I can't recall what it was used for but think it
was some sort of file server.  It's uptime was over 5 years.  He was
proud of its uptime and the fact it still worked given it was a dust
bunny. 

To each his own.  For me tho, I actually use my system a LOT. 

Dale

:-)  :-) 

[gentoo-user] Re: New Intel CPU flaws discovered

[Nikos Chantziaras]

On 15/05/2019 13:14, Dale wrote:
Thanks much for the info.  That was my thinking but I have been wrong 
before, more than I may even know about at times.  ;-)  I'll work on 
updating my kernel but I rarely reboot.


You make it sound like something to be proud of, even though it's just 
foolishness.


Update your software and reboot. Not rebooting is not an achievement 
whatsoever.

Re: [gentoo-user] Re: New Intel CPU flaws discovered

[Rich Freeman]

On Wed, May 15, 2019 at 6:01 AM Adam Carter  wrote:
>
>> Am I correct to think that "Mitigation" is good enough or does that mean it 
>> could be affected in some other way or is risky?
>
> I accept Mitigation as good enough.

I'm not sure what alternative there would be...  :)

Everything reported in this directory is a CPU hardware vulnerability.
If it reports that a CPU is not affected, then the CPU hardware
doesn't contain the vulnerability and there is no way to exploit it on
any OS/application/hypervisor/whatever.  If it reports that it is
vulnerable, then exploits can be run right now and the Linux kernel
won't be doing anything to stop them, or can only mount an incomplete
defense.

If a vulnerability is not listed at all it means that it either
doesn't apply to the architecture, or the kernel doesn't know about
it.  In the latter case you may or may not be vulnerable - the kernel
simply doesn't know about it so if the underlying hardware contains
the vulnerability then there will be no protection against it.

The last state that is reported is mitigation followed by some detail.
This means that your underlying cpu hardware contains the
vulnerability, but the Linux kernel is applying some software
mitigation to prevent it from being exploited.  Generally this means
that you aren't vulnerable in practice as long as you're running this
particular kernel.  Sometimes there might be more than one mitigation
approach available and some of them might incur more of a performance
penalty than others.  However, if the kernel reports mitigated then it
is the opinion of the kernel devs that you are not vulnerable.  You
might not be getting the best performance out of your CPU, but exploit
code will not work.

There are some vulnerabilities that will be reported as vulnerable,
but with some additional partial mitigation reported.  The overall
message will start with vulnerable in this case with some detail
following, such as:
 "spectre_v2:Vulnerable: Minimal generic ASM retpoline"
In these cases the kernel devs have started to fix a vulnerability,
but in their judgment the problem isn't fully resolved.  This might
happen when a vulnerability is first discovered, or if a microcode
update isn't available and there isn't a workaround yet.  In the
latter case a more expensive workaround might eventually be developed
and used if the microcode update isn't installed as a fallback.

In general the kernel team prioritizes security over performance.  CPU
hardware vulnerabilities will often cost you something in performance,
but if you're running the latest kernel and it doesn't report any
problems then there shouldn't be any actual exploits.

I have heard of datacenter admins seriously contemplating turning off
some of the mitigations because of their performance cost.  If you're
running customer-provided VMs that is obviously not a reasonable
approach, but if you're doing HPC in a highly-controlled datacenter,
then the local priv escalation attacks may not be as much of a concern
as needing to go out and rapidly buy/install another 200 hosts and the
infrastructure needed to run them if preserving job execution time is
critical.

-- 
Rich

Re: [gentoo-user] Re: New Intel CPU flaws discovered

[Dale]

Adam Carter wrote:
>
> This appears to be OK on my CPU but want to ask to be sure.  
> Here's some info, sort of taking cues from what you posted above.
>
>
> root@fireball / # uname -a
> Linux fireball 4.18.12-gentoo #1 SMP PREEMPT Sun Oct 14 23:45:12
> CDT 2018 x86_64 AMD FX(tm)-8350 Eight-Core Processor AuthenticAMD
> GNU/Linux
> root@fireball / # cat /sys/devices/system/cpu/vulnerabilities/
> l1tf   meltdown   spec_store_bypass 
> spectre_v1 spectre_v2
> root@fireball / # cat
> /sys/devices/system/cpu/vulnerabilities/meltdown
> Not affected
> root@fireball / # cat /sys/devices/system/cpu/vulnerabilities/l1tf
> Not affected
> root@fireball / # cat
> /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
> Mitigation: Speculative Store Bypass disabled via prctl and seccomp
> root@fireball / # cat
> /sys/devices/system/cpu/vulnerabilities/spectre_v1
> Mitigation: __user pointer sanitization
> root@fireball / # cat
> /sys/devices/system/cpu/vulnerabilities/spectre_v2
> Mitigation: Full AMD retpoline
> root@fireball / #
>
>
> You're missing the /sys/devices/system/cpu/vulnerabilities/mds file
> because only the latest kernels from 2019-05-14 have that check. The
> 4.18 line has gone away so you'd have to go to 4.19.43 to get it.
> Since you're an AMD cpu, you don't need to worry about mds, but if I
> were you i'd move to 4.19.43 anyway as you want to stay on a supported
> version. 4.19 is "longterm" (https://www.kernel.org/) so its a good
> option. Then if something serious comes up, an update from 4.19.x to
> 4.19.y is much less trouble than 4.18 to 4.19. 
>
> Am I correct to think that "Mitigation" is good enough or does
> that mean it could be affected in some other way or is risky? 
>
>
> I accept Mitigation as good enough. The kernel devs seem to choose a
> good balance between secure and fast. Anything that says 'vulnerable'
> is a problem, but you may have to live with it until a new microcode
> or kernel update arrives. Or if the CPU vendor is not making a
> microcode update for an old CPU, just live with it or upgrade the
> hardware. On my skylake box I need to think about disabling
> Hyperthreading or not, disabled is secure but halves the core count..
>  
>
> Also, since the problem that this thread is about isn't listed,
> mine isn't affected correct? 
>
>
> Covered above.
>  
>
> I'm guessing "Not affected" means all is good.  ;-) 
>
>
> Indeed!
>


Thanks much for the info.  That was my thinking but I have been wrong
before, more than I may even know about at times.  ;-)  I'll work on
updating my kernel but I rarely reboot.  Most of my reboots occurs when
power is lost, usually severe storms or something.  They upgraded the
main lines several years ago so it takes something pretty bad to take
out power long enough that I have to shutdown.  We do get the occasional
blinks during storms or high winds tho.  They just don't last long
enough since the UPS catches that. 

Kernel 4.19.  Going to emerge that and see what I can do.  At least it
will be a option when I reboot next time.

Dale

:-)  :-)


root@fireball / # uprecords
 #   Uptime | System
Boot up
+---
   1   303 days, 11:46:23 | Linux 4.5.2-gentoo    Sat Jul 29
23:20:27 2017
   2   193 days, 09:28:37 | Linux 3.5.3-gentoo    Sat Sep 22
07:50:38 2012
   3   184 days, 15:47:57 | Linux 3.18.7-gentoo   Tue Dec 15
21:53:59 2015
   4   143 days, 15:05:26 | Linux 4.5.2-gentoo    Sun Oct 23
20:09:26 2016
   5   138 days, 11:27:28 | Linux 4.5.2-gentoo    Tue May 29
13:27:44 2018
   6   135 days, 11:11:44 | Linux 4.5.2-gentoo    Thu Mar 16
11:58:17 2017
->   7   123 days, 00:28:59 | Linux 4.18.12-gentoo  Sat Jan 12
03:42:55 2019
   8   116 days, 16:24:24 | Linux 3.16.3-gentoo   Mon Oct 13
20:27:52 2014
   9   111 days, 00:34:49 | Linux 3.18.7-gentoo   Tue Mar 31
18:57:19 2015
  10   101 days, 18:34:17 | Linux 3.5.3-gentoo    Wed Dec 31
18:00:00 1969

Re: [gentoo-user] Re: New Intel CPU flaws discovered

[Adam Carter]

>
> This appears to be OK on my CPU but want to ask to be sure.   Here's some
> info, sort of taking cues from what you posted above.
>
>
> root@fireball / # uname -a
> Linux fireball 4.18.12-gentoo #1 SMP PREEMPT Sun Oct 14 23:45:12 CDT 2018
> x86_64 AMD FX(tm)-8350 Eight-Core Processor AuthenticAMD GNU/Linux
> root@fireball / # cat /sys/devices/system/cpu/vulnerabilities/
> l1tf   meltdown   spec_store_bypass
> spectre_v1 spectre_v2
> root@fireball / # cat /sys/devices/system/cpu/vulnerabilities/meltdown
> Not affected
> root@fireball / # cat /sys/devices/system/cpu/vulnerabilities/l1tf
> Not affected
> root@fireball / # cat
> /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
> Mitigation: Speculative Store Bypass disabled via prctl and seccomp
> root@fireball / # cat /sys/devices/system/cpu/vulnerabilities/spectre_v1
> Mitigation: __user pointer sanitization
> root@fireball / # cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
> Mitigation: Full AMD retpoline
> root@fireball / #
>

You're missing the /sys/devices/system/cpu/vulnerabilities/mds file because
only the latest kernels from 2019-05-14 have that check. The 4.18 line has
gone away so you'd have to go to 4.19.43 to get it. Since you're an AMD
cpu, you don't need to worry about mds, but if I were you i'd move to
4.19.43 anyway as you want to stay on a supported version. 4.19 is
"longterm" (https://www.kernel.org/) so its a good option. Then if
something serious comes up, an update from 4.19.x to 4.19.y is much less
trouble than 4.18 to 4.19.

Am I correct to think that "Mitigation" is good enough or does that mean it
> could be affected in some other way or is risky?
>

I accept Mitigation as good enough. The kernel devs seem to choose a good
balance between secure and fast. Anything that says 'vulnerable' is a
problem, but you may have to live with it until a new microcode or kernel
update arrives. Or if the CPU vendor is not making a microcode update for
an old CPU, just live with it or upgrade the hardware. On my skylake box I
need to think about disabling Hyperthreading or not, disabled is secure but
halves the core count..


> Also, since the problem that this thread is about isn't listed, mine isn't
> affected correct?
>

Covered above.


> I'm guessing "Not affected" means all is good.  ;-)
>

Indeed!

Re: [gentoo-user] Re: New Intel CPU flaws discovered

[Dale]

Adam Carter wrote:
> On Wed, May 15, 2019 at 3:26 PM Adam Carter  > wrote:
>
> Here we go again;
> https://mdsattacks.com/
>
> 
> Sounds like AMD not affected.
>
>
> AMD looks good;
> $ uname -a
> Linux proxy 5.1.2-gentoo #2 SMP Wed May 15 16:39:53 AEST 2019 x86_64
> AMD Phenom(tm) II X4 965 Processor AuthenticAMD GNU/Linux
> $ cat /sys/devices/system/cpu/vulnerabilities/mds
> Not affected
>
> $ uname -a
> Linux phat 5.1.2-gentoo #1 SMP Wed May 15 16:31:06 AEST 2019 x86_64
> AMD FX(tm)-8350 Eight-Core Processor AuthenticAMD GNU/Linux
> $ cat /sys/devices/system/cpu/vulnerabilities/mds
> Not affected
>
> But the skylake;
> $ uname -a
> Linux nuc 5.1.2-gentoo #2 SMP Wed May 15 16:35:17 AEST 2019 x86_64
> Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz GenuineIntel GNU/Linux
> $ cat /sys/devices/system/cpu/vulnerabilities/mds
> Mitigation: Clear CPU buffers; SMT vulnerable
>


This appears to be OK on my CPU but want to ask to be sure.   Here's
some info, sort of taking cues from what you posted above.


root@fireball / # uname -a
Linux fireball 4.18.12-gentoo #1 SMP PREEMPT Sun Oct 14 23:45:12 CDT
2018 x86_64 AMD FX(tm)-8350 Eight-Core Processor AuthenticAMD GNU/Linux
root@fireball / # cat /sys/devices/system/cpu/vulnerabilities/
l1tf   meltdown   spec_store_bypass 
spectre_v1 spectre_v2
root@fireball / # cat /sys/devices/system/cpu/vulnerabilities/meltdown
Not affected
root@fireball / # cat /sys/devices/system/cpu/vulnerabilities/l1tf
Not affected
root@fireball / # cat
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
Mitigation: Speculative Store Bypass disabled via prctl and seccomp
root@fireball / # cat /sys/devices/system/cpu/vulnerabilities/spectre_v1
Mitigation: __user pointer sanitization
root@fireball / # cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full AMD retpoline
root@fireball / #



Am I correct to think that "Mitigation" is good enough or does that mean
it could be affected in some other way or is risky?  Also, since the
problem that this thread is about isn't listed, mine isn't affected
correct?  I'm guessing "Not affected" means all is good.  ;-) 

Thanks much.  Just want to be sure my system is safe. 

Dale

:-)  :-) 

[gentoo-user] Re: New Intel CPU flaws discovered

[Adam Carter]

On Wed, May 15, 2019 at 3:26 PM Adam Carter  wrote:

> Here we go again;
> https://mdsattacks.com/
>
> 
> Sounds like AMD not affected.
>

AMD looks good;
$ uname -a
Linux proxy 5.1.2-gentoo #2 SMP Wed May 15 16:39:53 AEST 2019 x86_64 AMD
Phenom(tm) II X4 965 Processor AuthenticAMD GNU/Linux
$ cat /sys/devices/system/cpu/vulnerabilities/mds
Not affected

$ uname -a
Linux phat 5.1.2-gentoo #1 SMP Wed May 15 16:31:06 AEST 2019 x86_64 AMD
FX(tm)-8350 Eight-Core Processor AuthenticAMD GNU/Linux
$ cat /sys/devices/system/cpu/vulnerabilities/mds
Not affected

But the skylake;
$ uname -a
Linux nuc 5.1.2-gentoo #2 SMP Wed May 15 16:35:17 AEST 2019 x86_64 Intel(R)
Core(TM) i3-6100U CPU @ 2.30GHz GenuineIntel GNU/Linux
$ cat /sys/devices/system/cpu/vulnerabilities/mds
Mitigation: Clear CPU buffers; SMT vulnerable