This commit converts the late loader in the AMD microcode update driver to
use newly introduced microcode container data checking functions as the
previous commit did for the early loader.
Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>
---
arch/x86/kernel/cpu/microcode
.
Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>
---
arch/x86/include/asm/microcode_amd.h | 1 +
arch/x86/kernel/cpu/microcode/amd.c | 4
2 files changed, 5 insertions(+)
diff --git a/arch/x86/include/asm/microcode_amd.h
b/arch/x86/include/asm/microcode_amd.h
index 209492
Currently, the code scanning the CPU equivalence table read from a
microcode container file assumes that it actually contains a terminating
zero entry.
Let's check also the size of this table to make sure that we don't read
past it in case it actually doesn't.
Signed-off-by: Maciej S. Szmigiero
)
whether the size of a patch is not too large for a particular CPU family.
By adding these checks as separate functions the actual microcode loading
code won't get interspersed with a lot of checks and so will be more
readable.
Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>
---
for
printk()-style functions to work.
Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>
---
arch/x86/kernel/cpu/microcode/amd.c | 45 ++---
1 file changed, 22 insertions(+), 23 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/ar
Currently, it is very easy to make the AMD microcode update driver crash
or spin on a malformed microcode container file since it does very little
consistency checking on data loaded from such file.
This series introduces various checks, mostly on length-type fields,
so all corrupted microcode
the leftover file length before passing this value to
verify_patch_size().
Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>
Link:
http://lkml.kernel.org/r/b4854b17-e3ba-54d6-488d-0e0bfffe4...@maciej.szmigiero.name
[ Split comment. ]
Signed-off-by: Borislav Petkov <b..
is a problem for RSA
implementations that need it to be exactly correct (like AMD CCP).
Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>
Fixes: c26fd69fa009 ("X.509: Add a crypto key parser for binary (DER) X.509
certificates")
Cc: sta...@vger.kernel.org
---
This is a r
/ mono),
* Unplugging while capturing,
* DVB / analog coexistence,
* Raw BT.656 stream support.
What does not work yet:
* Audio,
* VBI,
* Picture controls.
Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>
---
drivers/media/usb/dvb-usb/Kconfig| 16 +-
drivers/media/u
ut risking compatibility problems.
Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>
---
drivers/media/i2c/cx25840/cx25840-core.c | 396 ++-
drivers/media/i2c/cx25840/cx25840-core.h | 13 +
drivers/media/i2c/cx25840/cx25840-vbi.c | 3 +
includ
time due to hardware
limitations.
Actual implementation of the analog mode will be provided by the next
commit.
Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>
---
drivers/media/usb/dvb-usb/cxusb.c| 450 +++
drivers/media/usb/dvb-usb/c
This commit describes a device instance private data of the driver
(struct cx25840_state) in a kernel-doc style comment.
Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>
---
drivers/media/i2c/cx25840/cx25840-core.h | 33 ++--
1 file chang
a FMD1216ME tuner.
Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>
---
drivers/media/tuners/tuner-simple.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/tuners/tuner-simple.c
b/drivers/media/tuners/tuner-simple.c
index 36b88f
We need to zero-initialize cx25840 platform data structure to make sure
that its future members do not contain random stack garbage.
Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>
---
drivers/media/pci/ivtv/ivtv-i2c.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/d
This series adds support for analog part of Medion 95700 in the cxusb
driver.
What works:
* Video capture at various sizes with sequential fields,
* Input switching (TV Tuner, Composite, S-Video),
* TV and radio tuning,
* Video standard switching and auto detection,
* Radio mode switching (stereo
PUs without updated microcode.
Other CPU types either already do the RSB filling on context switch for
other reasons or do support IBPB for more complete userspace-to-userspace
protection.
Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>
---
arch/x86/kernel/cpu/bugs.c | 10 +++--
On 22.03.2018 00:30, Dave Hansen wrote:
> On 03/20/2018 04:17 AM, Maciej S. Szmigiero wrote:
>> Since it is unlikely that existing RSB entries from the previous task match
>> the new task call stack we can use the existing unconditional
>> RSB-filling-on-context-switch infr
On 21.03.2018 15:05, Dave Hansen wrote:
> On 03/20/2018 04:17 AM, Maciej S. Szmigiero wrote:
>> If we run on a CPU that does not have IBPB support RSB entries from one
>> userspace process can influence 'ret' target prediction in another
>> userspace process after a contex
On 22.03.2018 17:11, Borislav Petkov wrote:
> On Fri, Mar 16, 2018 at 12:08:17AM +0100, Maciej S. Szmigiero wrote:
>> @@ -505,7 +505,7 @@ static unsigned int verify_patch_size(u8 family, u32
>> patch_size,
>> break;
>> }
>>
>> -if
On 22.03.2018 16:46, Dave Hansen wrote:
> On 03/21/2018 05:09 PM, Maciej S. Szmigiero wrote:
>> As far as I understand the issue this should provide a good protection
>> for userspace processes that were recompiled with retpolines as they
>> won't have any indirect jumps an
On 07.03.2018 18:56, Maciej S. Szmigiero wrote:
> On 07.03.2018 16:44, David Howells wrote:
>> Maciej S. Szmigiero <m...@maciej.szmigiero.name> wrote:
>>
>>> + if (!strcmp(ctx->cert->sig->pkey_algo, "rsa")) {
>>
>> I'm going to chang
On 02.03.2018 17:44, Herbert Xu wrote:
> On Sat, Feb 24, 2018 at 05:03:21PM +0100, Maciej S. Szmigiero wrote:
>> rsa-pkcs1pad uses a value returned from a RSA implementation max_size
>> callback as a size of an input buffer passed to the RSA implementation for
>> encryp
On 03.03.2018 00:49, Hook, Gary wrote:
> On 3/2/2018 5:15 PM, Maciej S. Szmigiero wrote:
>> On 02.03.2018 17:44, Herbert Xu wrote:
>>> On Sat, Feb 24, 2018 at 05:03:21PM +0100, Maciej S. Szmigiero wrote:
>>>> rsa-pkcs1pad uses a value returned from a RSA impleme
On 09.10.2018 22:36, Heiner Kallweit wrote:
> On 09.10.2018 16:40, Chris Clayton wrote:
>> Thanks to Maciej and Heiner for their replies.
>>
>> On 09/10/2018 13:32, Maciej S. Szmigiero wrote:
>>> On 07.10.2018 21:36, Chris Clayton wrote:
>>>> Hi again,
&
On 07.10.2018 21:36, Chris Clayton wrote:
> Hi again,
>
> I didn't think there was anything in 4.19-rc7 to fix this regression, but
> tried it anyway. I can confirm that the
> regression is still present and my network still fails when, after a resume
> from suspend (to ram or disk), I open my
On 11.10.2018 00:49, Chris Clayton wrote:
>> Now, knowing the "right" value you can experiment with what rtl_init_rxcfg()
>> writes (under the "default:" label for your NIC model).
>>
>
> This might be more interesting. Through a combination of viewing the output
> from pr_notice() and the
On 11.10.2018 10:24, Chris Clayton wrote:
> On 11/10/2018 01:12, Maciej S. Szmigiero wrote:
>> On 11.10.2018 00:49, Chris Clayton wrote:
>>>> Now, knowing the "right" value you can experiment with what
>>>> rtl_init_rxcfg()
>>>>
suspended and resumed.
Fixes: 05212ba8132b42 ("r8169: set RxConfig after tx/rx is enabled for
RTL8169sb/8110sb devices")
Reported-by: Chris Clayton
Signed-off-by: Maciej S. Szmigiero
---
drivers/net/ethernet/realtek/r8169.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Hi,
> Hi,
>
> I upgraded my kernel to 4.18.10 recently and have since been experiencing
> network problems after resuming from a
> suspend to RAM or disk. I previously had 4.18.6 and that was OK.
>
> The pattern of the problem is that when I first boot, the network is fine.
> But, after
Hi,
On 18.09.2018 12:23, David Arendt wrote:
> Hi,
>
> Today I had the network adapter problems again.
> So the patch doesn't seem to change anything regarding this problem.
> This week my time is unfortunately very limited, but I will try to
> find some time next weekend to look a bit more into
Currently, it is very easy to make the AMD microcode update driver crash
or spin on a malformed microcode container file since it does very little
consistency checking on data loaded from such file.
This series introduces various checks, mostly on length-type fields,
so all corrupted microcode
as an
expression) and we have a static array using this macro value as its
length.
This macro is specific to amd.c file so let's move it there (the max sizes
for families are in this file already).
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/include/asm/microcode_amd.h | 2 --
arch/x86/kernel
the PATCH_MAX_SIZE check in parse_container()
function.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/arch/x86/kernel/cpu/microcode/amd.c
index
the equivalence table anyway.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c | 54 ++---
1 file changed, 38 insertions(+), 16 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/arch/x86/kernel/cpu/microcode/amd.c
index
We should check whether the patch section currently being processed is
actually a patch section for each of them (not just the first one) in the
late loader verify_and_add_patch() function, just like the early loader
already does in parse_container() function.
Signed-off-by: Maciej S. Szmigiero
returned by this function are of no
use anyway, since they are all normalized to UCODE_ERROR by its caller
(__load_microcode_amd()).
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git
from the leftover file length before passing this value to
verify_patch_size().
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/arch/x86/kernel/cpu/microcode/amd.c
enough to contain the header magic value.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/arch/x86/kernel/cpu/microcode/amd.c
index 3ad23e72c2b0..63bd1a63f98a 100644
Currently, the code scanning the CPU equivalence table read from a
microcode container file assumes that it actually contains a terminating
zero entry.
Let's check also the size of this table to make sure that we don't read
past it in case it actually doesn't.
Signed-off-by: Maciej S. Szmigiero
patches.
Note that we already do silently skip patches in the late loader for
smaller issues like lack of an equivalence table entry, family-size
mismatch or an unsupported chipset match type.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c | 6 --
1 file changed, 4
On 14.03.2018 18:04, Borislav Petkov wrote:
> On Tue, Mar 13, 2018 at 10:06:23PM +0100, Maciej S. Szmigiero wrote:
(..)
>> --- a/arch/x86/kernel/cpu/microcode/amd.c
>> +++ b/arch/x86/kernel/cpu/microcode/amd.c
>> @@ -80,20 +80,29 @@ static u16 find_equiv_id(struct equiv_cpu_e
On 14.03.2018 18:58, Borislav Petkov wrote:
> On Tue, Mar 13, 2018 at 10:06:34PM +0100, Maciej S. Szmigiero wrote:
>> The maximum possible value returned by install_equiv_cpu_table() is
>> UINT_MAX + CONTAINER_HDR_SZ (on a 64-bit kernel).
>> This is more than (signed) int ty
On 14.03.2018 19:02, Borislav Petkov wrote:
> On Tue, Mar 13, 2018 at 10:06:48PM +0100, Maciej S. Szmigiero wrote:
>> +/* Maximum of all the above families */
>> +#define PATCH_MAX_SIZE SIMPLE_MAX3(F1XH_MPB_MAX_SIZE, F14H_MPB_MAX_SIZE, \
>
> Nope, it should be
>
> #d
On 15.03.2018 00:58, Borislav Petkov wrote:
> On Thu, Mar 15, 2018 at 12:46:05AM +0100, Maciej S. Szmigiero wrote:
>> The maximum possible value returned by install_equiv_cpu_table() of
>> UINT_MAX + CONTAINER_HDR_SZ comes from the maximum value of this 'size'
>> variable (t
On 15.03.2018 01:56, Borislav Petkov wrote:
> On Thu, Mar 15, 2018 at 01:13:07AM +0100, Maciej S. Szmigiero wrote:
>> This can be done if this function is modified to return only the CPU
>> equivalence table length (without the container header length), leaving
>> its
This series adds support for analog part of Medion 95700 in the cxusb
driver.
What works:
* Video capture at various sizes with sequential fields,
* Input switching (TV Tuner, Composite, S-Video),
* TV and radio tuning,
* Video standard switching and auto detection,
* Radio mode switching (stereo
time due to hardware
limitations.
Actual implementation of the analog mode will be provided by the next
commit.
Signed-off-by: Maciej S. Szmigiero
---
drivers/media/usb/dvb-usb/cxusb.c| 450 +++
drivers/media/usb/dvb-usb/cxusb.h| 48
drivers/media
This commit describes a device instance private data of the driver
(struct cx25840_state) in a kernel-doc style comment.
Signed-off-by: Maciej S. Szmigiero
---
drivers/media/i2c/cx25840/cx25840-core.h | 33 ++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff
We need to zero-initialize cx25840 platform data structure to make sure
that its future members do not contain random stack garbage.
Signed-off-by: Maciej S. Szmigiero
---
drivers/media/pci/ivtv/ivtv-i2c.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/pci/ivtv/ivtv-i2c.c
b
a FMD1216ME tuner.
Signed-off-by: Maciej S. Szmigiero
---
drivers/media/tuners/tuner-simple.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/tuners/tuner-simple.c
b/drivers/media/tuners/tuner-simple.c
index 36b88f820239..29c1473f2e9f 100644
--- a/drivers
/ mono),
* Unplugging while capturing,
* DVB / analog coexistence,
* Raw BT.656 stream support.
What does not work yet:
* Audio,
* VBI,
* Picture controls.
Signed-off-by: Maciej S. Szmigiero
---
drivers/media/usb/dvb-usb/Kconfig| 16 +-
drivers/media/usb/dvb-usb/Makefile |3
ut risking compatibility problems.
Signed-off-by: Maciej S. Szmigiero
---
drivers/media/i2c/cx25840/cx25840-core.c | 396 ++-
drivers/media/i2c/cx25840/cx25840-core.h | 13 +
drivers/media/i2c/cx25840/cx25840-vbi.c | 3 +
include/media/drv-intf/cx25840.h
are (hopefully) correctly rejected instead.
Signed-off-by: Maciej S. Szmigiero
---
Test files are at https://pastebin.com/XkKUSmMp
One has to enable KASAN in the kernel config and rename a particular
test file to name appropriate to the running CPU family to test its
loading.
arch/x86/include/asm
On 10.03.2018 10:18, Borislav Petkov wrote:
> On Sat, Mar 10, 2018 at 01:34:45AM +0100, Maciej S. Szmigiero wrote:
>> Currently, it is very easy to make the AMD microcode update driver crash
>> or spin on a malformed microcode file since it does very little
>> consistency ch
On 10.03.2018 14:12, Borislav Petkov wrote:
> On Sat, Mar 10, 2018 at 01:26:00PM +0100, Maciej S. Szmigiero wrote:
>> Without them, it is easy to crash the driver when just playing with
>> microcode files
>
> You're not supposed to play with the microcode files. If you do a
On 10.03.2018 01:34, Maciej S. Szmigiero wrote:
> Currently, it is very easy to make the AMD microcode update driver crash
> or spin on a malformed microcode file since it does very little
> consistency checking on data loaded from such file.
>
> This commit introduces various
On 10.03.2018 17:46, Borislav Petkov wrote:
> On Sat, Mar 10, 2018 at 05:16:40PM +0100, Maciej S. Szmigiero wrote:
(..)
>> There is no container file at all for family 17h (Zen) so
>> distributions like OpenSUSE that include this file must have gotten it
>> from some other
On 11.03.2018 10:59, Ingo Molnar wrote:
>
> * Maciej S. Szmigiero wrote:
>
>> Currently, it is very easy to make the AMD microcode update driver crash
>> or spin on a malformed microcode file since it does very little
>> consistency checking on data loaded from s
are (hopefully) correctly rejected instead.
Signed-off-by: Maciej S. Szmigiero
---
Changes from v1: Capitalize a comment, rename 'eqsize' and 'bufsize'
to 'eq_size' and 'buf_size', respectively, attach a comment about
checking the equivalence table header to its first size check, rename
'equiv{_cpu
On 12.03.2018 10:53, Borislav Petkov wrote:
> On Sun, Mar 11, 2018 at 04:27:03PM +0100, Maciej S. Szmigiero wrote:
>> +/* 4k */
>> +#define UCODE_EQUIV_CPU_TABLE_MAX_SIZE (256 * sizeof(struct
>> equiv_cpu_entry))
>
> And you came up with that max size how exactl
On 12.03.2018 14:06, Borislav Petkov wrote:
> On Mon, Mar 12, 2018 at 01:56:59PM +0100, Maciej S. Szmigiero wrote:
(..)
>> Since the maximum entry count in current microcode files is 18 the
>
> Where did you dream up that 18?
"microcode_amd.bin" in linux-firmware.
>
On 12.03.2018 14:48, Borislav Petkov wrote:
> On Mon, Mar 12, 2018 at 02:32:30PM +0100, Maciej S. Szmigiero wrote:
>> "microcode_amd.bin" in linux-firmware.
>
> That is the microcode container for all families < 0x15. And it
> *happens* to have 18 en
On 22.03.2018 17:11, Borislav Petkov wrote:
> On Fri, Mar 16, 2018 at 12:08:17AM +0100, Maciej S. Szmigiero wrote:
>> @@ -505,7 +505,7 @@ static unsigned int verify_patch_size(u8 family, u32
>> patch_size,
>> break;
>> }
>>
>> -if
On 07.03.2018 18:56, Maciej S. Szmigiero wrote:
> On 07.03.2018 16:44, David Howells wrote:
>> Maciej S. Szmigiero wrote:
>>
>>> + if (!strcmp(ctx->cert->sig->pkey_algo, "rsa")) {
>>
>> I'm going to change this to '== 0' rather than '!'.
On 22.03.2018 16:46, Dave Hansen wrote:
> On 03/21/2018 05:09 PM, Maciej S. Szmigiero wrote:
>> As far as I understand the issue this should provide a good protection
>> for userspace processes that were recompiled with retpolines as they
>> won't have any indirect jumps an
PUs without updated microcode.
Other CPU types either already do the RSB filling on context switch for
other reasons or do support IBPB for more complete userspace-to-userspace
protection.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/bugs.c | 10 +++---
1 file changed, 7 insertions(+)
On 21.03.2018 15:05, Dave Hansen wrote:
> On 03/20/2018 04:17 AM, Maciej S. Szmigiero wrote:
>> If we run on a CPU that does not have IBPB support RSB entries from one
>> userspace process can influence 'ret' target prediction in another
>> userspace process after a contex
On 22.03.2018 00:30, Dave Hansen wrote:
> On 03/20/2018 04:17 AM, Maciej S. Szmigiero wrote:
>> Since it is unlikely that existing RSB entries from the previous task match
>> the new task call stack we can use the existing unconditional
>> RSB-filling-on-context-switch infr
On 12.01.2018 18:49, Woodhouse, David wrote:
> When we context switch from a shallow call stack to a deeper one, as we
> 'ret' up the deeper side we may encounter RSB entries (predictions for
> where the 'ret' goes to) which were populated in userspace. This is
> problematic if we have neither
On 09.03.2018 16:14, Andi Kleen wrote:
>> Shouldn't the RSB filling on context switch also be done on non-IBPB
>> CPUs to protect (retpolined) user space tasks from other user space
>> tasks?
>
> The comment is actually incorrect. There's no risk to hit user space
> addresses if we have KPTI and
the equivalence table anyway.
This patch adds these checks to the early loader.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c | 35 +++
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b
Currently, it is very easy to make the AMD microcode update driver crash
or spin on a malformed microcode container file since it does very little
consistency checking on data loaded from such file.
This series introduces various checks, mostly on length-type fields,
so all corrupted microcode
from the leftover file length before passing this value to
verify_patch_size().
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/arch/x86/kernel/cpu
codes returned by install_equiv_cpu_table()
are of no use anyway, since they are all normalized to UCODE_ERROR by its
caller.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git
the equivalence table anyway.
This patch adds these checks to the late loader.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c | 32 ++--
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/arch
patches.
Note that we already do silently skip patches in the late loader for
smaller issues like lack of an equivalence table entry, family-size
mismatch or an unsupported chipset match type.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c | 6 --
1 file changed, 4
enough to contain the header magic value.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/arch/x86/kernel/cpu/microcode/amd.c
index 4d2116d08754..dc5ed4971879 100644
Currently, the code scanning the CPU equivalence table read from a
microcode container file assumes that it actually contains a terminating
zero entry.
Let's check also the size of this table to make sure that we don't read
past it in case it actually doesn't.
Signed-off-by: Maciej S. Szmigiero
check in parse_container()
function.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/arch/x86/kernel/cpu/microcode/amd.c
index eba9e3c8aa17
We should check whether the patch section currently being processed is
actually a patch section for each of them (not just the first one) in the
late loader verify_and_add_patch() function, just like the early loader
already does in parse_container() function.
Signed-off-by: Maciej S. Szmigiero
.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/include/asm/microcode_amd.h | 1 +
arch/x86/kernel/cpu/microcode/amd.c | 4
2 files changed, 5 insertions(+)
diff --git a/arch/x86/include/asm/microcode_amd.h
b/arch/x86/include/asm/microcode_amd.h
index 209492849566..8ea477fbc65f 100644
On 16.03.2018 00:23, Borislav Petkov wrote:
> On Fri, Mar 16, 2018 at 12:07:34AM +0100, Maciej S. Szmigiero wrote:
>> Currently, it is very easy to make the AMD microcode update driver crash
>> or spin on a malformed microcode container file since it does very little
>>
On 18.11.2017 06:14, Kees Cook wrote:
> On Fri, Nov 17, 2017 at 5:54 PM, Patrick McLean wrote:
>> On 2017-11-17 04:55 PM, Linus Torvalds wrote:
>>> On Fri, Nov 17, 2017 at 4:27 PM, Patrick McLean wrote:
I am still getting the crash at d9e12200852d, I figured I would
double-check
Patrick McLean
> Root-caused-by: Maciej S. Szmigiero
> Fixes: 3859a271a003 ("randstruct: Mark various structs for randomization")
> Suggested-by: Linus Torvalds
> Signed-off-by: Kees Cook
I can confirm that this patch fixes the original nfsd GPF issue.
Also, struct path members of
Hi William,
Hi Linus,
On 22.02.2018 21:30, William Breathitt Gray wrote:
> On Thu, Feb 22, 2018 at 04:16:17PM +0100, Linus Walleij wrote:
>> On Fri, Dec 29, 2017 at 9:13 PM, William Breathitt Gray
>> wrote:
>>
>>> The ISA_BUS_API Kconfig option enables the compilation of the ISA bus
>>> driver.
On 30.04.2018 11:05, Borislav Petkov wrote:
> On Mon, Apr 23, 2018 at 11:34:08PM +0200, Maciej S. Szmigiero wrote:
>> --- a/arch/x86/kernel/cpu/microcode/amd.c
>> +++ b/arch/x86/kernel/cpu/microcode/amd.c
>> @@ -216,29 +216,33 @@ static bool verify_patch(u8 family, cons
On 30.04.2018 11:04, Borislav Petkov wrote:
> On Mon, Apr 23, 2018 at 11:34:07PM +0200, Maciej S. Szmigiero wrote:
>> --- a/arch/x86/kernel/cpu/microcode/amd.c
>> +++ b/arch/x86/kernel/cpu/microcode/amd.c
>> +/*
>> + * Checks whether there is a valid, non-trun
On 30.04.2018 11:05, Borislav Petkov wrote:
> On Mon, Apr 23, 2018 at 11:34:09PM +0200, Maciej S. Szmigiero wrote:
>> --- a/arch/x86/kernel/cpu/microcode/amd.c
>> +++ b/arch/x86/kernel/cpu/microcode/amd.c
>> @@ -750,28 +752,20 @@ static int verify_and_add_patch(u8 family, u8
On 01.05.2018 10:18, Borislav Petkov wrote:
> On Tue, May 01, 2018 at 12:27:17AM +0200, Maciej S. Szmigiero wrote:
>> These checking functions are supposed to be called in order:
>
> We don't do magical rules like that - you either verify fully and
> correctly or you d
On 01.05.2018 10:43, Borislav Petkov wrote:
> On Tue, May 01, 2018 at 12:27:51AM +0200, Maciej S. Szmigiero wrote:
>> 1) -EINVAL maps to a valid return value of 4294967274 bytes.
>> We have a different behavior for invalid data in the container file
>> (including too large le
On 01.05.2018 22:03, Borislav Petkov wrote:
> On Tue, May 01, 2018 at 06:19:56PM +0200, Maciej S. Szmigiero wrote:
>> -EINVAL cast to unsigned int is 4294967274 and this value is also
>> a valid count of bytes to skip that this function can return.
>
> And where exactly in th
On 03.05.2018 12:01, Borislav Petkov wrote:
> On Wed, May 02, 2018 at 02:47:39AM +0200, Maciej S. Szmigiero wrote:
>> On 01.05.2018 22:03, Borislav Petkov wrote:
>>> On Tue, May 01, 2018 at 06:19:56PM +0200, Maciej S. Szmigiero wrote:
>>>> -EINVAL cast to unsigned in
is a problem for RSA
implementations that need it to be exactly correct (like AMD CCP).
Signed-off-by: Maciej S. Szmigiero
Fixes: c26fd69fa009 ("X.509: Add a crypto key parser for binary (DER) X.509
certificates")
Cc: sta...@vger.kernel.org
---
This is a resend of a patch that was previously
()-style functions to work.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c | 59 -
1 file changed, 33 insertions(+), 26 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/arch/x86/kernel/cpu/microcode/amd.c
index f9485ff7183c
of a patch is not too large for a particular CPU family.
By adding these checks as separate functions the actual microcode loading
code won't get interspersed with a lot of checks and so will be more
readable.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c | 148
Currently, it is very easy to make the AMD microcode update driver crash
or spin on a malformed microcode container file since it does very little
consistency checking on data loaded from such file.
This series introduces various checks, mostly on length-type fields,
so all corrupted microcode
ainer data to skip to a separate output parameter.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c | 33 +++--
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/arch/x86/kernel/cpu/microcode/a
the leftover file length before passing this value to
verify_patch_size().
Signed-off-by: Maciej S. Szmigiero
Link:
http://lkml.kernel.org/r/b4854b17-e3ba-54d6-488d-0e0bfffe4...@maciej.szmigiero.name
[ Split comment. ]
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/cpu/microcode/amd.c | 15
Now that the previous commit converted the late loader to do a full patch
checking via verify_patch() instead of calling verify_patch_size() directly
we can integrate the later function into the former because it was its only
user.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu
Convert the late loader in the AMD microcode update driver to use newly
introduced microcode container data checking functions as it was previously
done for the early loader.
Signed-off-by: Maciej S. Szmigiero
---
arch/x86/kernel/cpu/microcode/amd.c | 70 +
1 file
401 - 500 of 936 matches
Mail list logo
