On Mon, Mar 12, 2018 at 03:10:47PM +0100, Maciej S. Szmigiero wrote:
> And this current maximum was reached by CPU types added in
> families < 15h during last 10+ years (the oldest supported CPU family in
You're assuming that the rate of adding patches to the microcode
container won't change. You
On Mon, Mar 12, 2018 at 03:10:47PM +0100, Maciej S. Szmigiero wrote:
> And this current maximum was reached by CPU types added in
> families < 15h during last 10+ years (the oldest supported CPU family in
You're assuming that the rate of adding patches to the microcode
container won't change. You
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 entries.
>
> So purely arbitrary:
>
>
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 entries.
>
> So purely arbitrary:
>
>
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 entries.
So purely arbitrary:
Equivalence table (magic: AMD, type: 0, length: 288 (0x120))
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 entries.
So purely arbitrary:
Equivalence table (magic: AMD, type: 0, length: 288 (0x120))
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.
>> Also, looking in the past,
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.
>> Also, looking in the past,
On Mon, Mar 12, 2018 at 01:56:59PM +0100, Maciej S. Szmigiero wrote:
> The equivalent CPU table is allocated using vmalloc() so it is nice
> when the maximum size is an integer multiple of the page size.
Arbitrary.
> Since the maximum entry count in current microcode files is 18 the
Where did
On Mon, Mar 12, 2018 at 01:56:59PM +0100, Maciej S. Szmigiero wrote:
> The equivalent CPU table is allocated using vmalloc() so it is nice
> when the maximum size is an integer multiple of the page size.
Arbitrary.
> Since the maximum entry count in current microcode files is 18 the
Where did
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 exactly?
The equivalent CPU table is
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 exactly?
The equivalent CPU table is
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 exactly?
> +/* If a patch is larger than this the microcode file is surely corrupted */
>
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 exactly?
> +/* If a patch is larger than this the microcode file is surely corrupted */
>
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 checks, mostly on length-type fields, so
all corrupted microcode files are
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 checks, mostly on length-type fields, so
all corrupted microcode files are
16 matches
Mail list logo
