summaryrefslogtreecommitdiffstats
path: root/meta/recipes-support/gnupg/gnupg-1.4.7/CVE-2013-4242.patch
diff options
context:
space:
mode:
authorRichard Purdie <richard.purdie@linuxfoundation.org>2017-03-02 12:04:08 +0000
committerRichard Purdie <richard.purdie@linuxfoundation.org>2017-03-07 20:04:58 +0000
commit19b7e950346fb1dde6505c45236eba6cd9b33b4b (patch)
tree4e582be23e08321bd04c591be3f37926199d6005 /meta/recipes-support/gnupg/gnupg-1.4.7/CVE-2013-4242.patch
parent39f5a05152aa0c3503735e18dd3b4c066b284107 (diff)
downloadopenembedded-core-uninative-1.5.tar.gz
recipes: Move out stale GPLv2 versions to a seperate layeruninative-1.5
These are recipes where the upstream has moved to GPLv3 and these old versions are the last ones under the GPLv2 license. There are several reasons for making this move. There is a different quality of service with these recipes in that they don't get security fixes and upstream no longer care about them, in fact they're actively hostile against people using old versions. The recipes tend to need a different kind of maintenance to work with changes in the wider ecosystem and there needs to be isolation between changes made in the v3 versions and those in the v2 versions. There are probably better ways to handle a "non-GPLv3" system but right now having these in OE-Core makes them look like a first class citizen when I believe they have potential for a variety of undesireable issues. Moving them into a separate layer makes their different needs clearer, it also makes it clear how many of these there are. Some are probably not needed (e.g. mc), I also wonder whether some are useful (e.g. gmp) since most things that use them are GPLv3 only already. Someone could now more clearly see how to streamline the list of recipes here. I'm proposing we mmove to this separate layer for 2.3 with its future maintinership and testing to be determined in 2.4 and beyond. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/recipes-support/gnupg/gnupg-1.4.7/CVE-2013-4242.patch')
-rw-r--r--meta/recipes-support/gnupg/gnupg-1.4.7/CVE-2013-4242.patch63
1 files changed, 0 insertions, 63 deletions
diff --git a/meta/recipes-support/gnupg/gnupg-1.4.7/CVE-2013-4242.patch b/meta/recipes-support/gnupg/gnupg-1.4.7/CVE-2013-4242.patch
deleted file mode 100644
index f0667741c8..0000000000
--- a/meta/recipes-support/gnupg/gnupg-1.4.7/CVE-2013-4242.patch
+++ /dev/null
@@ -1,63 +0,0 @@
-From e2202ff2b704623efc6277fb5256e4e15bac5676 Mon Sep 17 00:00:00 2001
-From: Werner Koch <wk@gnupg.org>
-Date: Thu, 25 Jul 2013 11:17:52 +0200
-Subject: [PATCH] Mitigate a flush+reload cache attack on RSA secret
- exponents.
-
-commit e2202ff2b704623efc6277fb5256e4e15bac5676 from
-git://git.gnupg.org/libgcrypt.git
-
-* mpi/mpi-pow.c (gcry_mpi_powm): Always perfrom the mpi_mul for
-exponents in secure memory.
-
-Upstream-Status: Backport
-CVE: CVE-2013-4242
-
-Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
-
-The attack is published as http://eprint.iacr.org/2013/448 :
-
-Flush+Reload: a High Resolution, Low Noise, L3 Cache Side-Channel
-Attack by Yuval Yarom and Katrina Falkner. 18 July 2013.
-
- Flush+Reload is a cache side-channel attack that monitors access to
- data in shared pages. In this paper we demonstrate how to use the
- attack to extract private encryption keys from GnuPG. The high
- resolution and low noise of the Flush+Reload attack enables a spy
- program to recover over 98% of the bits of the private key in a
- single decryption or signing round. Unlike previous attacks, the
- attack targets the last level L3 cache. Consequently, the spy
- program and the victim do not need to share the execution core of
- the CPU. The attack is not limited to a traditional OS and can be
- used in a virtualised environment, where it can attack programs
- executing in a different VM.
-
-Index: gnupg-1.4.7/mpi/mpi-pow.c
-===================================================================
---- gnupg-1.4.7.orig/mpi/mpi-pow.c
-+++ gnupg-1.4.7/mpi/mpi-pow.c
-@@ -212,7 +212,13 @@ mpi_powm( MPI res, MPI base, MPI exponen
- tp = rp; rp = xp; xp = tp;
- rsize = xsize;
-
-- if( (mpi_limb_signed_t)e < 0 ) {
-+ /* To mitigate the Yarom/Falkner flush+reload cache
-+ * side-channel attack on the RSA secret exponent, we do
-+ * the multiplication regardless of the value of the
-+ * high-bit of E. But to avoid this performance penalty
-+ * we do it only if the exponent has been stored in secure
-+ * memory and we can thus assume it is a secret exponent. */
-+ if (esec || (mpi_limb_signed_t)e < 0) {
- /*mpihelp_mul( xp, rp, rsize, bp, bsize );*/
- if( bsize < KARATSUBA_THRESHOLD ) {
- mpihelp_mul( xp, rp, rsize, bp, bsize );
-@@ -227,6 +233,8 @@ mpi_powm( MPI res, MPI base, MPI exponen
- mpihelp_divrem(xp + msize, 0, xp, xsize, mp, msize);
- xsize = msize;
- }
-+ }
-+ if ( (mpi_limb_signed_t)e < 0 ) {
-
- tp = rp; rp = xp; xp = tp;
- rsize = xsize;