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

[Paul Colquhoun]

On Saturday, May 18, 2019 11:01:30 P.M. AEST Wols Lists wrote:
> On 17/05/19 06:19, Andrew Udvare wrote:
> >> On May 17, 2019, at 01:14, Adam Carter  wrote:
> >> 
> >> The classic one is where OPS haven't noticed that disks in a RAID array
> >> have died years ago...> 
> > This really happened?
> 
> It's probably more common than you think.
> 
> Can't tell (don't really know) the details, but I was told a story first
> hand about someone who went in to the computer room and asked "what are
> those flashing red lights?"
> 
> Cue massive panic as ops suddenly realised that (a) it was the main
> billing server with terabytes of critical information and (b) the two
> flashing lights meant their terribly expensive raid-6 disk array was now
> running in raid-0!


And the even bigger worry would be that a drive replacement and rebuild, which 
is the whole point of using RAID, may fail. The degraded RAID is working (so 
far) but a rebuild (unless it is *very* file system aware) needs to read EVERY 
BLOCK on the existing disks to rebuild the failed drive/s, and if it 
encounters any failed blocks in unused areas of the RAID it may be unable to 
complete the rebuild.

I have seen this happen in previous positions. Not an easy thing to report to 
management, and the unexpected downtime to rebuild everything from backups 
onto new drives can be extensive (and expensive).

This is why good RAID systems have a background task that regularly reads and 
checks every block of every disk, to avoid undetected errors.

Hot Spares are also a good safety measure, along with monitoring software that 
alerts you when the spares have gone live.


-- 
Reverend Paul Colquhoun, ULC. http://andor.dropbear.id.au/
  Asking for technical help in newsgroups?  Read this first:
 http://catb.org/~esr/faqs/smart-questions.html#intro

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

[Mick]

On Saturday, 18 May 2019 02:25:58 BST Frank Steinmetzger wrote:

> At some point in the future, my stationary PC will require a hardware
> refresh. At that point I will say goodbye to Intel. This is the only
> language companies understand. 

Yes, Intel has been permanently erased as an option for any future computer 
purchases of mine.

However, in the current oligopoly of hardware suppliers and their market carve 
up, there isn't much/any choice for the retail consumer. The only CPU which 
does not come with ME/PSP hardware backdoors built-in by design, is the 
POWER9, which is an expensive server CPU.  No choice for laptops.

Unless big OEMs like Apple start exerting pressure on the CPU manufacturers to 
secure their designs, I can't see them changing their strategy just because an 
infinitesimally small number of users stopped buying their products.


> They’ve been getting ahead by developing
> features without due diligence and by cutting corners. And this is biting
> them in their behind now all the way back.

It's not just a matter of cutting corners and trying to remain competitive by 
being first to market with shoddy products.  They have also consciously 
decided to incorporate  co-processors (OOB hypervisors) in their 
chips, with no option of physically removing these, or at least fully 
disabling or replacing the proprietary firmware blobs they have been running.  
The concept of 'secure computing' with today's market offerings is increasing 
showing itself to be an oxymoron.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

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

[Wols Lists]

On 17/05/19 06:19, Andrew Udvare wrote:
>> On May 17, 2019, at 01:14, Adam Carter  wrote:
>>
>> The classic one is where OPS haven't noticed that disks in a RAID array have 
>> died years ago...
> 
> This really happened?
> 
It's probably more common than you think.

Can't tell (don't really know) the details, but I was told a story first
hand about someone who went in to the computer room and asked "what are
those flashing red lights?"

Cue massive panic as ops suddenly realised that (a) it was the main
billing server with terabytes of critical information and (b) the two
flashing lights meant their terribly expensive raid-6 disk array was now
running in raid-0!

Cheers,
Wol

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

[Frank Steinmetzger]

On Wed, May 15, 2019 at 01:53:45PM -0500, Dale wrote:
> Nikos Chantziaras wrote:
> > […]
> > If your system is on, how is it going to replace vulnerable kernels
> > with patched ones?

> […]
>
> 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.

I’m kinda on the same train of thought. All those vulnerabilities of recent
years are about data exfiltration through cross-process memory reads or
exploitation of caching mechanisms for instruction optimisations. The threat
scenario is mostly relevant for servers which run unverified processes of
any number of users which may be trying to attack other users’ processes.

On a personal computer, nowadays the most common point of entry for malware
is the browser (or a manipulated data file for any kind of parser bug such
as Adobe or M$ Office). And in the browser, the threat comes from active
elements, IOW, Ecma Script. I use uMatrix with strict defaults, scripts are
only enabled when actually needed. And opposed to often-heard street talk,
you can still use many corners of the Web without JS in many cases.
And of course I don’t blindly extract any ace archive that pretends to be a
rar.

Linux doesn’t “support” Windows crapware, and as long as you are careful
about where you get your programs from (i.e. package manager and other
trustworthy sources), you are reasonably safe, as opposed from Joe
Average-Windows-User who loads Adobe Reader and Google Chrome from
free-full-version-software.com instead of the developer’s official website
because he simply doesn’t know any better.

So I might not be as safe as technically possible, but right now I’m grown
tired of following which fix incurs what performance penalty and don’t
really give a crap. I set mitigations=off to my cmdline and watch the Tech
media burn itself down in a spiral of hysteria. In the meantime I protect
myself by (hopefully) knowing what each of my actions does and by using
software that uses common sense and provides a small attack surface, for
example mutt and vim instead of HTML mail and a text editor based on an
entire browser engine.

At some point in the future, my stationary PC will require a hardware
refresh. At that point I will say goodbye to Intel. This is the only
language companies understand. They’ve been getting ahead by developing
features without due diligence and by cutting corners. And this is biting
them in their behind now all the way back.

-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

There is only one way to the lung and it must be tarred.


signature.asc
Description: PGP signature

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

[Dale]

Mick wrote:
> On Friday, 17 May 2019 09:43:46 BST Dale wrote:
>
>> My problems with init thingys date all the way back to to the Mandrake
>> 9.1 days when I first used Linux.
> I was never a Mandrake user, but also avoided using an initrd unless it came 
> with a binary distro - at which point I would also expect it to Just-Work(TM).
>
> The world has moved on since Mandrake 9.x and the generation of initramfs is 
> a 
> much more automated and reliable process now.

I was not that lucky with Mandrake.  I stopped counting the number of
times the init thingy failed.  It got to a point where I would not
update Mandrake, I would download a new CD and reinstall only leaving
/home untouched.  Even then, with some dodgy hardware, rebooting was not
something I looked forward to. 


>
> Regarding a separate /usr fs necessitating initramfs, it shouldn't be too 
> difficult to plan some downtime, reboot with Live-media and move the /usr fs 
> contents into /, following any required partition modifications.  Unless of 
> course you *want* to keep /usr separate for mounting it as read-only, or 
> sharing it among multiple OS, in which case I don't think you can escape 
> initramfs.
>
> The downtime for rebooting a new kernel is measured in seconds.  Even if the 
> new kernel fails, you can fallback onto the previous kernel and boot that in 
> seconds.
>

As I posted earlier, if I ever replace the hard drive, with a SDD most
likely, that is the plan.  With a SDD there is little need to have a
separate partition.  I may still make /var separate tho, since I've had
logs go crazy and fill it up before.  Having /var fill up is less of a
problem than / filling up.


>> As to hardware, I had one time where that was a issue.  Power failed and
>> a shutdown was needed.  When I went to power back up, the CPU fan
>> wouldn't spin up.  After a couple drops of oil was added, it was
>> spinning up again and of course, I ordered a replacement fan right
>> away.  I don't recall ever having any other hardware problem.  
> Count yourself lucky.  You could have discovered your disk wouldn't spin up 
> again, your PSU packed up, or even the MoBo chipset decided to retire from 
> active service.  Eventually, any of these hardware problems would manifest 
> themselves, but a reboot could reveal their demise sooner and hopefully at a 
> point where you were somewhat prepared for it.
>

As I posted, I've had a fan to fail, that's it.  Thing is, at the moment
I'm not prepared for any of that but when things age, I replace them. 
Of course, that really requires planning and is one reason I wouldn't
mind having a second system.  Thing is, if I'm running, it is working. 
Avoiding reboots avoids those issues.  Rebooting only forces them to
show up sooner, which I don't want.  I'm not sure how making something
fail sooner is really going to help anything.  If making something fail
sooner is the answer, never change oil in your car.  ROFL 

Dale

:-)  :-) 

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

[Dale]

Rich Freeman wrote:
> On Fri, May 17, 2019 at 6:28 AM Mick  wrote:
>> Count yourself lucky.  You could have discovered your disk wouldn't spin up
>> again, your PSU packed up, or even the MoBo chipset decided to retire from
>> active service.  Eventually, any of these hardware problems would manifest
>> themselves, but a reboot could reveal their demise sooner and hopefully at a
>> point where you were somewhat prepared for it.
>>
> ++
>
> You can't completely prevent reboots (not unless you are willing to
> spend big and go mainframe or something like that - and those create a
> different set of issues).  What you can do is take steps to reduce the
> risk that an unplanned reboot will cause problems.
>
> One of the best ways to ensure you're prepared for disaster is to make
> disaster routine.  Regular reboots can be a part of this, because you
> can do them at a time when you have time to deal with problems, and
> when you're looking for problems.
>
> This is why I've made the move to containers largely.  I still have a
> few processes running on my host because, but almost everything has
> moved into containers that do one thing.  When I update a container I
> take a snapshot, run updates, shut it down, take another snapshot,
> start it up, and test the service it runs.  Since each container only
> does one thing, I know exactly what to test.  If it works I'm good,
> and if it doesn't work I can roll it back and not worry about what
> that might break on the 47 other services running on the same host.
> Every update involves an effective reboot for that one service, so I
> know that in the event of a host reboot they will generally all come
> up fine.  I of course update the host regularly and reboot that for
> kernel updates, which seem to come about twice a week these days
> anyway.
>
> Obviously I don't run updates the day before I leave on vacation,
> unless they are security critical, and then I exercise some care.
>
> The downside is that I end up with a lot more hosts to keep up to
> date, because I can't just run emerge -u world once on one host and
> have every service I run updated.  However, I gladly accept the extra
> work because the work itself becomes much simpler and predictable.  If
> I'm updating my imapd container and imapd still works, then I'm fine.
> I don't have to worry about suddenly realizing two days later that
> postgrey is bouncing a ton of mail or whatever.  If something obscure
> like a text editor breaks in my imapd container which I didn't catch,
> that might be an annoyance but it doesn't really impact me much since
> it isn't critical for the operation of that container.
>


But none of this changes one main point, my system is in use virtually
all the time.  A KDE upgrade has been ready for a while.  While waiting
for time to log out and back in, yet another KDE upgrade came
available.  So, I ended up with two updates that were ready.  Still, it
took me a couple days to get to a stopping point where I could log out
and back in again.  Even restarting Firefox gets on my nerve at times. 
I've even learned how to figure out what tab is going wacky so that I
can either close it or reload it to reset it to correct either a high
CPU usage problem or it using a large amount of memory.  Again, if it is
in the middle of a download that may lack hours of download, I can't
just close it without losing what I've already downloaded. 

Even with that, I still didn't want to risk rebooting and having any
sort of failure, no matter what it was.  As I pointed out, I can't think
of anything that a person can post that will change how I use my
system.  One thing I have considered, building a second system and use
that to at least play my videos to the TV with.  Still, I download a lot. 

Until how I use my system changes, init thingy or not, it is still
difficult to find time to reboot.  Add in the risk of it all, since I do
not trust the init thingy, that just adds to the issue. 

Dale

:-)  :-) 

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

[Rich Freeman]

On Fri, May 17, 2019 at 6:28 AM Mick  wrote:
>
> Count yourself lucky.  You could have discovered your disk wouldn't spin up
> again, your PSU packed up, or even the MoBo chipset decided to retire from
> active service.  Eventually, any of these hardware problems would manifest
> themselves, but a reboot could reveal their demise sooner and hopefully at a
> point where you were somewhat prepared for it.
>

++

You can't completely prevent reboots (not unless you are willing to
spend big and go mainframe or something like that - and those create a
different set of issues).  What you can do is take steps to reduce the
risk that an unplanned reboot will cause problems.

One of the best ways to ensure you're prepared for disaster is to make
disaster routine.  Regular reboots can be a part of this, because you
can do them at a time when you have time to deal with problems, and
when you're looking for problems.

This is why I've made the move to containers largely.  I still have a
few processes running on my host because, but almost everything has
moved into containers that do one thing.  When I update a container I
take a snapshot, run updates, shut it down, take another snapshot,
start it up, and test the service it runs.  Since each container only
does one thing, I know exactly what to test.  If it works I'm good,
and if it doesn't work I can roll it back and not worry about what
that might break on the 47 other services running on the same host.
Every update involves an effective reboot for that one service, so I
know that in the event of a host reboot they will generally all come
up fine.  I of course update the host regularly and reboot that for
kernel updates, which seem to come about twice a week these days
anyway.

Obviously I don't run updates the day before I leave on vacation,
unless they are security critical, and then I exercise some care.

The downside is that I end up with a lot more hosts to keep up to
date, because I can't just run emerge -u world once on one host and
have every service I run updated.  However, I gladly accept the extra
work because the work itself becomes much simpler and predictable.  If
I'm updating my imapd container and imapd still works, then I'm fine.
I don't have to worry about suddenly realizing two days later that
postgrey is bouncing a ton of mail or whatever.  If something obscure
like a text editor breaks in my imapd container which I didn't catch,
that might be an annoyance but it doesn't really impact me much since
it isn't critical for the operation of that container.

-- 
Rich

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

[Mick]

On Friday, 17 May 2019 09:43:46 BST Dale wrote:

> My problems with init thingys date all the way back to to the Mandrake
> 9.1 days when I first used Linux.

I was never a Mandrake user, but also avoided using an initrd unless it came 
with a binary distro - at which point I would also expect it to Just-Work(TM).

The world has moved on since Mandrake 9.x and the generation of initramfs is a 
much more automated and reliable process now.

Regarding a separate /usr fs necessitating initramfs, it shouldn't be too 
difficult to plan some downtime, reboot with Live-media and move the /usr fs 
contents into /, following any required partition modifications.  Unless of 
course you *want* to keep /usr separate for mounting it as read-only, or 
sharing it among multiple OS, in which case I don't think you can escape 
initramfs.

The downtime for rebooting a new kernel is measured in seconds.  Even if the 
new kernel fails, you can fallback onto the previous kernel and boot that in 
seconds.


> As to hardware, I had one time where that was a issue.  Power failed and
> a shutdown was needed.  When I went to power back up, the CPU fan
> wouldn't spin up.  After a couple drops of oil was added, it was
> spinning up again and of course, I ordered a replacement fan right
> away.  I don't recall ever having any other hardware problem.  

Count yourself lucky.  You could have discovered your disk wouldn't spin up 
again, your PSU packed up, or even the MoBo chipset decided to retire from 
active service.  Eventually, any of these hardware problems would manifest 
themselves, but a reboot could reveal their demise sooner and hopefully at a 
point where you were somewhat prepared for it.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

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

[Dale]

Adam Carter wrote:
>
> something even worse.  Since rebooting is when those tend to
> fail/break/whatever, it is yet another reason I avoid rebooting.  
>
>
> I take the opposite approach. If I update the kernel and reboot often,
> I see the following benefits;
> - Each increment in version is smaller, therefore there's less change
> per update, which make it easier to troubleshoot if there's problems
> - Doing something regularly is practice, and practice makes perfect.
> If you were to update regularly you would become more proficient and
> confident with doing the init thingy (initrd?)
> - If a hardware issue occurs, I find it at a good time when i'm not
> busy, and have the time to troubleshoot
> - Getting the benefits of the automated kernel code testing (eg
> syzbot, KASAN) that is used these days finding issues that then get
> fixed (including security issues). You'd have to assume that over the
> overall quality of the kernel is improving at a faster rate now than
> before those extra checks were in place.
>  
> At work I have raised tickets to have systems with big uptimes have
> their hardware status reviewed then restarted, a couple of days before
> I undertake risky/critical work. That way I can have more confidence
> in the system's health before starting. The classic one is where OPS
> haven't noticed that disks in a RAID array have died years ago...
>
> Even when I have a power fail here, it makes me very nervous to
> shutdown. 
>
>
> Another benefit of regular updates would be to reduce stress of
> deciding to shutdown, as you will have more confidence that the
> systems are healthy when you need to do it.
>
> :)


My problems with init thingys date all the way back to to the Mandrake
9.1 days when I first used Linux.  At that time, I didn't make the init
thingys at all, the OS did that during install or updates.  Still, they
would work but eventually a update or something would break them which
left me with a unbootable OS.  After a few times with that, I grew to
hate the init thingys and have hated them ever since.  It is just one
more thing that tends to fail and since it shouldn't really even be
needed, since it wasn't for many years, I would rather not have one at
all.  I find it odd that I can build a kernel from scratch that boots
and works on the first try but that silly init thingy seems to cause
problems even when not messed with.  I might add, the init thingy is one
reason I left Mandrake.  Gentoo didn't require the stupid thing and for
years when I didn't have one, rebooting wasn't a issue since I was
confident my kernels would work.  After all, even back then, I didn't
change or update the kernels that often. 

As to hardware, I had one time where that was a issue.  Power failed and
a shutdown was needed.  When I went to power back up, the CPU fan
wouldn't spin up.  After a couple drops of oil was added, it was
spinning up again and of course, I ordered a replacement fan right
away.  I don't recall ever having any other hardware problem.  Thing is,
even if I had shutdown a week earlier, that fan may have worked fine. 
Who knows when it would have eventually failed. 

As I also said, my system is almost always doing something I need it to
do.  It is doing things that it can't do if I'm rebooting or shutting
down.  It is certainly something it can't do if it us unable to boot due
to a broken init thingy.  If I wanted a system that required rebooting
on a regular basis to work, I'd be using windoze not Linux.  Reboots
frequently fixes windoze issues but doesn't usually do so with Linux. 

As I said before, for some the advice is good advice.  For me, it is
not.  It is counterproductive even for me in my use case.  I can't think
of anything that will be changing that either.  If how I use my system
changes, that may change things.

Dale

:-)  :-)

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

[Adam Carter]

> Yep, and not just to Adam.  I had to ask support twice to check their
> array
> because performance was degraded, but they preferred to blame (my) network
> for
> it.  So much for keeping an eye on monitoring kit for their storage.
>
>
Systems guys blame the network, network guys blame the firewall. I just ask
"what evidence do you have there is a network/firewall problem?". That
question is troubling if you haven't done your homework before blaming
someone else.

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

[Mick]

On Friday, 17 May 2019 06:48:28 BST Adam Carter wrote:
> > > The classic one is where OPS haven't noticed that disks in a RAID array
> > 
> > have died years ago...
> > 
> > This really happened?
> 
> Yeah. Spent huge money on NMSes but then didn't spend the relatively small
> amount on thorough integration to make it really worthwhile... It seems
> common to me that companies penny pinch too hard and shoot themselves in
> the foot. Probably due to perverse incentives and/or the inability to
> capture true value on a ledger. It requires leadership.

Yep, and not just to Adam.  I had to ask support twice to check their array 
because performance was degraded, but they preferred to blame (my) network for 
it.  So much for keeping an eye on monitoring kit for their storage.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

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

[Adam Carter]

>
> > The classic one is where OPS haven't noticed that disks in a RAID array
> have died years ago...
>
> This really happened?
>

Yeah. Spent huge money on NMSes but then didn't spend the relatively small
amount on thorough integration to make it really worthwhile... It seems
common to me that companies penny pinch too hard and shoot themselves in
the foot. Probably due to perverse incentives and/or the inability to
capture true value on a ledger. It requires leadership.

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

[Andrew Udvare]

> On May 17, 2019, at 01:14, Adam Carter  wrote:
> 
> The classic one is where OPS haven't noticed that disks in a RAID array have 
> died years ago...

This really happened?

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

[Adam Carter]

>
> something even worse.  Since rebooting is when those tend to
> fail/break/whatever, it is yet another reason I avoid rebooting.


I take the opposite approach. If I update the kernel and reboot often, I
see the following benefits;
- Each increment in version is smaller, therefore there's less change per
update, which make it easier to troubleshoot if there's problems
- Doing something regularly is practice, and practice makes perfect. If you
were to update regularly you would become more proficient and confident
with doing the init thingy (initrd?)
- If a hardware issue occurs, I find it at a good time when i'm not busy,
and have the time to troubleshoot
- Getting the benefits of the automated kernel code testing (eg syzbot,
KASAN) that is used these days finding issues that then get fixed
(including security issues). You'd have to assume that over the overall
quality of the kernel is improving at a faster rate now than before those
extra checks were in place.

At work I have raised tickets to have systems with big uptimes have their
hardware status reviewed then restarted, a couple of days before I
undertake risky/critical work. That way I can have more confidence in the
system's health before starting. The classic one is where OPS haven't
noticed that disks in a RAID array have died years ago...

Even when I have a power fail here, it makes me very nervous to shutdown.
>

Another benefit of regular updates would be to reduce stress of deciding to
shutdown, as you will have more confidence that the systems are healthy
when you need to do it.

:)

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