Intel Microcode updates

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Intel Microcode updates

Russell Coker
I just discovered the spectre-meltdown-checker package (thanks Sylvestre for
packaging this).

model name      : Intel(R) Core(TM)2 Quad CPU    Q9505  @ 2.83GHz

On a system with the above CPU running Debian/Testing I get the following
results from the spectre-meltdown-checker script.  Is this a bug in the intel-
microcode package that the latest version isn't packaged?  There is no newer
version of intel-microcode in Unstable.

# spectre-meltdown-checker |grep CPU.mic
* Hardware support (CPU microcode) for mitigation techniques
  * CPU microcode is known to cause stability problems:  NO  (model 0x17
family 0x6 stepping 0xa ucode 0xa0b cpuid 0x1067a)
  * CPU microcode is the latest known available version:  NO  (latest version
is 0xa0e dated 2015/07/29 according to builtin MCExtractor DB v111 -
2019/05/18)
IBPB is considered as a good addition to retpoline for Variant 2 mitigation,
but your CPU microcode doesn't support it
* CPU microcode mitigates the vulnerability:  NO
> STATUS:  VULNERABLE  (an up-to-date CPU microcode is needed to mitigate this
vulnerability)
* CPU microcode mitigates the vulnerability:  N/A

--
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Reply | Threaded
Open this post in threaded view
|

Re: Intel Microcode updates

Michael Stone-2
On Mon, Jun 10, 2019 at 02:01:25PM +1000, Russell Coker wrote:

>I just discovered the spectre-meltdown-checker package (thanks Sylvestre for
>packaging this).
>
>model name      : Intel(R) Core(TM)2 Quad CPU    Q9505  @ 2.83GHz
>
>On a system with the above CPU running Debian/Testing I get the following
>results from the spectre-meltdown-checker script.  Is this a bug in the intel-
>microcode package that the latest version isn't packaged?  There is no newer
>version of intel-microcode in Unstable.
>
># spectre-meltdown-checker |grep CPU.mic
>* Hardware support (CPU microcode) for mitigation techniques
>  * CPU microcode is known to cause stability problems:  NO  (model 0x17
>family 0x6 stepping 0xa ucode 0xa0b cpuid 0x1067a)
>  * CPU microcode is the latest known available version:  NO  (latest version
>is 0xa0e dated 2015/07/29 according to builtin MCExtractor DB v111 -
>2019/05/18)
>IBPB is considered as a good addition to retpoline for Variant 2 mitigation,
>but your CPU microcode doesn't support it
>* CPU microcode mitigates the vulnerability:  NO
>> STATUS:  VULNERABLE  (an up-to-date CPU microcode is needed to mitigate this
>vulnerability)
>* CPU microcode mitigates the vulnerability:  N/A

Your CPU is not supported my Intel, so you either accept the risk or buy
a new one. (Note that the latest version of the microcode is from
2015--long before any of these speculative execution vulnerabilities
were mitigated.) Yours is a yorkfield:
https://www.theregister.co.uk/2018/04/04/intel_spectre_microcode_updates/

Reply | Threaded
Open this post in threaded view
|

Re: Intel Microcode updates

Davide Prina
On 10/06/19 13:16, Michael Stone wrote:
> On Mon, Jun 10, 2019 at 02:01:25PM +1000, Russell Coker wrote:
>> I just discovered the spectre-meltdown-checker package

>> model name      : Intel(R) Core(TM)2 Quad CPU    Q9505  @ 2.83GHz

> Your CPU is not supported my Intel, so you either accept the risk or buy
> a new one.

you have another choice: disable the SMP & C. and all mitigation form Linux

> (Note that the latest version of the microcode is from
> 2015--long before any of these speculative execution vulnerabilities
> were mitigated.) Yours is a yorkfield:
> https://www.theregister.co.uk/2018/04/04/intel_spectre_microcode_updates/

Intel(R) Core(TM)2 Quad CPU was already on sell on many site when the
spectre/meltdown hardware bug was discovered and probably you can buy
also now. It is a shame that intel do not give microcode update for
these CPU and others.

For me, buying new CPU do not give you protection against possible
hardware bug because:

* you will get only mitigation and not bug correction. Mitigation == the
attack is more hard, but it can be done successfully. I don't have read
any new CPU that was designed against this bug... probably because need
5-10 years have these CPU on the market

* your CPU run slower because of these mitigation (I have rad that for
some task you can have 50% or less performance), also some software have
been modified (== make more slower) for these bugs: compiler, browser,
... and, in theory, these mitigation in compilation can be propagate to
all the software you are running (== slowing all your software)

* each CPU has a lot of undocumented instructions each of these can be a
potentially new attack target. There are tools that let you find some of
these, but after that understand how to use or abuse of them is an
another story

* firmware also is nearly always an obscure piece of code, always bigger
that the previous one and in that can be present back door (recently it
has been found back doors in firmware of some cellphone sell in Germany)

* new hardware bugs and variant of previous bugs are found constantly,
so we need a new CPU class designed for security. I have read that some
people want to create a new CPU under free license, I think that is the
only solution that we can trust

* ...

Ciao
Davide

Reply | Threaded
Open this post in threaded view
|

Re: Intel Microcode updates

Michael Stone-2
On Mon, Jun 10, 2019 at 07:46:47PM +0200, Davide Prina wrote:
>On 10/06/19 13:16, Michael Stone wrote:
>>Your CPU is not supported my Intel, so you either accept the risk or
>>buy a new one.
>
>you have another choice: disable the SMP & C. and all mitigation form Linux

That's not correct, but will set your performance back 20 years.

>* you will get only mitigation and not bug correction. Mitigation ==
>the attack is more hard, but it can be done successfully. I don't have

That is also not correct.

>* your CPU run slower because of these mitigation (I have rad that for
>some task you can have 50% or less performance),

That depends on the CPU, some see significant impacts, others see none
or were never vulnerable to some of these issues.

There's enough misinformation about this class of attacks without
spreading more...

>* new hardware bugs and variant of previous bugs are found constantly,
>so we need a new CPU class designed for security. I have read that
>some people want to create a new CPU under free license, I think that
>is the only solution that we can trust

For those who want to use a computer now, that's not particularly
helpful.

Reply | Threaded
Open this post in threaded view
|

Re: Intel Microcode updates

Henrique de Moraes Holschuh
In reply to this post by Russell Coker
On Mon, 10 Jun 2019, Russell Coker wrote:
> model name      : Intel(R) Core(TM)2 Quad CPU    Q9505  @ 2.83GHz
>
> On a system with the above CPU running Debian/Testing I get the following
> results from the spectre-meltdown-checker script.  Is this a bug in the intel-
> microcode package that the latest version isn't packaged?  There is no newer
> version of intel-microcode in Unstable.

Intel upstream decided to not distribute it, for whatever reason.  The
Core2 will not get any fixes for MDS either (nor will Nehalem and
Westmere).

It is easy enough to source that microcode update if you look for it,
and you can just drop it on /usr/share/misc/intel-microcode.bin with
intel-microcode installed, and update the initramfs.  It will pick the
extra microcode up.

--
  Henrique Holschuh

Reply | Threaded
Open this post in threaded view
|

Re: Intel Microcode updates

Russell Coker
On Tuesday, 11 June 2019 12:19:14 PM AEST Henrique de Moraes Holschuh wrote:

> On Mon, 10 Jun 2019, Russell Coker wrote:
> > model name      : Intel(R) Core(TM)2 Quad CPU    Q9505  @ 2.83GHz
> >
> > On a system with the above CPU running Debian/Testing I get the following
> > results from the spectre-meltdown-checker script.  Is this a bug in the
> > intel- microcode package that the latest version isn't packaged?  There
> > is no newer version of intel-microcode in Unstable.
>
> Intel upstream decided to not distribute it, for whatever reason.  The
> Core2 will not get any fixes for MDS either (nor will Nehalem and
> Westmere).
>
> It is easy enough to source that microcode update if you look for it,
> and you can just drop it on /usr/share/misc/intel-microcode.bin with
> intel-microcode installed, and update the initramfs.  It will pick the
> extra microcode up.

Should it be regarded as a bug in the intel-microcode package that it doesn't
have this update that is "easy enough to source"?  Or do you mean "easy to get
but not licensed for distribution"?

--
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Reply | Threaded
Open this post in threaded view
|

Re: Intel Microcode updates

Russell Coker
In reply to this post by Michael Stone-2
On Monday, 10 June 2019 9:16:02 PM AEST Michael Stone wrote:
> Your CPU is not supported my Intel, so you either accept the risk or buy
> a new one. (Note that the latest version of the microcode is from
> 2015--long before any of these speculative execution vulnerabilities
> were mitigated.) Yours is a yorkfield:
> https://www.theregister.co.uk/2018/04/04/intel_spectre_microcode_updates/

Thanks for the advice.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930319

I've filed a bug against the spectre-meltdown-checker package wishing for such
information to be included.

--
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Reply | Threaded
Open this post in threaded view
|

Re: Intel Microcode updates

Moritz Mühlenhoff-2
In reply to this post by Russell Coker
Russell Coker <[hidden email]> schrieb:
> Should it be regarded as a bug in the intel-microcode package that it doesn't
> have this update that is "easy enough to source"?  Or do you mean "easy to get
> but not licensed for distribution"?

This is covered by #929073, which links to a PDF by Intel (which documents
that Intel won't ship an update for your CPU).

Cheers,
        Moritz

Reply | Threaded
Open this post in threaded view
|

Re: Intel Microcode updates

Andrew McGlashan
In reply to this post by Henrique de Moraes Holschuh
Hi Russell,

On 11/6/19 12:19 pm, Henrique de Moraes Holschuh wrote:
> On Mon, 10 Jun 2019, Russell Coker wrote:
>> model name      : Intel(R) Core(TM)2 Quad CPU    Q9505  @ 2.83GHz

The first thing to think about with all of these problems is, are you
/really/ affected.... ie, are you at risk?

Now, if you run your own machine and you trust EVERY process on that
machine, then you should be safe.  This is extended if you have VMs on
the machine, you have to trust EVERY SINGLE process on every VM.

Exploiting the flaws needs malicious code to be running on your box.  If
you are in total control over all VMs and processes on the box, then you
should be good.

The trouble comes when you have an non-trusted process or VM or a trust
that has been broken.

If you share a machine that you are not in control of, others using that
same (physical) machine, will then you are at risk.

Of course, at any time, if there is some other vulnerability that comes
in to play and a process can run that should not be ran, then you are at
risk.

Kind Regards
AndrewM

Reply | Threaded
Open this post in threaded view
|

Re: Intel Microcode updates

Holger Levsen-2
On Wed, Jun 12, 2019 at 03:05:13AM +1000, Andrew McGlashan wrote:
> Exploiting the flaws needs malicious code to be running on your box.  If
> you are in total control over all VMs and processes on the box, then you
> should be good.
 
do you use a webbrowser with javascript enabled?


--
tschau,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Intel Microcode updates

Davide Prina
In reply to this post by Michael Stone-2
On 10/06/19 20:31, Michael Stone wrote:
> On Mon, Jun 10, 2019 at 07:46:47PM +0200, Davide Prina wrote:
>> On 10/06/19 13:16, Michael Stone wrote:
>>> Your CPU is not supported my Intel, so you either accept the risk or
>>> buy a new one.
>>
>> you have another choice: disable the SMP & C. and all mitigation form
>> Linux
>
> That's not correct, but will set your performance back 20 years.

why is it not correct?

I have read that most of this hardware bug is related to the execution
of the possible future operation, while the system is executing the
actual operation.

OK this solution will slow down a lot your CPU.

>> * you will get only mitigation and not bug correction. Mitigation ==
>> the attack is more hard, but it can be done successfully. I don't have
>
> That is also not correct.

why?

I have read that some variant of the initial bug cannot be mitigated
with the initial solution and so they have create a different mitigation.
I have read that the bug let you read a bit a time and get in data that
you don't have permission to read with a good probability and in a
little time; the patch let this process be more difficult to implement
and need more time to be used to the same task.

I have also read that some hardware bug solution are not implementable
with software (firmware), so the only thing you can do is to mitigate
this problem.

>> * your CPU run slower because of these mitigation (I have rad that for
>> some task you can have 50% or less performance),
>
> That depends on the CPU, some see significant impacts, others see none
> or were never vulnerable to some of these issues.

that true, but I never read that a processor type with a
spectre/meltdown/& C. have been released with a new CPU version that is
immune to this bug, so you always need this software mitigation.

So you buy a CPU that his power need to be "partially" used to mitigate
some hardware bug while it run "real" processes

> There's enough misinformation about this class of attacks without
> spreading more...

I have try to read the research that describe those hardware bugs,
probably I don't have understand all or I don't have read all the
document... you can write some more and try do correct what I don't have
understand... and if you give us some link... :-)

>> * new hardware bugs and variant of previous bugs are found constantly,
>> so we need a new CPU class designed for security. I have read that
>> some people want to create a new CPU under free license, I think that
>> is the only solution that we can trust
>
> For those who want to use a computer now, that's not particularly helpful.

or it will be?

I have read that researchers have start to search for hardware bug only
recently and hardware manufacturers have designed they hardware without
take security in consideration. Also, I have read, that researches are
now developing new tools that let them investigate for hardware bug.
Some expert say that the bug actually found are only the small part of
the iceberg that emerge from the see and some say that soon we will see
hardware bug that let attacker also write other processes data.

In this "catastrophic" scenario, I think, that knowing the problematic
of the hardware are you buying is important. Also knowing that someone
is building a better hardware with free license, with all schematics and
sources available, ... can be a very useful information and this can
make more people contribute (also with only money) to let this dream to
be realized in a near future.

Ciao
Davide

Reply | Threaded
Open this post in threaded view
|

Re: Intel Microcode updates

Andrew McGlashan
In reply to this post by Holger Levsen-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

On 12/6/19 3:16 am, Holger Levsen wrote:
> On Wed, Jun 12, 2019 at 03:05:13AM +1000, Andrew McGlashan wrote:
>> Exploiting the flaws needs malicious code to be running on your
>> box.  If you are in total control over all VMs and processes on
>> the box, then you should be good.
>
> do you use a webbrowser with javascript enabled?

Good point, yes that is another risk.

Cheers
A.
-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXP/76QAKCRCoFmvLt+/i
+8YWAQDfgkeWAEhYLtcORGRnznYwVlsMe1APLfzmZOIPB/GeygD+Ly/bSqA4Zdt7
JMolvBBceyvEwxoTymSqEsn71H7Mbhw=
=DAkU
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Intel Microcode updates

Andrew McGlashan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

> On 12/6/19 3:16 am, Holger Levsen wrote:
>> On Wed, Jun 12, 2019 at 03:05:13AM +1000, Andrew McGlashan
>> wrote:
>>> Exploiting the flaws needs malicious code to be running on your
>>>  box.  If you are in total control over all VMs and processes
>>> on the box, then you should be good.
>
>> do you use a webbrowser with javascript enabled?
>
> Good point, yes that is another risk.

Actually though, if you update your browser to lessen the granularity
of time that the exploits require, it might not be an issue.  So,
don't run an out of date browser....  is that enough?

Cheers
A.
-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXP/8eAAKCRCoFmvLt+/i
+2AsAP4knXw4eLsVrlYm/CwuWJrhGC8FRVj4Uc09H0mR2ZDlhwD/RI/FDdLYiO9t
nNNga1FHGhCMj7v/rzJcZ/8iGrNrmqI=
=/5dj
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Intel Microcode updates

Michael Stone-2
In reply to this post by Davide Prina
On Tue, Jun 11, 2019 at 08:00:49PM +0200, Davide Prina wrote:

>On 10/06/19 20:31, Michael Stone wrote:
>>On Mon, Jun 10, 2019 at 07:46:47PM +0200, Davide Prina wrote:
>>>On 10/06/19 13:16, Michael Stone wrote:
>>>>Your CPU is not supported my Intel, so you either accept the
>>>>risk or buy a new one.
>>>
>>>you have another choice: disable the SMP & C. and all mitigation
>>>form Linux
>>
>>That's not correct, but will set your performance back 20 years.
>
>why is it not correct?
>
>I have read that most of this hardware bug is related to the execution
>of the possible future operation, while the system is executing the
>actual operation.
>
>OK this solution will slow down a lot your CPU.

It's simply not correct that every one of these hardware bugs can be
mitigated by running on only a single thread. I think you're confusing
SMP (multiple processors) with speculative execution (within a
processor), but this really isn't the right forum to sort that out.

>>>* you will get only mitigation and not bug correction. Mitigation
>>>== the attack is more hard, but it can be done successfully. I
>>>don't have
>>
>>That is also not correct.
>
>why?

Because "mitigation" simply does not mean "the attack...can be done
successfully". In some cases the mitigations make an attack unlikely, in
other cases the mitigations change the behavior of the system to make an
attack impossible, and in some cases the mitigations add capabilities
which can be used to prevent attacks but which require additional
changes in programs.

>>>* your CPU run slower because of these mitigation (I have rad that
>>>for some task you can have 50% or less performance),
>>
>>That depends on the CPU, some see significant impacts, others see
>>none or were never vulnerable to some of these issues.
>
>that true, but I never read that a processor type with a
>spectre/meltdown/& C. have been released with a new CPU version that
>is immune to this bug, so you always need this software mitigation.

"etc" covers a lot of ground when we're talking about (currently) 12
seperately-identified vulnerabilities. Many CPUs weren't vulnerable to
every one of the vulnerabilities. Getting one not vulnerable to the
vulnerabilities that are most expensive to mitigate is a good starting
place. Some have functionality that makes the mitigations less expensive
than others. Again, this isn't the right place to tell people what CPU
to buy or to discuss the performance characteristics of more than half a
dozen different CPU families. As a specific example, AMD processors were
not vulnerable to the "meltdown" bug. As a further specific example,
some vulnerable intel CPUs support the PCID instructions which make the
mitigation much less expensive by allowing the kernel to selectively
flush the TLB rather than flushing the whole thing. So just for that one
vulnerability the cost ranges from "nothing/not vulnerable" to "modest"
to "severe"--though the cost is also heavily dependent on the workload
and whether a single user thread does most of the work or whether there
are frequent system calls or contention on the system.

>>There's enough misinformation about this class of attacks without
>>spreading more...
>
>I have try to read the research that describe those hardware bugs,
>probably I don't have understand all or I don't have read all the
>document

Then it's probably best that you not tell thousands of people the wrong
information.

Reply | Threaded
Open this post in threaded view
|

Re: Intel Microcode updates

Henrique de Moraes Holschuh
In reply to this post by Moritz Mühlenhoff-2
(BCC'd to #929073 to avoid dragging the BTS into this thread).

On Tue, 11 Jun 2019, Moritz Mühlenhoff wrote:
> Russell Coker <[hidden email]> schrieb:
> > Should it be regarded as a bug in the intel-microcode package that it doesn't
> > have this update that is "easy enough to source"?  Or do you mean "easy to get
> > but not licensed for distribution"?
>
> This is covered by #929073, which links to a PDF by Intel (which documents
> that Intel won't ship an update for your CPU).

I'd like to add that:

We do not, and will not, distribute in non-free's intel-microcode
anything we did not get from Intel (or from someone else who got it from
Intel with permission to redistribute).  This ensures all microcode
updates we distribute in non-free are under a license that allows
redistribution.

Note that, as long as there are very good reasons to do so, I am willing
to distribute microcode updates that are no longer being distributed[1],
since we did receive it with an appropriate license that allows
redistribution in the first place.

Also, one can place whatever microcode updates they got from wherever to
/usr/share/misc/intel-microcode*.bin at their own risk and
responsibility, and the intel-microcode package will attempt to use it.

[1] as in: "they were being distributed by Intel on the Linux microcode
update package in the past, and for more than one release of Intel's
microcode update package".

--
  Henrique Holschuh

Reply | Threaded
Open this post in threaded view
|

Re: Intel Microcode updates

Elmar Stellnberger-3
In reply to this post by Andrew McGlashan
   Just because you disable Javascript in your browser I would not trust
that you will be save from arbitrary code execution. I am using
Thunderbird as an email client and it has the same intrusion problem as
the browsers running Javascript. The arbitrary binary code execution
problem does to my believe more relate to common vulnerabilities like
buffer overflows in the whole code than just to the Javascript subsystem
which is of course an additional security risk. As long as the code base
is changing rapidly and as long as new arbitrary code execution problems
are discovered from time to time you are not save. The speed new bugs
are moved in is simply higher than the speed by with some of the old
bugs are corrected for browsers like Chromium or Firefox (I would not
trust software from Google anyway as it is part of the empire of
'evil'.). Intelligence services usually use zero days exploits for which
there is no known mitigation. If you wanna be save on a computer do not
use an email client or web browser; at least not if it can connect to
sites spoofed by secret services. To avoid connecting to a 1:1 mirror
site of an intelligence service we would need an improvement of https
certificate management like f.i. DANE provides. There are many rogue
certificates issued for intelligence services out there and restricting
your browser to use https does not help.

Regards,
Elmar



Am 11.06.19 um 21:09 schrieb Andrew McGlashan:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi,
>
>> On 12/6/19 3:16 am, Holger Levsen wrote:
>>> On Wed, Jun 12, 2019 at 03:05:13AM +1000, Andrew McGlashan
>>> wrote:
>>>> Exploiting the flaws needs malicious code to be running on your
>>>>   box.  If you are in total control over all VMs and processes
>>>> on the box, then you should be good.
>>> do you use a webbrowser with javascript enabled?
>> Good point, yes that is another risk.
> Actually though, if you update your browser to lessen the granularity
> of time that the exploits require, it might not be an issue.  So,
> don't run an out of date browser....  is that enough?
>
> Cheers
> A.
> -----BEGIN PGP SIGNATURE-----
>
> iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXP/8eAAKCRCoFmvLt+/i
> +2AsAP4knXw4eLsVrlYm/CwuWJrhGC8FRVj4Uc09H0mR2ZDlhwD/RI/FDdLYiO9t
> nNNga1FHGhCMj7v/rzJcZ/8iGrNrmqI=
> =/5dj
> -----END PGP SIGNATURE-----
>

Reply | Threaded
Open this post in threaded view
|

Re: Intel Microcode updates

Elmar Stellnberger-3
In reply to this post by Henrique de Moraes Holschuh
Perhaps you could add a bash script that does automatically download the
microcode like f.i. winetricks does with windows code. That way one
could be more sure to use the right url for it. I also still have quite
a lot of Core 2 computers and would thus profit from such a provision.

Am 12.06.19 um 16:52 schrieb Henrique de Moraes Holschuh:

> (BCC'd to #929073 to avoid dragging the BTS into this thread).
>
> On Tue, 11 Jun 2019, Moritz Mühlenhoff wrote:
>> Russell Coker <[hidden email]> schrieb:
>>> Should it be regarded as a bug in the intel-microcode package that it doesn't
>>> have this update that is "easy enough to source"?  Or do you mean "easy to get
>>> but not licensed for distribution"?
>> This is covered by #929073, which links to a PDF by Intel (which documents
>> that Intel won't ship an update for your CPU).
> I'd like to add that:
>
> We do not, and will not, distribute in non-free's intel-microcode
> anything we did not get from Intel (or from someone else who got it from
> Intel with permission to redistribute).  This ensures all microcode
> updates we distribute in non-free are under a license that allows
> redistribution.
>
> Note that, as long as there are very good reasons to do so, I am willing
> to distribute microcode updates that are no longer being distributed[1],
> since we did receive it with an appropriate license that allows
> redistribution in the first place.
>
> Also, one can place whatever microcode updates they got from wherever to
> /usr/share/misc/intel-microcode*.bin at their own risk and
> responsibility, and the intel-microcode package will attempt to use it.
>
> [1] as in: "they were being distributed by Intel on the Linux microcode
> update package in the past, and for more than one release of Intel's
> microcode update package".
>

Reply | Threaded
Open this post in threaded view
|

Re: Intel Microcode updates

Andrew McGlashan
In reply to this post by Elmar Stellnberger-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

>>>> On 12/6/19 3:16 am, Holger Levsen wrote:
>>>>> On Wed, Jun 12, 2019 at 03:05:13AM +1000, Andrew McGlashan
>>>>> wrote:
>>>>>> Exploiting the flaws needs malicious code to be running
>>>>>> on your box.  If you are in total control over all VMs
>>>>>> and processes on the box, then you should be good.
>>>>> do you use a webbrowser with javascript enabled?
>>>> Good point, yes that is another risk.
> Actually though, if you update your browser to lessen the
> granularity of time that the exploits require, it might not be an
> issue.  So, don't run an out of date browser....  is that enough?


It doesn't have to be JavaScript, it can be ANY scripting.  When it
comes to an updated browser, the exploit relies upon very precise
timing differences between operations -- if the browser won't report
timing with enough precision, then the exploit cannot work reliably if
at all (probably not at all).

Now as for TB, well, one would hope (I don't now the answer), that
they too have implemented the same fixes that Mozilla made for Firefox
to thwart the success of an exploit as well, ie have timing being less
granular to be able to perform the exploit.

Anyway, if the CPU microcode can be attained for the older CPUs, then
the licensing issue with Debian providing it is no longer a concern (I
believe).  Refer https://01.org/mcu-path-license-2018

Cheers
A.
-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXQkrpQAKCRCoFmvLt+/i
+zHAAP4nK5G7HuNv+YzJBjb0aU4e06faITqYO4/pVxARNed8BQD/ZygkaIizLAte
0MuzlcPSQSjN04zlTUo9gxqD18ttbAE=
=21rJ
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Intel Microcode updates

Elmar Stellnberger-3
In reply to this post by Andrew McGlashan
   Just because you disable Javascript in your browser I would not trust
that you will be save from arbitrary code execution. I am using
Thunderbird as an email client and it has the same intrusion problem as
the browsers running Javascript. The arbitrary binary code execution
problem does to my believe more relate to common vulnerabilities like
buffer overflows in the whole code than just to the Javascript subsystem
which is of course an additional security risk. As long as the code base
is changing rapidly and as long as new arbitrary code execution problems
are discovered from time to time you are not save. The speed new bugs
are moved in is simply higher than the speed by with some of the old
bugs are corrected for browsers like Chromium or Firefox (I would not
trust software from Google anyway as it is part of the empire of
'evil'.). Intelligence services usually use zero days exploits for which
there is no known mitigation. If you wanna be save on a computer do not
use an email client or web browser; at least not if it can connect to
sites spoofed by secret services. To avoid connecting to a 1:1 mirror
site of an intelligence service we would need an improvement of https
certificate management like f.i. DANE provides. There are many rogue
certificates issued for intelligence services out there and restricting
your browser to use https does not help.

Regards,
Elmar



Am 11.06.19 um 21:09 schrieb Andrew McGlashan:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi,
>
>> On 12/6/19 3:16 am, Holger Levsen wrote:
>>> On Wed, Jun 12, 2019 at 03:05:13AM +1000, Andrew McGlashan
>>> wrote:
>>>> Exploiting the flaws needs malicious code to be running on your
>>>> box. If you are in total control over all VMs and processes
>>>> on the box, then you should be good.
>>> do you use a webbrowser with javascript enabled?
>> Good point, yes that is another risk.
> Actually though, if you update your browser to lessen the granularity
> of time that the exploits require, it might not be an issue. So,
> don't run an out of date browser.... is that enough?
>
> Cheers
> A.
> -----BEGIN PGP SIGNATURE-----
>
> iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXP/8eAAKCRCoFmvLt+/i
> +2AsAP4knXw4eLsVrlYm/CwuWJrhGC8FRVj4Uc09H0mR2ZDlhwD/RI/FDdLYiO9t
> nNNga1FHGhCMj7v/rzJcZ/8iGrNrmqI=
> =/5dj
> -----END PGP SIGNATURE-----
>

Reply | Threaded
Open this post in threaded view
|

Re: Intel Microcode updates

Elmar Stellnberger-3
In reply to this post by Henrique de Moraes Holschuh
Perhaps you could add a bash script that does automatically download the
microcode like f.i. winetricks does with windows code. That way one
could be more sure to use the right url for it. I also still have quite
a lot of Core 2 computers and would thus profit from such a provision.

Am 12.06.19 um 16:52 schrieb Henrique de Moraes Holschuh:

> (BCC'd to #929073 to avoid dragging the BTS into this thread).
>
> On Tue, 11 Jun 2019, Moritz Mühlenhoff wrote:
>> Russell Coker <[hidden email]> schrieb:
>>> Should it be regarded as a bug in the intel-microcode package that
>>> it doesn't
>>> have this update that is "easy enough to source"? Or do you mean
>>> "easy to get
>>> but not licensed for distribution"?
>> This is covered by #929073, which links to a PDF by Intel (which
>> documents
>> that Intel won't ship an update for your CPU).
> I'd like to add that:
>
> We do not, and will not, distribute in non-free's intel-microcode
> anything we did not get from Intel (or from someone else who got it from
> Intel with permission to redistribute). This ensures all microcode
> updates we distribute in non-free are under a license that allows
> redistribution.
>
> Note that, as long as there are very good reasons to do so, I am willing
> to distribute microcode updates that are no longer being distributed[1],
> since we did receive it with an appropriate license that allows
> redistribution in the first place.
>
> Also, one can place whatever microcode updates they got from wherever to
> /usr/share/misc/intel-microcode*.bin at their own risk and
> responsibility, and the intel-microcode package will attempt to use it.
>
> [1] as in: "they were being distributed by Intel on the Linux microcode
> update package in the past, and for more than one release of Intel's
> microcode update package".
>

12