All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org,
	Andrii Anisov <Andrii_Anisov@epam.com>,
	Oleksandr_Tyshchenko@epam.com
Subject: Re: [Xen-devel] [PATCH MM-PART3 v2 06/12] xen/arm: mm: Sanity check any update of Xen page tables
Date: Wed, 12 Jun 2019 15:48:51 +0100	[thread overview]
Message-ID: <a1921f46-f042-f167-4461-72b903a9418d@arm.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1906111710110.13737@sstabellini-ThinkPad-T480s>

Hi Stefano,

On 12/06/2019 01:10, Stefano Stabellini wrote:
> On Tue, 14 May 2019, Julien Grall wrote:
>> The code handling Xen PT update has quite a few restrictions on what it
>> can do. This is not a bad thing as it keeps the code simple.
>>
>> There are already a few checks scattered in current page table handling.
>> However they are not sufficient as they could still allow to
>> modify/remove entry with contiguous bit set.
>>
>> The checks are divided in two sets:
>>      - per entry check: They are gathered in a new function that will
>>      check whether an update is valid based on the flags passed and the
>>      current value of an entry.
>>      - global check: They are sanity check on xen_pt_update() parameters.
>>
>> Additionally to contiguous check, we also now check that the caller is
>> not trying to modify the memory attributes of an entry.
>>
>> Lastly, it was probably a bit over the top to forbid removing an
>> invalid mapping. This could just be ignored. The new behavior will be
>> helpful in future changes.
>>
>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>> Reviewed-by: Andrii Anisov <andrii_anisov@epam.com>
>>
>> ---
>>      Changes in v2:
>>          - Correctly detect the removal of a page
>>          - Fix ASSERT on flags in the else case
>>          - Add Andrii's reviewed-by
>> ---
>>   xen/arch/arm/mm.c | 115 +++++++++++++++++++++++++++++++++++++++++++++---------
>>   1 file changed, 97 insertions(+), 18 deletions(-)
>>
>> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
>> index 2192dede55..45a6f9287f 100644
>> --- a/xen/arch/arm/mm.c
>> +++ b/xen/arch/arm/mm.c
>> @@ -50,6 +50,19 @@ struct domain *dom_xen, *dom_io, *dom_cow;
>>   #undef mfn_to_virt
>>   #define mfn_to_virt(mfn) __mfn_to_virt(mfn_x(mfn))
>>   
>> +#ifdef NDEBUG
>> +static inline void
>> +__attribute__ ((__format__ (__printf__, 1, 2)))
>> +mm_printk(const char *fmt, ...) {}
>> +#else
>> +#define mm_printk(fmt, args...)             \
>> +    do                                      \
>> +    {                                       \
>> +        dprintk(XENLOG_ERR, fmt, ## args);  \
>> +        WARN();                             \
>> +    } while (0);
>> +#endif
>> +
>>   #define DEFINE_PAGE_TABLES(name, nr)                    \
>>   lpae_t __aligned(PAGE_SIZE) name[LPAE_ENTRIES * (nr)]
>>   
>> @@ -968,12 +981,74 @@ enum xenmap_operation {
>>       RESERVE
>>   };
>>   
>> +/* Sanity check of the entry */
>> +static bool xen_pt_check_entry(lpae_t entry, mfn_t mfn, unsigned int flags)
>> +{
>> +    /* Sanity check when modifying a page. */
>> +    if ( (flags & _PAGE_PRESENT) && mfn_eq(mfn, INVALID_MFN) )
>> +    {
> 
> I understand we could skip the valid check on REMOVE, but should we skip
> it on MODIFY too? Is that also going to be helpful in future changes?

Hmmm, I can't exactly remember why I didn't check the valid bit here.

I did it for REMOVE as for the early FDT mapping it is more convenient to remove 
the full possible range over keeping track of the exact start/size.

I would assume the same would hold for MODIFY, but I don't have a concrete 
example here. I am happy to add the valid check and defer the decision to remove 
it if it is deem to be useful in the future.

> 
> 
>> +        /* We don't allow changing memory attributes. */
>> +        if ( entry.pt.ai != PAGE_AI_MASK(flags) )
>> +        {
>> +            mm_printk("Modifying memory attributes is not allowed (0x%x -> 0x%x).\n",
>> +                      entry.pt.ai, PAGE_AI_MASK(flags));
>> +            return false;
>> +        }
>> +
>> +        /* We don't allow modifying entry with contiguous bit set. */
>> +        if ( entry.pt.contig )
>> +        {
>> +            mm_printk("Modifying entry with contiguous bit set is not allowed.\n");
>> +            return false;
>> +        }
>> +    }
>> +    /* Sanity check when inserting a page */
>> +    else if ( flags & _PAGE_PRESENT )
>> +    {
>> +        /* We should be here with a valid MFN. */
>> +        ASSERT(!mfn_eq(mfn, INVALID_MFN));
>> +
>> +        /* We don't allow replacing any valid entry. */
>> +        if ( lpae_is_valid(entry) )
>> +        {
>> +            mm_printk("Changing MFN for a valid entry is not allowed (%#"PRI_mfn" -> %#"PRI_mfn").\n",
>> +                      mfn_x(lpae_get_mfn(entry)), mfn_x(mfn));
>> +            return false;
>> +        }
>> +    }
>> +    /* Sanity check when removing a page. */
>> +    else if ( (flags & (_PAGE_PRESENT|_PAGE_POPULATE)) == 0 )
>> +    {
>> +        /* We should be here with an invalid MFN. */
>> +        ASSERT(mfn_eq(mfn, INVALID_MFN));
>> +
>> +        /* We don't allow removing page with contiguous bit set. */
>> +        if ( entry.pt.contig )
>> +        {
>> +            mm_printk("Removing entry with contiguous bit set is not allowed.\n");
>> +            return false;
>> +        }
>> +    }
>> +    /* Sanity check when populating the page-table. No check so far. */
>> +    else
>> +    {
>> +        ASSERT(flags & _PAGE_POPULATE);
>> +        /* We should be here with an invalid MFN */
>> +        ASSERT(mfn_eq(mfn, INVALID_MFN));
>> +    }
>> +
>> +    return true;
>> +}
>> +
>>   static int xen_pt_update_entry(enum xenmap_operation op, unsigned long addr,
>>                                  mfn_t mfn, unsigned int flags)
>>   {
>>       lpae_t pte, *entry;
>>       lpae_t *third = NULL;
>>   
>> +    /* _PAGE_POPULATE and _PAGE_PRESENT should never be set together. */
>> +    ASSERT((flags & (_PAGE_POPULATE|_PAGE_PRESENT)) != (_PAGE_POPULATE|_PAGE_PRESENT));
> 
> over 80 chars?

It is 87 chars, I was hoping you didn't notice it :). The line splitting result 
to nasty code. Alternatively, I could introduce a define for 
_PAGE_POPULATE|_PAGE_PRESENT, maybe EXCLUSIVE_FLAGS?

Any preference?

> 
> 
>>       entry = &xen_second[second_linear_offset(addr)];
>>       if ( !lpae_is_valid(*entry) || !lpae_is_table(*entry, 2) )
>>       {
>> @@ -989,15 +1064,12 @@ static int xen_pt_update_entry(enum xenmap_operation op, unsigned long addr,
>>       third = mfn_to_virt(lpae_get_mfn(*entry));
>>       entry = &third[third_table_offset(addr)];
>>   
>> +    if ( !xen_pt_check_entry(*entry, mfn, flags) )
>> +        return -EINVAL;
>> +
>>       switch ( op ) {
>>           case INSERT:
>>           case RESERVE:
>> -            if ( lpae_is_valid(*entry) )
>> -            {
>> -                printk("%s: trying to replace an existing mapping addr=%lx mfn=%"PRI_mfn"\n",
>> -                       __func__, addr, mfn_x(mfn));
>> -                return -EINVAL;
>> -            }
>>               if ( op == RESERVE )
>>                   break;
>>               pte = mfn_to_xen_entry(mfn, PAGE_AI_MASK(flags));
>> @@ -1009,12 +1081,6 @@ static int xen_pt_update_entry(enum xenmap_operation op, unsigned long addr,
>>               break;
>>           case MODIFY:
>>           case REMOVE:
>> -            if ( !lpae_is_valid(*entry) )
>> -            {
>> -                printk("%s: trying to %s a non-existing mapping addr=%lx\n",
>> -                       __func__, op == REMOVE ? "remove" : "modify", addr);
>> -                return -EINVAL;
>> -            }
>>               if ( op == REMOVE )
>>                   pte.bits = 0;
>>               else
>> @@ -1022,12 +1088,6 @@ static int xen_pt_update_entry(enum xenmap_operation op, unsigned long addr,
>>                   pte = *entry;
>>                   pte.pt.ro = PAGE_RO_MASK(flags);
>>                   pte.pt.xn = PAGE_XN_MASK(flags);
>> -                if ( !pte.pt.ro && !pte.pt.xn )
>> -                {
>> -                    printk("%s: Incorrect combination for addr=%lx\n",
>> -                           __func__, addr);
>> -                    return -EINVAL;
>> -                }
>>               }
>>               write_pte(entry, pte);
>>               break;
>> @@ -1049,6 +1109,25 @@ static int xen_pt_update(enum xenmap_operation op,
>>       int rc = 0;
>>       unsigned long addr = virt, addr_end = addr + nr_mfns * PAGE_SIZE;
>>   
>> +    /*
>> +     * The hardware was configured to forbid mapping both writeable and
>> +     * executable.
>> +     * When modifying/creating mapping (i.e _PAGE_PRESENT is set),
>> +     * prevent any update if this happen.
>> +     */
>> +    if ( (flags & _PAGE_PRESENT) && !PAGE_RO_MASK(flags) &&
>> +         !PAGE_XN_MASK(flags) )
>> +    {
>> +        mm_printk("Mappings should not be both Writeable and Executable.\n");
>> +        return -EINVAL;
>> +    }
> 
> I am thinking this is serious enough that we might want to always print
> this warning when this error happens. At the same time it is awkward to
> have all the other messages using mm_printk and only this one being
> different. So I'll live it to you, it is also OK at this.

Any error here means the caller didn't do sanity check (if input is external) or 
pass the wrong parameters. I purposefully chose mm_printk over a normal printk 
because this could potentially lead to a DoS if accessible from outside of Xen.

If the error happen, then there are an high chance with DEBUG (or hacking 
mm_printk to be used in non-debug build) will make it appear as well.

Cheers,

-- 
Julien Grall

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

  reply	other threads:[~2019-06-12 14:49 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-14 12:31 [PATCH MM-PART3 v2 00/12] xen/arm: Provide a generic function to update Xen PT Julien Grall
2019-05-14 12:31 ` [Xen-devel] " Julien Grall
2019-05-14 12:31 ` [PATCH MM-PART3 v2 01/12] xen/arm: lpae: Add a macro to generate offsets from an address Julien Grall
2019-05-14 12:31   ` [Xen-devel] " Julien Grall
2019-06-11 18:21   ` Stefano Stabellini
2019-06-11 18:27     ` Julien Grall
2019-05-14 12:31 ` [PATCH MM-PART3 v2 02/12] xen/arm: mm: Rename create_xen_entries() to xen_pt_update() Julien Grall
2019-05-14 12:31   ` [Xen-devel] " Julien Grall
2019-06-11 18:23   ` Stefano Stabellini
2019-05-14 12:31 ` [PATCH MM-PART3 v2 03/12] xen/arm: mm: Move out of xen_pt_update() the logic to update an entry Julien Grall
2019-05-14 12:31   ` [Xen-devel] " Julien Grall
2019-06-11 18:29   ` Stefano Stabellini
2019-05-14 12:31 ` [PATCH MM-PART3 v2 04/12] xen/arm: mm: Only increment mfn when valid in xen_pt_update Julien Grall
2019-05-14 12:31   ` [Xen-devel] " Julien Grall
2019-06-11 18:37   ` Stefano Stabellini
2019-06-11 19:56     ` [Xen-devel] Checking INVALID_MFN in mfn_add (WAS: Re: [PATCH MM-PART3 v2 04/12] xen/arm: mm: Only increment mfn when valid in xen_pt_update) Julien Grall
2019-06-11 20:24       ` Andrew Cooper
2019-06-12 12:47         ` Julien Grall
2019-06-12 15:57           ` Stefano Stabellini
2019-06-12  7:53       ` Jan Beulich
2019-05-14 12:31 ` [PATCH MM-PART3 v2 05/12] xen/arm: mm: Introduce _PAGE_PRESENT and _PAGE_POPULATE Julien Grall
2019-05-14 12:31   ` [Xen-devel] " Julien Grall
2019-06-11 22:35   ` Stefano Stabellini
2019-06-12 13:00     ` Julien Grall
2019-05-14 12:31 ` [PATCH MM-PART3 v2 06/12] xen/arm: mm: Sanity check any update of Xen page tables Julien Grall
2019-05-14 12:31   ` [Xen-devel] " Julien Grall
2019-06-12  0:10   ` Stefano Stabellini
2019-06-12 14:48     ` Julien Grall [this message]
2019-06-12 15:54       ` Stefano Stabellini
2019-06-12 15:58         ` Julien Grall
2019-05-14 12:31 ` [PATCH MM-PART3 v2 07/12] xen/arm: mm: Rework xen_pt_update_entry to avoid use xenmap_operation Julien Grall
2019-05-14 12:31   ` [Xen-devel] " Julien Grall
2019-06-12 22:22   ` Stefano Stabellini
2019-05-14 12:31 ` [PATCH MM-PART3 v2 08/12] xen/arm: mm: Remove enum xenmap_operation Julien Grall
2019-05-14 12:31   ` [Xen-devel] " Julien Grall
2019-06-11 22:38   ` Stefano Stabellini
2019-05-14 12:31 ` [PATCH MM-PART3 v2 09/12] xen/arm: mm: Use {, un}map_domain_page() to map/unmap Xen page-tables Julien Grall
2019-05-14 12:31   ` [Xen-devel] " Julien Grall
2019-06-12 22:25   ` Stefano Stabellini
2019-06-13  8:07     ` Julien Grall
2019-06-13 17:55       ` Stefano Stabellini
2019-05-14 12:31 ` [PATCH MM-PART3 v2 10/12] xen/arm: mm: Rework Xen page-tables walk during update Julien Grall
2019-05-14 12:31   ` [Xen-devel] " Julien Grall
2019-06-12 22:52   ` Stefano Stabellini
2019-06-13  8:20     ` Julien Grall
2019-06-13 17:59       ` Stefano Stabellini
2019-06-13 21:32         ` Julien Grall
2019-06-13 22:57           ` Stefano Stabellini
2019-05-14 12:31 ` [PATCH MM-PART3 v2 11/12] xen/arm: mm: Don't open-code Xen PT update in {set, clear}_fixmap() Julien Grall
2019-05-14 12:31   ` [Xen-devel] " Julien Grall
2019-06-12 22:33   ` Stefano Stabellini
2019-06-13  8:31     ` Julien Grall
2019-06-13 18:51       ` Stefano Stabellini
2019-06-13 21:21         ` Julien Grall
2019-06-13 22:55           ` Stefano Stabellini
2019-05-14 12:31 ` [PATCH MM-PART3 v2 12/12] xen/arm: mm: Remove set_pte_flags_on_range() Julien Grall
2019-05-14 12:31   ` [Xen-devel] " Julien Grall
2019-06-12 22:41   ` Stefano Stabellini
2019-06-13  8:51     ` Julien Grall
2019-06-13 18:04       ` Stefano Stabellini
2019-06-13 21:22         ` Julien Grall
2019-05-29 17:23 ` [PATCH MM-PART3 v2 00/12] xen/arm: Provide a generic function to update Xen PT Julien Grall
2019-05-29 17:23   ` [Xen-devel] " Julien Grall
2019-06-10 10:08   ` Julien Grall

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=a1921f46-f042-f167-4461-72b903a9418d@arm.com \
    --to=julien.grall@arm.com \
    --cc=Andrii_Anisov@epam.com \
    --cc=Oleksandr_Tyshchenko@epam.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.