All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: keir@xen.org, Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [PATCH V2] x86, amd_ucode: Support multiple container files appended together
Date: Wed, 25 Jun 2014 09:49:45 -0500	[thread overview]
Message-ID: <53AAE189.8010307@amd.com> (raw)
In-Reply-To: <53AA4A42.2090304@oracle.com>

On 6/24/2014 11:04 PM, Boris Ostrovsky wrote:
>
>>>>   -    /* No more data */
>>>> -    if ( mpbuf->len + 12 >= *offset )
>>>> -        return -EINVAL;
>>> Iirc you and Boris agreed that this check is pointless _here_. But I
>>> doubt it can be removed without replacement elsewhere.
>>
>> For single containers, this check made some sense earlier as we 
>> verify to see there is *some*
>> data beyond the equivalent_table structure.
>> Say, mpbuf->len=0 and we return error val; Due to the fact that we 
>> have already advanced *offset,
>> cases when we reach EOF or *offset goes over bufsize is handled in 
>> container_fast_forward
>> function.
>>
>> For multiple containers, we will always have at least two such 
>> container headers and hence,
>> mpbuf->len + 12 is always less than total_size
>>
>> If first container for some reason is corrupted and exposes 
>> mpbuf->len=0,  we return EINVAL
>> and forward to next container.
>> (This is infact one reason to  advance *offset earlier. See below)
>>
>> Now, if the last container were to have mpbuf->len=0,
>> As Boris mentioned on earlier thread, we will
>> continue because 'if (0+12 >= tot_size) ' is false.
>> Here too, we will return EINVAL.
>>
>> Again, advancing *offset early allows to workaround these issues.
>> And this check can be removed as a result.
>
> Let's say we have a single container and the file got truncated (i.e. 
> bufsize in cpu_request_microcode() is smaller than it should be). 
> Aren't we now risking doing a memcpy out of too short a buffer?
>
>

No, because in 'install_equiv_cpu_table', we only alloc memory and 
memcpy data for the equiv_cpu_table.
Alloc-ing memory (and memcpy) for the patch is handled by 
get_ucode_from_buffer_amd;
and corrupted files (like the ones you say) should be handled by this-
  if ( (off + mpbuf->len) > bufsize )
{
    printk(KERN_ERR "microcode: Bad data in microcode data file\n");
    return -EINVAL;
}

-Aravind.

  reply	other threads:[~2014-06-25 14:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-23 20:25 [PATCH V2] x86, amd_ucode: Support multiple container files appended together Aravind Gopalakrishnan
2014-06-24  7:23 ` Jan Beulich
2014-06-24 22:42   ` Aravind Gopalakrishnan
2014-06-25  4:04     ` Boris Ostrovsky
2014-06-25 14:49       ` Aravind Gopalakrishnan [this message]
2014-06-25 10:47     ` Jan Beulich
2014-06-25 14:54       ` Aravind Gopalakrishnan

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=53AAE189.8010307@amd.com \
    --to=aravind.gopalakrishnan@amd.com \
    --cc=JBeulich@suse.com \
    --cc=boris.ostrovsky@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.