Fixes the following security issues:
- CVE-2020-8696: Description: Improper removal of sensitive information
before storage or transfer in some Intel(R) Processors may allow an
authenticated user to potentially enable information disclosure via local
access
- CVE-2020-8698: Description: Improper isolation of shared resources in some
Intel(R) Processors may allow an authenticated user to potentially enable
information disclosure via local access
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00381.html
License file updated with the new year, so change hash accordingly.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[yann.morin.1998@free.fr: explain license hash change]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
On Github, a large number of projects name their tag
<some-prefix>-0.3-<some-suffix> (i.e release-3.0, poco-0.1-release,
etc.). In fact majority of the cased adressed in this commit concerns
prefixes.
In most packages, we encode those prefix/suffix in the <pkg>_VERSION
variable.
The problem with this approach is that when used in conjunction with
release-monitoring.org, it doesn't work very well, because
release-monitoring.org has the concept of "version prefix/suffix" and
using that they drop the prefix/suffix to really get the version. For
example on https://release-monitoring.org/project/5418/ the latest
release of "poco" is "1.8.1", not "poco-1.8.1-release".
Therefore, a number of packages in Buildroot have a version that
doesn't match with release-monitoring.org.
Since really the version number of 1.8.1, is makes sense to update our
packages to drop these prefixes/suffixes.
This commit addreses the case of github-fetched packages with
non-conventional prefixes/suffixes.
Note that these changes modify the name of the files stored in DL_DIR,
which means that this will force a re-download of those package source
code for all users, and requires a change to their .hash file.
Signed-off-by: Victor Huesca <victor.huesca@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
For early microcode loading, there is no need to install the individual
microcode files to /lib/firmware - So make that optional.
Let the option default to y for backwards compatibility, and select it from
iucode-tool as the init script relies on the /lib/firmware files.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Microcode based security mitigation (E.G. MDS) requires that the microcode
gets loaded very early. This can be handled by one of:
- Concatenating (a subset of) the intel-microcode files and write to
kernel/x86/microcode/GenuineIntel.bin in the initrd. Requires that the
(first) initrd is external from the kernel and NOT compressed.
- Build (a subset of) the intel-microcode files into the kernel using the
CONFIG_EXTRA_FIRMWARE option.
Install the microcode files into images to support these use cases (E.G.
through a post-build script for the initrd, or by pointing
CONFIG_EXTRA_FIRMWARE_DIR to ${BR_BINARIES_DIR}, similar to how we include
the .cpio image inside the kernel).
Notice that there may be licensing concerns when embedded non-GPL firmware
in the kernel.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Includes MDS mitigation (RIDL, Fallout, Zombieload), INTEL-SA-00223
Move to the Intel github repo as this release is not yet available on
downloadmirror.intel.com.
Update license hash because of copyright year and DOS/UNIX newlines change.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 1f0beaf9a8 ("intel-microcode:
bump to version 20180807a") introduced the use of "install -D -t" to
the intel-microcode package. The intent is that install will create
the full destination directory, including all components leading to
it, before copying the files.
Unfortunately, "install -D -t" is only supported since coreutils since
v8.23. Several of the build systems we support have older coreutils
versions, such as Debian 7, which uses coreutils 8.13. Ubuntu 14.04
also doesn't have a recent enough coreutils.
So let's create the directory explicitly first, and then use a more
regular "install -t".
Fixes:
http://autobuild.buildroot.net/results/aa44f9ff90f296f886be6309b3355ed075494fb2/
Note: the "gzip: stdout: Broken pipe" messages in those failures seem
unrelated. We have been able to reproduce the installation failure
without those "Broken pipe" issues, and we have not been able to
reproduce those "Broken pipe" problems.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Carlos Santos <casantos@datacom.com.br>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The big "intel-microcode.dat" text file is gone. Only binary files are
provided, in the "intel-ucode" directory. Install it at /lib/firmware/,
like linux-firmware does, and update the iucode-tool init script to use
that path.
We don't install the microcode under "intel-ucode-with-caveats", since
it needs special commits in the Linux kernel (see "relnotes" for more
information).
Tested on an equipment with Intel C3000 processor.
Signed-off-by: Carlos Santos <casantos@datacom.com.br>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The intel microcode is a proprietary package which provides a data file
used to correct processors errors.
It was originally sent by Richard Braun <rbraun@sceen.net>
[Peter: set _LICENSE_FILES]
Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Richard Braun <rbraun@sceen.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
