From: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Thomas.Lendacky@amd.com, keir@xen.org,
Suravee.Suthikulpanit@amd.com, xen-devel@lists.xen.org
Subject: Re: [PATCH] x86, amd_ucode: Verify max allowed patch size before apply
Date: Fri, 25 Apr 2014 14:48:10 -0500 [thread overview]
Message-ID: <535ABBFA.7020104@amd.com> (raw)
In-Reply-To: <535A2418020000780000C255@nat28.tlf.novell.com>
On 4/25/2014 2:00 AM, Jan Beulich wrote:
>>>> On 24.04.14 at 21:54, <aravind.gopalakrishnan@amd.com> wrote:
>> Each family has a stipulated max patch_size. Use this as
>> additional sanity check before we apply it.
> And iirc there was a size limit check earlier, and it got dropped for one
> reason or another - did you check history?
Yes, I believe you are referring to this commit:
commit 5663cc8258cef27509a437ebd95061b8b01b9c01
Author: Christoph Egger <Christoph.Egger@amd.com>
AuthorDate: Thu Dec 15 11:00:09 2011 +0100
Commit: Christoph Egger <Christoph.Egger@amd.com>
CommitDate: Thu Dec 15 11:00:09 2011 +0100
x86/ucode: fix for AMD Fam15 CPUs
Remove hardcoded maximum size a microcode patch can have. This is
dynamic now.
The microcode patch for family15h can be larger than 2048 bytes and
gets silently truncated.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
The above patch was to make the microcode patch buffer allocation dynamic.
The hunk below simply verifies that we don't exceed the 'max_size'..
>> @@ -94,7 +94,40 @@ static int collect_cpu_info(int cpu, struct cpu_signature *csig)
>> return 0;
>> }
>>
>> -static bool_t microcode_fits(const struct microcode_amd *mc_amd, int cpu)
>> +static bool_t verify_patch_size(uint32_t patch_size)
>> +{
>> + uint8_t family;
>> + uint32_t max_size;
>> +
>> +#define F1XH_MPB_MAX_SIZE 2048
>> +#define F14H_MPB_MAX_SIZE 1824
>> +#define F15H_MPB_MAX_SIZE 4096
>> +#define F16H_MPB_MAX_SIZE 3458
>> +
>> + family = boot_cpu_data.x86;
>> + switch (family)
>> + {
>> + case 0x14:
>> + max_size = F14H_MPB_MAX_SIZE;
>> + break;
>> + case 0x15:
>> + max_size = F15H_MPB_MAX_SIZE;
>> + break;
>> + case 0x16:
>> + max_size = F16H_MPB_MAX_SIZE;
>> + break;
>> + default:
>> + max_size = F1XH_MPB_MAX_SIZE;
>> + break;
>> + }
>> +
>> + if ( patch_size > max_size )
>> + return 0;
>> +
>> + return 1;
> Please simply "return patch_size <= max_size" in cases like this.
Okay.
>> @@ -329,6 +369,11 @@ static int cpu_request_microcode(int cpu, const void *buf, size_t bufsize)
>>
>> last_offset = offset;
>>
>> + if ( error == -EEXIST ) {
> Coding style, but as Andrew already indicated this block of code isn't
> correct anyway.
Yes, will fix this. But some help in understanding the microcode_init
calls would help me here..
(Pleas refer reply to Andrew's comments)
>> @@ -370,9 +415,11 @@ static int microcode_resume_match(int cpu, const void *mc)
>> struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
>> struct microcode_amd *mc_amd = uci->mc.mc_amd;
>> const struct microcode_amd *src = mc;
>> + int error;
>>
>> - if ( !microcode_fits(src, cpu) )
>> - return 0;
>> + error = microcode_fits(src, cpu);
>> + if ( error )
>> + return error;
> Is it really correct for this to get switched from success to error return?
Previously, microcode_fits returned '1' for Success, '0' for error. So,
the condition returns '0' when return val is '0'
This mechanism is still preserved in the changes made above..
>> @@ -383,10 +430,11 @@ static int microcode_resume_match(int cpu, const void *mc)
>> xfree(mc_amd);
>> }
>>
>> + error = -ENOMEM;
>> mc_amd = xmalloc(struct microcode_amd);
>> uci->mc.mc_amd = mc_amd;
>> if ( !mc_amd )
>> - return -ENOMEM;
>> + return error;
> Bogus (pointless) change?
>
>> @@ -408,7 +456,7 @@ err2:
>> err1:
>> xfree(mc_amd);
>> uci->mc.mc_amd = NULL;
>> - return -ENOMEM;
>> + return error;
> Same here.
>
Hmm. Okay, Will just revert this.
Thanks,
-Aravind.
next prev parent reply other threads:[~2014-04-25 19:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-24 19:54 [PATCH] x86, amd_ucode: Verify max allowed patch size before apply Aravind Gopalakrishnan
2014-04-24 20:26 ` Andrew Cooper
2014-04-25 19:48 ` Aravind Gopalakrishnan
2014-04-25 20:30 ` Andrew Cooper
2014-04-28 8:49 ` Jan Beulich
2014-04-28 15:48 ` Aravind Gopalakrishnan
2014-04-25 7:00 ` Jan Beulich
2014-04-25 19:48 ` Aravind Gopalakrishnan [this message]
2014-04-28 7:21 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=535ABBFA.7020104@amd.com \
--to=aravind.gopalakrishnan@amd.com \
--cc=JBeulich@suse.com \
--cc=Suravee.Suthikulpanit@amd.com \
--cc=Thomas.Lendacky@amd.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).