lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 13 Oct 2008 09:49:57 -0700
From:	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
To:	bibo mao <bibo.mao@...il.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: RE: [patch 1/1]pat: fix type check error on chk_conflict function


No. This patch is not right. Inlined some comments below.

Thanks,
Venki

>-----Original Message-----
>From: linux-kernel-owner@...r.kernel.org
>[mailto:linux-kernel-owner@...r.kernel.org] On Behalf Of bibo mao
>Sent: Sunday, October 12, 2008 6:52 AM
>To: akpm@...ux-foundation.org
>Cc: linux-kernel@...r.kernel.org
>Subject: [patch 1/1]pat: fix type check error on chk_conflict function
>
> On chk_conflict() function, if new->type does not match entry->type
>  and type is not NULL, this does not go through conflict path. This
>  patch fix this bug.

No. If the type is not NULL, then new->type != entry->type is not a conflict.
In this case, the caller is looking to map some region with some type and
willing to take a type as output of reserve_memtype in "type" parameter.

So, reserve should succeed with proper type returned to the caller.

But, if type parameter is NULL, then the caller of reserve cannot really
take an output and strictly wants req_type mapping. In that case, if we have
new->type != entry->type we have to return an error. That is what the current
code is doing.

The second list_for_each_entry loop below checks for conflicting requirements
which cannot be satisfied and that will be an error in both type being NULL
and not NULL cases.

>
> Signed-off-by:  bibo.mao@...il.com
>
>----------------------------------------------------------------------
>diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
>index 12cac5e..0632308 100644
>--- a/arch/x86/mm/pat.c
>+++ b/arch/x86/mm/pat.c
>@@ -183,28 +183,29 @@ static unsigned long pat_x_mtrr_type(u64 start,
>u64 end, unsigned long req_type)
> static int chk_conflict(struct memtype *new, struct memtype *entry,
>                        unsigned long *type)
> {
>-       if (new->type != entry->type) {
>-               if (type) {
>-                       new->type = entry->type;
>-                       *type = entry->type;
>-               } else
>-                       goto conflict;
>-       }
>+       int err = -EBUSY;
>+
>+       if (new->type != entry->type)
>+               goto conflict;
>
>         /* check overlaps with more than one entry in the list */
>        list_for_each_entry_continue(entry, &memtype_list, nd) {
>                if (new->end <= entry->start)
>                        break;
>-               else if (new->type != entry->type)
>+               else if (new->type != entry->type) {
>+                       err = -EINVAL;
>                        goto conflict;
>+               }
>        }
>        return 0;
>
>  conflict:
>+       if (type)
>+               *type = entry->type;
>        printk(KERN_INFO "%s:%d conflicting memory types "
>               "%Lx-%Lx %s<->%s\n", current->comm,
>current->pid, new->start,
>               new->end, cattr_name(new->type),
>cattr_name(entry->type));
>-       return -EBUSY;
>+       return err;
> }
>
> static struct memtype *cached_entry;
>@@ -278,9 +279,6 @@ int reserve_memtype(u64 start, u64 end, unsigned
>long req_type,
>        new->end = end;
>        new->type = actual_type;
>
>-       if (new_type)
>-               *new_type = actual_type;
>-
>        spin_lock(&memtype_lock);
>
>        if (cached_entry && start >= cached_start)
>@@ -326,6 +324,9 @@ int reserve_memtype(u64 start, u64 end, unsigned
>long req_type,
>
>        spin_unlock(&memtype_lock);
>
>+       if (new_type)
>+               *new_type = actual_type;
>+
>        dprintk("reserve_memtype added 0x%Lx-0x%Lx, track %s,
>req %s, ret %s\n",
>                start, end, cattr_name(new->type),
>cattr_name(req_type),
>                new_type ? cattr_name(*new_type) : "-");
>@@ -474,15 +475,22 @@ void map_devmem(unsigned long pfn, unsigned long
>size, pgprot_t vma_prot)
>        u64 addr = (u64)pfn << PAGE_SHIFT;
>        unsigned long flags;
>        unsigned long want_flags = (pgprot_val(vma_prot) &
>_PAGE_CACHE_MASK);
>+       int err;
>
>-       reserve_memtype(addr, addr + size, want_flags, &flags);
>-       if (flags != want_flags) {
>+       err = reserve_memtype(addr, addr + size, want_flags, &flags);
>+       if (err == -EBUSY) {
>                printk(KERN_INFO
>                "%s:%d /dev/mem expected mapping type %s for
>%Lx-%Lx, got %s\n",
>                        current->comm, current->pid,
>                        cattr_name(want_flags),
>                        addr, (unsigned long long)(addr + size),
>                        cattr_name(flags));
>+       } else if (err == -EINVAL) {
>+               printk(KERN_INFO
>+               "%s:%d /dev/mem has both mapping type %s and
>%s for %Lx-%Lx \n",
>+                       current->comm, current->pid,
>+                       cattr_name(want_flags), cattr_name(flags),
>+                       addr, (unsigned long long)(addr + size));
>        }
> }
>--
>To unsubscribe from this list: send the line "unsubscribe
>linux-kernel" in
>the body of a message to majordomo@...r.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ