All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: sstabellini@kernel.org, ross.lagerwall@citrix.com,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien.grall@arm.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 07/16] livepatch/arm/x86: Check payload for for unwelcomed symbols.
Date: Mon, 19 Sep 2016 13:32:57 -0400	[thread overview]
Message-ID: <20160919173249.GA32633@localhost.localdomain> (raw)
In-Reply-To: <57E016CA0200007800110251@prv-mh.provo.novell.com>

On Mon, Sep 19, 2016 at 08:48:10AM -0600, Jan Beulich wrote:
> >>> On 19.09.16 at 16:13, <julien.grall@arm.com> wrote:
> 
> > 
> > On 19/09/2016 16:11, Jan Beulich wrote:
> >>>>> On 19.09.16 at 15:33, <julien.grall@arm.com> wrote:
> >>> On 19/09/2016 11:27, Jan Beulich wrote:
> >>>>>>> On 16.09.16 at 18:38, <konrad.wilk@oracle.com> wrote:
> >>>>> --- a/xen/arch/arm/livepatch.c
> >>>>> +++ b/xen/arch/arm/livepatch.c
> >>>>> @@ -117,6 +117,20 @@ bool arch_livepatch_symbol_ok(const struct livepatch_elf
> >>> *elf,
> >>>>>      return true;
> >>>>>  }
> >>>>>
> >>>>> +bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
> >>>>> +                                const struct livepatch_elf_sym *sym)
> >>>>> +{
> >>>>> +#ifdef CONFIG_ARM_32
> >>>>> +    /*
> >>>>> +     * Xen does not use Thumb instructions - and we should not see any of
> >>>>> +     * them. If we do, abort.
> >>>>> +     */
> >>>>> +    if ( sym->name && *sym->name == '$' && sym->name[1] == 't' )
> >>>
> >>> Please use sym->name[0] for readability. Also, you may want to check the
> >>> length of the symbol before checking the second character.
> >>
> >> Why would the length check be needed? If the first character is $,
> >> then looking at the second one is always valid (and it being nul will
> >> be properly dealt with by the expression above).
> > 
> > Because you may have a payload which is not valid? Or maybe you consider 
> > that all the payload are trusted.
> 
> If all symbols' names are inside their string tables and the string
> tables are both contained inside the image and have a zero byte
> at their end (all of which gets verified afair), nothing bad can
> happen I think.

Exactly. All of those checks are done so we are sure that the
sym->name[0] points to something.


Julien, I can use strlen if you prefer, so it would be like so:
                                                                               
bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
                                const struct livepatch_elf_sym *sym)
{
#ifdef CONFIG_ARM_32
    /*
     * Xen does not use Thumb instructions - and we should not see any of
     * them. If we do, abort.
     */
    if ( sym-name && sym->name[0] == '$' && sym->name[1] == 't' )
    {
        size_t len = strlen(sym->name);

        if ( (len >= 3 && (sym->name[2] == '.')) || len == 2 )
            return true;
    }
#endif
    return false;
}

Or this way:

bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,                
                                const struct livepatch_elf_sym *sym)            
{                                                                               
#ifdef CONFIG_ARM_32                                                            
    /*                                                                          
     * Xen does not use Thumb instructions - and we should not see any
     * of          
     * them. If we do, abort.                                                   
     */                                                                         
    if ( sym->name && sym->name[0] == '$' && sym->name[1] == 't' )                           
    {                                                                           
        if ( sym->name[2] && sym->name[2] != '.' )                              
            return false;                                                       
                                                                                
        return true;                                                            
    }                                                                           
#endif                                                                          
    return false;                                                               
}                                   


Both add exactly the same amount of lines of code :-)

> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2016-09-19 17:33 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-16 16:38 [PATCH v4] Livepatch for ARM 64 and 32 Konrad Rzeszutek Wilk
2016-09-16 16:38 ` [PATCH v4 01/16] arm/x86/common: Add HAS_[ALTERNATIVE|EX_TABLE] Konrad Rzeszutek Wilk
2016-09-19  9:09   ` Jan Beulich
2016-09-19  9:26   ` Julien Grall
2016-09-19 14:04     ` Konrad Rzeszutek Wilk
2016-09-19 14:09       ` Julien Grall
2016-09-19 14:43         ` Konrad Rzeszutek Wilk
2016-09-16 16:38 ` [PATCH v4 02/16] livepatch: Reject payloads with .alternative or .ex_table if support is not built-in Konrad Rzeszutek Wilk
2016-09-16 16:38 ` [PATCH v4 03/16] arm: poison initmem when it is freed Konrad Rzeszutek Wilk
2016-09-19  9:35   ` Julien Grall
2016-09-19 14:19     ` Konrad Rzeszutek Wilk
2016-09-16 16:38 ` [PATCH v4 04/16] livepatch: Initial ARM64 support Konrad Rzeszutek Wilk
2016-09-19 10:26   ` Julien Grall
2016-09-19 14:33     ` Konrad Rzeszutek Wilk
2016-09-20  9:40       ` Julien Grall
2016-09-16 16:38 ` [PATCH v4 05/16] livepatch: ARM/x86: Check displacement of old_addr and new_addr Konrad Rzeszutek Wilk
2016-09-19  9:19   ` Jan Beulich
2016-09-19 13:12   ` Julien Grall
2016-09-16 16:38 ` [PATCH v4 06/16] livepatch: ARM 32|64: Ignore mapping symbols: $[d, a, x] Konrad Rzeszutek Wilk
2016-09-16 16:38 ` [PATCH v4 07/16] livepatch/arm/x86: Check payload for for unwelcomed symbols Konrad Rzeszutek Wilk
2016-09-19  9:27   ` Jan Beulich
2016-09-19 13:33     ` Julien Grall
2016-09-19 14:11       ` Jan Beulich
2016-09-19 14:13         ` Julien Grall
2016-09-19 14:48           ` Jan Beulich
2016-09-19 17:32             ` Konrad Rzeszutek Wilk [this message]
2016-09-20  7:00               ` Jan Beulich
2016-09-20  9:44               ` Julien Grall
2016-09-16 16:38 ` [PATCH v4 08/16] livepatch: Move test-cases to their own sub-directory in test Konrad Rzeszutek Wilk
2016-09-16 16:58   ` Konrad Rzeszutek Wilk
2016-09-16 16:38 ` [PATCH v4 09/16] livepatch: tests: Make them compile under ARM64 Konrad Rzeszutek Wilk
2016-09-19 13:35   ` Julien Grall
2016-09-16 16:38 ` [PATCH v4 10/16] livepatch: x86, ARM, alternative: Expose FEATURE_LIVEPATCH Konrad Rzeszutek Wilk
2016-09-19 13:47   ` Julien Grall
2016-09-16 16:38 ` [PATCH v4 11/16] xen/arm32: Add an helper to invalidate all instruction caches Konrad Rzeszutek Wilk
2016-09-19 14:24   ` Julien Grall
2016-09-16 16:38 ` [PATCH v4 12/16] bug/x86/arm: Align bug_frames sections Konrad Rzeszutek Wilk
2016-09-19  9:29   ` Jan Beulich
2016-09-19 14:34   ` Julien Grall
2016-09-19 14:35     ` Julien Grall
2016-09-19 20:19       ` Konrad Rzeszutek Wilk
2016-09-19 20:26         ` Konrad Rzeszutek Wilk
2016-09-20  9:46         ` Julien Grall
2016-09-16 16:38 ` [PATCH v4 13/16] livepatch: Initial ARM32 support Konrad Rzeszutek Wilk
2016-09-19 14:39   ` Julien Grall
2016-09-16 16:38 ` [PATCH v4 14/16] livepatch, arm[32|64]: Share arch_livepatch_revert_jmp Konrad Rzeszutek Wilk
2016-09-19 14:43   ` Julien Grall
2016-09-16 16:38 ` [PATCH v4 15/16] livepatch: arm[32, 64], x86: NOP test-case Konrad Rzeszutek Wilk
2016-09-16 16:38 ` [PATCH v4 16/16] livepatch: In xen_nop test-case remove the .bss and .data sections Konrad Rzeszutek Wilk
2016-09-19  9:32   ` 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=20160919173249.GA32633@localhost.localdomain \
    --to=konrad.wilk@oracle.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=julien.grall@arm.com \
    --cc=ross.lagerwall@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.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.