Re: [PATCH] powernv: Use __printf in pe_level_printk

[Michael Ellerman]

Joe Perches  writes:

> On Fri, 2016-07-15 at 14:36 +1000, Michael Ellerman wrote:
>> Joe Perches  writes:
>> > 
>> > diff --git a/arch/powerpc/platforms/powernv/pci.h
>> > b/arch/powerpc/platforms/powernv/pci.h
>> > index 3a97990..1c1a586 100644
>> > --- a/arch/powerpc/platforms/powernv/pci.h
>> > +++ b/arch/powerpc/platforms/powernv/pci.h
>> > @@ -213,6 +213,7 @@ extern void pnv_pci_dma_bus_setup(struct pci_bus
>> > *bus);
>> >  extern int pnv_setup_msi_irqs(struct pci_dev *pdev, int nvec, int
>> > type);
>> >  extern void pnv_teardown_msi_irqs(struct pci_dev *pdev);
>> >  
>> > +__printf(3, 4)
>> >  extern void pe_level_printk(const struct pnv_ioda_pe *pe, const
>> > char *level,
>> >    const char *fmt, ...);
>> Thanks, but it breaks the build due to lots of new warnings.
>> 
>> We'll have to fix those before merging it.
>
> Good.  Are you going to fix those?

Not this month.

> I thought I did a powerpc defconfig build of arch/powerpc/
> and I believe it finished without error, but I'm pleased
> it found some defects.

Hmm, I'd be surprised, but it might depend on the exact config /
compiler etc.

> I think it's now marked "rejected" in patchwork.
> Perhaps it'd better to mark it "deferred" instead.

I can do that. Though realistically I'm unlikely to go back and find it.

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] workqueue:Fix affinity of an unbound worker of a node with 1 online CPU

[Michael Ellerman]

Tejun Heo  writes:

> On Thu, Jun 16, 2016 at 02:45:48PM +0200, Peter Zijlstra wrote:
>> Subject: workqueue: Fix setting affinity of unbound worker threads
>> From: Peter Zijlstra 
>> Date: Thu Jun 16 14:38:42 CEST 2016
>> 
>> With commit e9d867a67fd03ccc ("sched: Allow per-cpu kernel threads to
>> run on online && !active"), __set_cpus_allowed_ptr() expects that only
>> strict per-cpu kernel threads can have affinity to an online CPU which
>> is not yet active.
>> 
>> This assumption is currently broken in the CPU_ONLINE notification
>> handler for the workqueues where restore_unbound_workers_cpumask()
>> calls set_cpus_allowed_ptr() when the first cpu in the unbound
>> worker's pool->attr->cpumask comes online. Since
>> set_cpus_allowed_ptr() is called with pool->attr->cpumask in which
>> only one CPU is online which is not yet active, we get the following
>> WARN_ON during an CPU online operation.
>
> Applied to wq/for-4.7-fixes.

It looks like this still hasn't gone to Linus for 4.7?

Could it please, it's a pretty nasty regression on our boxes.

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] workqueue:Fix affinity of an unbound worker of a node with 1 online CPU

[Gautham R Shenoy]

Hi Tejun,

On Thu, Jun 16, 2016 at 03:39:05PM -0400, Tejun Heo wrote:
> On Thu, Jun 16, 2016 at 02:45:48PM +0200, Peter Zijlstra wrote:
> > Subject: workqueue: Fix setting affinity of unbound worker threads
> > From: Peter Zijlstra 
> > Date: Thu Jun 16 14:38:42 CEST 2016
> > 
> > With commit e9d867a67fd03ccc ("sched: Allow per-cpu kernel threads to
> > run on online && !active"), __set_cpus_allowed_ptr() expects that only
> > strict per-cpu kernel threads can have affinity to an online CPU which
> > is not yet active.
> > 
> > This assumption is currently broken in the CPU_ONLINE notification
> > handler for the workqueues where restore_unbound_workers_cpumask()
> > calls set_cpus_allowed_ptr() when the first cpu in the unbound
> > worker's pool->attr->cpumask comes online. Since
> > set_cpus_allowed_ptr() is called with pool->attr->cpumask in which
> > only one CPU is online which is not yet active, we get the following
> > WARN_ON during an CPU online operation.
> 
> Applied to wq/for-4.7-fixes.

Did this patch get missed by any chance? It is not in
the master branch of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git yet.

We're still hitting the WARN_ON() during boot-up on the mainline kernel.
> Thanks.
> 
> -- 
> tejun
> 

--
Thanks and Regards
gautham.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powernv: Use __printf in pe_level_printk

[Joe Perches]

On Fri, 2016-07-15 at 14:36 +1000, Michael Ellerman wrote:
> Joe Perches  writes:
> 
> > 
> > Make the compiler detect format and argument mismatches.
> > 
> > Signed-off-by: Joe Perches 
> > ---
> >  arch/powerpc/platforms/powernv/pci.h | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/powerpc/platforms/powernv/pci.h
> > b/arch/powerpc/platforms/powernv/pci.h
> > index 3a97990..1c1a586 100644
> > --- a/arch/powerpc/platforms/powernv/pci.h
> > +++ b/arch/powerpc/platforms/powernv/pci.h
> > @@ -213,6 +213,7 @@ extern void pnv_pci_dma_bus_setup(struct pci_bus
> > *bus);
> >  extern int pnv_setup_msi_irqs(struct pci_dev *pdev, int nvec, int
> > type);
> >  extern void pnv_teardown_msi_irqs(struct pci_dev *pdev);
> >  
> > +__printf(3, 4)
> >  extern void pe_level_printk(const struct pnv_ioda_pe *pe, const
> > char *level,
> >     const char *fmt, ...);
> Thanks, but it breaks the build due to lots of new warnings.
> 
> We'll have to fix those before merging it.

Good.  Are you going to fix those?

I thought I did a powerpc defconfig build of arch/powerpc/
and I believe it finished without error, but I'm pleased
it found some defects.

I think it's now marked "rejected" in patchwork.
Perhaps it'd better to mark it "deferred" instead.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 02/11] mm: Hardened usercopy

[Kees Cook]

On Thu, Jul 14, 2016 at 9:05 PM, Kees Cook  wrote:
> On Thu, Jul 14, 2016 at 6:41 PM, Balbir Singh  wrote:
>> On Thu, Jul 14, 2016 at 09:04:18PM -0400, Rik van Riel wrote:
>>> On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote:
>>>
>>> > > ==
>>> > > +((unsigned long)end & (unsigned
>>> > > long)PAGE_MASK)))
>>> > > + return NULL;
>>> > > +
>>> > > + /* Allow if start and end are inside the same compound
>>> > > page. */
>>> > > + endpage = virt_to_head_page(end);
>>> > > + if (likely(endpage == page))
>>> > > + return NULL;
>>> > > +
>>> > > + /* Allow special areas, device memory, and sometimes
>>> > > kernel data. */
>>> > > + if (PageReserved(page) && PageReserved(endpage))
>>> > > + return NULL;
>>> >
>>> > If we came here, it's likely that endpage > page, do we need to check
>>> > that only the first and last pages are reserved? What about the ones
>>> > in
>>> > the middle?
>>>
>>> I think this will be so rare, we can get away with just
>>> checking the beginning and the end.
>>>
>>
>> But do we want to leave a hole where an aware user space
>> can try a longer copy_* to avoid this check? If it is unlikely
>> should we just bite the bullet and do the check for the entire
>> range?
>
> I'd be okay with expanding the test -- it should be an extremely rare
> situation already since the common Reserved areas (kernel data) will
> have already been explicitly tested.
>
> What's the best way to do "next page"? Should it just be:
>
> for ( ; page <= endpage ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr) ) {
> if (!PageReserved(page))
> return "";
> }
>
> return NULL;
>
> ?

Er, I was testing the wrong thing. How about:

/*
 * Reject if range is not Reserved (i.e. special or device memory),
 * since then the object spans several independently allocated pages.
 */
for (; ptr <= end ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr)) {
if (!PageReserved(page))
return "";
}

return NULL;



-- 
Kees Cook
Chrome OS & Brillo Security
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powernv: Use __printf in pe_level_printk

[Michael Ellerman]

Joe Perches  writes:

> Make the compiler detect format and argument mismatches.
>
> Signed-off-by: Joe Perches 
> ---
>  arch/powerpc/platforms/powernv/pci.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/platforms/powernv/pci.h 
> b/arch/powerpc/platforms/powernv/pci.h
> index 3a97990..1c1a586 100644
> --- a/arch/powerpc/platforms/powernv/pci.h
> +++ b/arch/powerpc/platforms/powernv/pci.h
> @@ -213,6 +213,7 @@ extern void pnv_pci_dma_bus_setup(struct pci_bus *bus);
>  extern int pnv_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type);
>  extern void pnv_teardown_msi_irqs(struct pci_dev *pdev);
>  
> +__printf(3, 4)
>  extern void pe_level_printk(const struct pnv_ioda_pe *pe, const char *level,
>   const char *fmt, ...);

Thanks, but it breaks the build due to lots of new warnings.

We'll have to fix those before merging it.

cheers

In file included from ../arch/powerpc/platforms/powernv/pci-ioda.c:49:0:
../arch/powerpc/platforms/powernv/pci-ioda.c: In function 
‘pnv_ioda_deconfigure_pe’:
../arch/powerpc/platforms/powernv/pci-ioda.c:784:15: error: format ‘%ld’ 
expects argument of type ‘long int’, but argument 4 has type ‘int64_t {aka long 
long int}’ [-Werror=format=]
   pe_warn(pe, "OPAL error %ld remove self from PELTV\n", rc);
   ^
../arch/powerpc/platforms/powernv/pci.h:233:36: note: in definition of macro 
‘pe_warn’
  pe_level_printk(pe, KERN_WARNING, fmt, ##__VA_ARGS__)
^~~
../arch/powerpc/platforms/powernv/pci-ioda.c:788:14: error: format ‘%ld’ 
expects argument of type ‘long int’, but argument 4 has type ‘int64_t {aka long 
long int}’ [-Werror=format=]
   pe_err(pe, "OPAL error %ld trying to setup PELT table\n", rc);
  ^
../arch/powerpc/platforms/powernv/pci.h:231:32: note: in definition of macro 
‘pe_err’
  pe_level_printk(pe, KERN_ERR, fmt, ##__VA_ARGS__)
^~~
../arch/powerpc/platforms/powernv/pci-ioda.c: In function 
‘pnv_ioda_setup_bus_PE’:
../arch/powerpc/platforms/powernv/pci-ioda.c:1095:15: error: format ‘%d’ 
expects argument of type ‘int’, but argument 4 has type ‘resource_size_t {aka 
long long unsigned int}’ [-Werror=format=]
   pe_info(pe, "Secondary bus %d..%d associated with PE#%d\n",
   ^
../arch/powerpc/platforms/powernv/pci.h:235:33: note: in definition of macro 
‘pe_info’
  pe_level_printk(pe, KERN_INFO, fmt, ##__VA_ARGS__)
 ^~~
../arch/powerpc/platforms/powernv/pci-ioda.c:1095:15: error: format ‘%d’ 
expects argument of type ‘int’, but argument 5 has type ‘resource_size_t {aka 
long long unsigned int}’ [-Werror=format=]
   pe_info(pe, "Secondary bus %d..%d associated with PE#%d\n",
   ^
../arch/powerpc/platforms/powernv/pci.h:235:33: note: in definition of macro 
‘pe_info’
  pe_level_printk(pe, KERN_INFO, fmt, ##__VA_ARGS__)
 ^~~
../arch/powerpc/platforms/powernv/pci-ioda.c:1098:15: error: format ‘%d’ 
expects argument of type ‘int’, but argument 4 has type ‘resource_size_t {aka 
long long unsigned int}’ [-Werror=format=]
   pe_info(pe, "Secondary bus %d associated with PE#%d\n",
   ^
../arch/powerpc/platforms/powernv/pci.h:235:33: note: in definition of macro 
‘pe_info’
  pe_level_printk(pe, KERN_INFO, fmt, ##__VA_ARGS__)
 ^~~
../arch/powerpc/platforms/powernv/pci-ioda.c: In function 
‘pnv_pci_ioda2_release_dma_pe’:
../arch/powerpc/platforms/powernv/pci-ioda.c:1351:15: error: format ‘%ld’ 
expects argument of type ‘long int’, but argument 4 has type ‘int64_t {aka long 
long int}’ [-Werror=format=]
   pe_warn(pe, "OPAL error %ld release DMA window\n", rc);
   ^
../arch/powerpc/platforms/powernv/pci.h:233:36: note: in definition of macro 
‘pe_warn’
  pe_level_printk(pe, KERN_WARNING, fmt, ##__VA_ARGS__)
^~~
../arch/powerpc/platforms/powernv/pci-ioda.c: In function 
‘pnv_pci_ioda1_setup_dma_pe’:
../arch/powerpc/platforms/powernv/pci-ioda.c:2093:15: error: format ‘%ld’ 
expects argument of type ‘long int’, but argument 4 has type ‘int64_t {aka long 
long int}’ [-Werror=format=]
pe_err(pe, " Failed to configure 32-bit TCE table,"
   ^
../arch/powerpc/platforms/powernv/pci.h:231:32: note: in definition of macro 
‘pe_err’
  pe_level_printk(pe, KERN_ERR, fmt, ##__VA_ARGS__)
^~~
../arch/powerpc/platforms/powernv/pci-ioda.c: In function 
‘pnv_pci_ioda2_set_window’:
../arch/powerpc/platforms/powernv/pci-ioda.c:2153:14: error: format ‘%x’ 
expects argument of type ‘unsigned int’, but argument 7 has type ‘long unsigned 
int’ [-Werror=format=]
  pe_info(pe, "Setting up window#%d %llx..%llx pg=%x\n", num,
  ^
../arch/powerpc/platforms/powernv/pci.h:235:33: note: in definition of macro 
‘pe_info’
  pe_level_printk(pe, KERN_INFO, fmt, ##__VA_ARGS__)

Re: [PATCH v2 11/11] mm: SLUB hardened usercopy support

[Kees Cook]

On Thu, Jul 14, 2016 at 7:05 PM, Balbir Singh  wrote:
> On Wed, Jul 13, 2016 at 02:56:04PM -0700, Kees Cook wrote:
>> Under CONFIG_HARDENED_USERCOPY, this adds object size checking to the
>> SLUB allocator to catch any copies that may span objects. Includes a
>> redzone handling fix from Michael Ellerman.
>>
>> Based on code from PaX and grsecurity.
>>
>> Signed-off-by: Kees Cook 
>> ---
>>  init/Kconfig |  1 +
>>  mm/slub.c| 36 
>>  2 files changed, 37 insertions(+)
>>
>> diff --git a/init/Kconfig b/init/Kconfig
>> index 798c2020ee7c..1c4711819dfd 100644
>> --- a/init/Kconfig
>> +++ b/init/Kconfig
>> @@ -1765,6 +1765,7 @@ config SLAB
>>
>>  config SLUB
>>   bool "SLUB (Unqueued Allocator)"
>> + select HAVE_HARDENED_USERCOPY_ALLOCATOR
>
> Should this patch come in earlier from a build perspective? I think
> patch 1 introduces and uses __check_heap_object.

__check_heap_object in patch 1 is protected by a check for
CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR.

It seemed better to be to do arch enablement first, and then add the
per-allocator heap object size check since it was a distinct piece.
I'm happy to rearrange things, though, if there's a good reason.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 02/11] mm: Hardened usercopy

[Kees Cook]

On Thu, Jul 14, 2016 at 4:20 PM, Balbir Singh  wrote:
> On Wed, Jul 13, 2016 at 02:55:55PM -0700, Kees Cook wrote:
>> [...]
>> +++ b/mm/usercopy.c
>> @@ -0,0 +1,219 @@
>> [...]
>> +/*
>> + * Checks if a given pointer and length is contained by the current
>> + * stack frame (if possible).
>> + *
>> + *   0: not at all on the stack
>> + *   1: fully within a valid stack frame
>> + *   2: fully on the stack (when can't do frame-checking)
>> + *   -1: error condition (invalid stack position or bad stack frame)
>
> Can we use enums? Makes it easier to read/debug

Sure, I will update this.

>> [...]
>> +static void report_usercopy(const void *ptr, unsigned long len,
>> + bool to_user, const char *type)
>> +{
>> + pr_emerg("kernel memory %s attempt detected %s %p (%s) (%lu bytes)\n",
>> + to_user ? "exposure" : "overwrite",
>> + to_user ? "from" : "to", ptr, type ? : "unknown", len);
>> + dump_stack();
>> + do_group_exit(SIGKILL);
>
> SIGKILL -- SIGBUS?

I'd like to keep SIGKILL since it indicates a process fiddling with a
kernel bug. The real problem here is that there doesn't seem to be an
arch-independent way to Oops the kernel and kill a process ("die()" is
closest, but it's defined on a per-arch basis with varying arguments).
This could be a BUG, but I'd rather not panic the entire kernel.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] linuxppc/devtree: Parse new DRC mem/cpu/dev device tree elements

[Michael Ellerman]

Nathan Fontenot  writes:

> On 06/30/2016 04:44 PM, Michael Bringmann wrote:
>> Several properties in the DRC device tree format are replaced by
>> more compact representations to allow, for example, for the encoding
>> of vast amounts of memory, and or reduced duplication of information
>> in related data structures.
...
>
> A thought, this is a big patch. Perhaps it should be split into multiple
> patches; setting the arch bit, prom updates, numa updates, hotplug
> updates...

Please.

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 02/11] mm: Hardened usercopy

[Kees Cook]

On Thu, Jul 14, 2016 at 6:41 PM, Balbir Singh  wrote:
> On Thu, Jul 14, 2016 at 09:04:18PM -0400, Rik van Riel wrote:
>> On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote:
>>
>> > > ==
>> > > +((unsigned long)end & (unsigned
>> > > long)PAGE_MASK)))
>> > > + return NULL;
>> > > +
>> > > + /* Allow if start and end are inside the same compound
>> > > page. */
>> > > + endpage = virt_to_head_page(end);
>> > > + if (likely(endpage == page))
>> > > + return NULL;
>> > > +
>> > > + /* Allow special areas, device memory, and sometimes
>> > > kernel data. */
>> > > + if (PageReserved(page) && PageReserved(endpage))
>> > > + return NULL;
>> >
>> > If we came here, it's likely that endpage > page, do we need to check
>> > that only the first and last pages are reserved? What about the ones
>> > in
>> > the middle?
>>
>> I think this will be so rare, we can get away with just
>> checking the beginning and the end.
>>
>
> But do we want to leave a hole where an aware user space
> can try a longer copy_* to avoid this check? If it is unlikely
> should we just bite the bullet and do the check for the entire
> range?

I'd be okay with expanding the test -- it should be an extremely rare
situation already since the common Reserved areas (kernel data) will
have already been explicitly tested.

What's the best way to do "next page"? Should it just be:

for ( ; page <= endpage ; ptr += PAGE_SIZE, page = virt_to_head_page(ptr) ) {
if (!PageReserved(page))
return "";
}

return NULL;

?


-- 
Kees Cook
Chrome OS & Brillo Security
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Problems with prom.h

[Christian Zigotzky]

Hi All,

We have problems with some latest stable longterm kernels.
>> I tested the kernel for some hours today. Unfortunately our computers 
>> frequently freezes or completely halts with the latest longterm kernels.

- Christian

Sent from my iPhone

> On 15 Jul 2016, at 05:39, Christian Zigotzky  wrote:
> 
> Hi All,
> 
> Mechanic reported about the same problems with the stable longterm kernel 
> 3.18.37.
> 
> Link: 
> http://forum.hyperion-entertainment.biz/viewtopic.php?f=35=2983=38389=42cf09ed83f7aa590cdac8b7c02eb281#p38389
> 
> Cheers,
> 
> Christian
> 
> Sent from my iPhone
> 
>> On 14 Jul 2016, at 20:15, Christian Zigotzky  wrote:
>> 
>> Hi All,
>> 
>> I tried to compile the kernel 4.1.28 today. Unfortunately it didn't compile 
>> because of an undeclared variable PPC_FEATURE2_HTM_NOSC_COMP.
>> 
>> Error message:
>> 
>>  CHK include/config/kernel.release
>>  CHK include/generated/uapi/linux/version.h
>>  CHK include/generated/utsrelease.h
>>  CHK include/generated/bounds.h
>>  CHK include/generated/asm-offsets.h
>>  CALLscripts/checksyscalls.sh
>>  CHK include/generated/compile.h
>>  CALLarch/powerpc/kernel/systbl_chk.sh
>>  CC  arch/powerpc/kernel/prom.o
>> arch/powerpc/kernel/prom.c:170:25: error: 'PPC_FEATURE2_HTM_NOSC_COMP' 
>> undeclared here (not in a function)
>>   PPC_FEATURE2_HTM_COMP|PPC_FEATURE2_HTM_NOSC_COMP, 22, 0, 0},
>> ^
>> make[1]: *** [arch/powerpc/kernel/prom.o] Error 1
>> make: *** [arch/powerpc/kernel] Error 2
>> 
>> I reported this issue on the Linux ppc mailing list today. After that, 
>> Michael posted a patch because of this issue. Then I compiled the kernel 
>> again and I can confirm that the patch works.
>> 
>> Further information: 
>> https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-July/145993.html
>> 
>> I tested the kernel for some hours today. Unfortunately the X1000 frequently 
>> freezes or completely halts with the kernel 4.1.28. That means, I can't 
>> release the kernel 4.1.28.
>> 
>> If you want to test it then you can download it via the following link: 
>> http://www.xenosoft.de/vmlinux-4.1.28-AmigaONE_X1000.tar.gz
>> 
>> I don't know where the problem is in the patches.
>> 
>> Linux Git log: 
>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?id=refs/tags/v4.1.28
>> 
>> ChangeLog: https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.1.28
>> 
>> Cheers,
>> 
>> Christian
>> 
>> 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Kernel 4.1.28: Update TM user feature bits in scan_features()

[Michael Ellerman]

Christian Zigotzky  writes:

> Hi Michael,
>
> I was able to compile the kernel 4.1.28 with your patch. It boots and works.

Thanks.

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [bug report] Linux-2.6.12-rc2

[Michael Ellerman]

Dan Carpenter  writes:

> Hi PPC Devs,
>
> The patch 1da177e4c3f4: "Linux-2.6.12-rc2" from Apr 16, 2005, leads

Might want to special case that one :)

> to the following static checker warning:
>
>   arch/powerpc/sysdev/ipic.c:783 ipic_set_priority()
>   error: buffer overflow 'ipic_info' 95 <= 127
...
>
>773  int ipic_set_priority(unsigned int virq, unsigned int priority)
>774  {
>775  struct ipic *ipic = ipic_from_irq(virq);
>776  unsigned int src = virq_to_hw(virq);
>777  u32 temp;
>778  
>779  if (priority > 7)
>780  return -EINVAL;
>781  if (src > 127)
> ^
> We cap this at 127
>
>782  return -EINVAL;
>783  if (ipic_info[src].prio == 0)
> ^^
> But we only have 95 elements.  Should the array be larger or should
> we >= ARRAY_SIZE(ipic_info) is invalid?

I don't know the code personally, but looking at the history it seems new
interrupts are added manually with specific flags.

So testing against ARRAY_SIZE would be the best fix AFAICS.

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 11/11] mm: SLUB hardened usercopy support

[Balbir Singh]

On Wed, Jul 13, 2016 at 02:56:04PM -0700, Kees Cook wrote:
> Under CONFIG_HARDENED_USERCOPY, this adds object size checking to the
> SLUB allocator to catch any copies that may span objects. Includes a
> redzone handling fix from Michael Ellerman.
> 
> Based on code from PaX and grsecurity.
> 
> Signed-off-by: Kees Cook 
> ---
>  init/Kconfig |  1 +
>  mm/slub.c| 36 
>  2 files changed, 37 insertions(+)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index 798c2020ee7c..1c4711819dfd 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1765,6 +1765,7 @@ config SLAB
>  
>  config SLUB
>   bool "SLUB (Unqueued Allocator)"
> + select HAVE_HARDENED_USERCOPY_ALLOCATOR

Should this patch come in earlier from a build perspective? I think
patch 1 introduces and uses __check_heap_object.

Balbir Singh.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH kernel] powerpc/mm/iommu: Put pages on process exit

[Alexey Kardashevskiy]

On 14/07/16 21:52, Alexey Kardashevskiy wrote:
> On 14/07/16 20:12, Balbir Singh wrote:
>> On Thu, Jul 14, 2016 at 3:16 PM, Alexey Kardashevskiy  wrote:
>>> At the moment VFIO IOMMU SPAPR v2 driver pins all guest RAM pages when
>>> the userspace starts using VFIO. When the userspace process finishes,
>>> all the pinned pages need to be put; this is done as a part of
>>> the userspace memory context (MM) destruction which happens on
>>> the very last mmdrop().
>>>
>>> This approach has a problem that a MM of the userspace process
>>> may live longer than the userspace process itself as kernel threads
>>> usually execute on a MM of a userspace process which was runnning
>>> on a CPU where the kernel thread was scheduled to. If this happened,
>>> the MM remains referenced until this exact kernel thread wakes up again
>>> and releases the very last reference to the MM, on an idle system this
>>> can take even hours.
>>>
>>> This fixes the issue by moving mm_iommu_cleanup() (the helper which puts
>>> pages) from destroy_context() (called on the last mmdrop()) to
>>> the arch-specific arch_exit_mmap() hook (called on the last mmput()).
>>> mmdrop() decrements the mm->mm_count which is a total reference number;
>>> mmput() decrements the mm->mm_users which is a number of user spaces and
>>> this is actually the counter we want to watch for here.
>>>
>>> Cc: David Gibson 
>>> Cc: Benjamin Herrenschmidt 
>>> Cc: Paul Mackerras 
>>> Cc: Balbir Singh 
>>> Cc: Nick Piggin 
>>> Signed-off-by: Alexey Kardashevskiy 
>>> ---
>>>  arch/powerpc/include/asm/mmu_context.h | 3 +++
>>>  arch/powerpc/mm/mmu_context_book3s64.c | 4 
>>>  2 files changed, 3 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/mmu_context.h 
>>> b/arch/powerpc/include/asm/mmu_context.h
>>> index 9d2cd0c..24b590d 100644
>>> --- a/arch/powerpc/include/asm/mmu_context.h
>>> +++ b/arch/powerpc/include/asm/mmu_context.h
>>> @@ -138,6 +138,9 @@ static inline void arch_dup_mmap(struct mm_struct 
>>> *oldmm,
>>>
>>>  static inline void arch_exit_mmap(struct mm_struct *mm)
>>>  {
>>> +#ifdef CONFIG_SPAPR_TCE_IOMMU
>>> +   mm_iommu_cleanup(>context);
>>> +#endif
>>>  }
>>>
>>
>> The assumption is that all necessary tear down has happened. Earlier
>> we were doing the teardown
>> on the last mm ref drop, do we have any dependence on that? I don't
>> think so, but just checking
>>
>> Does qemu dotce_iommu_register_pages on exit()/atexit() or do we rely
>> on the exit path to do the teardown?
> 
> QEMU does call unregister when a memory region is deleted. Handling it in
> arch_exit_mmap() is for the case when a QEMU process just dies for whatever
> reason.

After a second thought the patch is not correct, before it would actually
put pages when all references to MM were dropped and many of them are hold
by file descriptors, with this patch, pages are put before files are closed
which means that devices will not be reset and doing DMA to memory which is
not pinned but there are TCEs pointign to it.

I will make another patch, with additional mmget()/mmput().



>> Can we please remove the #ifdef CONFIG_SPAPR_TCE_IOMMU here and have a 
>> version
>> of mm_iommu_cleanup that handles it
> 
> 
> That would be a change unrelated to the fix. And I just do not see the
> point in this - mm_iommu_cleanup() is declared in the very same header.
> 
> 
>> Basically do
>>
>> #ifdef CONFIG_SPAPR_TCE_IOMMU
>> extern void mm_iommu_cleanup(void *ptr)
>> #else
>> static inline mm_iommu_cleanup(void *ptr) {}
>> #endif
>>
>> Otherwise looks good
>>
>> Acked-by: Balbir Singh 
> 
> Thanks!
> 
> 


-- 
Alexey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC 0/3] extend kexec_file_load system call

[Thiago Jung Bauermann]

Am Donnerstag, 14 Juli 2016, 10:29:11 schrieb Arnd Bergmann:
> On Wednesday, July 13, 2016 11:18:04 PM CEST Thiago Jung Bauermann wrote:
> > Am Mittwoch, 13 Juli 2016, 21:59:18 schrieb Arnd Bergmann:
> > > On Wednesday, July 13, 2016 3:45:41 PM CEST Thiago Jung Bauermann 
wrote:
> > > > Am Mittwoch, 13 Juli 2016, 15:13:42 schrieb Arnd Bergmann:
> > > > 
> > > > For secure boot, Petitboot needs to use kexec_file_load, because of
> > > > the
> > > > following two features which the system call enables:
> > > > 
> > > > 1. only allow loading of signed kernels.
> > > > 2. "measure" (i.e., record the hashes of) the kernel, initrd, kernel
> > > > 
> > > >command line and other boot inputs for the Integrity Measurement
> > > >Architecture subsystem.
> > > > 
> > > > Those can't be done with kexec_load.
> > > 
> > > Can't petitboot do both of these in user space?
> > 
> > To be honest I'm not sure if it *can't* be done from userspace but if
> > you do it from the kernel you can guarantee that any kernel image that
> > is loaded gets verified and measured.
> > 
> > Whereas if you verify and measure the kernel in userspace then if
> > there's a vulnerability in the system which allows an attacker to
> > upload their own binary, then they can use kexec_load directly and
> > bypass the verification and measurement.
> > 
> > So it's a more resilient design.
> 
> Right, but the question remains whether this helps while you allow the
> boot loader to modify the dtb. If an attacker gets in and cannot modify
> the kernel or initid but can modify the DT, a successful attack would
> be a bit harder than having a modified kernel, but you may still need
> to treat the system as compromised.

Yes, and the same question also remains regarding the kernel command line.

We can have the kernel perform sanity checks on the device tree, just as the 
kernel needs to sanity check the command line.

There's the point that was raised about not wanting to increase the attack 
surface, and that's a valid point. But at least in the way Petitboot works 
today, it needs to modify the device tree and pass it to the kernel.

One thing that is unavoidable to come from userspace is 
/chosen/linux,stdout-path, because it's Petitboot that knows from which 
console the user is interacting with. The other modification to set 
properties in vga@0 can be done in the kernel.

Given that on DTB-based systems /chosen is an important and established way 
to pass information to the operating system being booted, I'd like to 
suggest the following, then:

Extend the syscall as shown in this RFC from Takahiro AKASHI, but instead of 
accepting a complete DTB from userspace, the syscall would accept a DTB 
containing only a /chosen node. If the DTB contains any other node, the 
syscall fails with EINVAL. The kernel can then add the properties in /chosen 
to the device tree that it will pass to the next kernel.

What do you think?

-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 02/11] mm: Hardened usercopy

[Balbir Singh]

On Thu, Jul 14, 2016 at 09:04:18PM -0400, Rik van Riel wrote:
> On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote:
> 
> > > ==
> > > +    ((unsigned long)end & (unsigned
> > > long)PAGE_MASK)))
> > > + return NULL;
> > > +
> > > + /* Allow if start and end are inside the same compound
> > > page. */
> > > + endpage = virt_to_head_page(end);
> > > + if (likely(endpage == page))
> > > + return NULL;
> > > +
> > > + /* Allow special areas, device memory, and sometimes
> > > kernel data. */
> > > + if (PageReserved(page) && PageReserved(endpage))
> > > + return NULL;
> > 
> > If we came here, it's likely that endpage > page, do we need to check
> > that only the first and last pages are reserved? What about the ones
> > in
> > the middle?
> 
> I think this will be so rare, we can get away with just
> checking the beginning and the end.
>

But do we want to leave a hole where an aware user space
can try a longer copy_* to avoid this check? If it is unlikely
should we just bite the bullet and do the check for the entire
range?

Balbir Singh. 


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 02/11] mm: Hardened usercopy

[Rik van Riel]

On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote:

> > ==
> > +      ((unsigned long)end & (unsigned
> > long)PAGE_MASK)))
> > +   return NULL;
> > +
> > +   /* Allow if start and end are inside the same compound
> > page. */
> > +   endpage = virt_to_head_page(end);
> > +   if (likely(endpage == page))
> > +   return NULL;
> > +
> > +   /* Allow special areas, device memory, and sometimes
> > kernel data. */
> > +   if (PageReserved(page) && PageReserved(endpage))
> > +   return NULL;
> 
> If we came here, it's likely that endpage > page, do we need to check
> that only the first and last pages are reserved? What about the ones
> in
> the middle?

I think this will be so rare, we can get away with just
checking the beginning and the end.

-- 

All Rights Reversed.

signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [patch V2 30/67] powerpc/numa: Convert to hotplug state machine

[Anton Blanchard via Linuxppc-dev]

Hi Anna-Maria,

> >> Install the callbacks via the state machine and let the core invoke
> >> the callbacks on the already online CPUs.  
> >
> > This is causing an oops on ppc64le QEMU, looks like a NULL
> > pointer:  
> 
> Did you tested it against tip WIP.hotplug?

I noticed tip started failing in my CI environment which tests on QEMU.
The failure bisected to commit 425209e0abaf2c6e3a90ce4fedb935c10652bf80

It reproduces running ppc64le QEMU on a x86-64 box. On Ubuntu:

sudo apt-get install qemu-system-ppc gcc-powerpc64le-linux-gnu

make ARCH=powerpc pseries_le_defconfig

make ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- vmlinux -j4

qemu-system-ppc64 -nographic -vga none -kernel vmlinux 

Anton
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [patch V2 30/67] powerpc/numa: Convert to hotplug state machine

[Anna-Maria Gleixner]

Hi,

On 2016-07-14 23:42, Anton Blanchard wrote:

Hi,


From: Sebastian Andrzej Siewior 

Install the callbacks via the state machine and let the core invoke
the callbacks on the already online CPUs.


This is causing an oops on ppc64le QEMU, looks like a NULL pointer:


Did you tested it against tip WIP.hotplug?

Regards,
 Anna-Maria
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 02/11] mm: Hardened usercopy

[Balbir Singh]

On Wed, Jul 13, 2016 at 02:55:55PM -0700, Kees Cook wrote:
> This is the start of porting PAX_USERCOPY into the mainline kernel. This
> is the first set of features, controlled by CONFIG_HARDENED_USERCOPY. The
> work is based on code by PaX Team and Brad Spengler, and an earlier port
> from Casey Schaufler. Additional non-slab page tests are from Rik van Riel.
> 
> This patch contains the logic for validating several conditions when
> performing copy_to_user() and copy_from_user() on the kernel object
> being copied to/from:
> - address range doesn't wrap around
> - address range isn't NULL or zero-allocated (with a non-zero copy size)
> - if on the slab allocator:
>   - object size must be less than or equal to copy size (when check is
> implemented in the allocator, which appear in subsequent patches)
> - otherwise, object must not span page allocations
> - if on the stack
>   - object must not extend before/after the current process task
>   - object must be contained by the current stack frame (when there is
> arch/build support for identifying stack frames)
> - object must not overlap with kernel text
> 
> Signed-off-by: Kees Cook 
> ---
>  arch/Kconfig|   7 ++
>  include/linux/slab.h|  12 +++
>  include/linux/thread_info.h |  15 +++
>  mm/Makefile |   4 +
>  mm/usercopy.c   | 219 
> 
>  security/Kconfig|  27 ++
>  6 files changed, 284 insertions(+)
>  create mode 100644 mm/usercopy.c
> 
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 5e2776562035..195ee4cc939a 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -433,6 +433,13 @@ config HAVE_ARCH_WITHIN_STACK_FRAMES
> and similar) by implementing an inline arch_within_stack_frames(),
> which is used by CONFIG_HARDENED_USERCOPY.
>  
> +config HAVE_ARCH_LINEAR_KERNEL_MAPPING
> + bool
> + help
> +   An architecture should select this if it has a secondary linear
> +   mapping of the kernel text. This is used to verify that kernel
> +   text exposures are not visible under CONFIG_HARDENED_USERCOPY.
> +
>  config HAVE_CONTEXT_TRACKING
>   bool
>   help
> diff --git a/include/linux/slab.h b/include/linux/slab.h
> index aeb3e6d00a66..96a16a3fb7cb 100644
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -155,6 +155,18 @@ void kfree(const void *);
>  void kzfree(const void *);
>  size_t ksize(const void *);
>  
> +#ifdef CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR
> +const char *__check_heap_object(const void *ptr, unsigned long n,
> + struct page *page);
> +#else
> +static inline const char *__check_heap_object(const void *ptr,
> +   unsigned long n,
> +   struct page *page)
> +{
> + return NULL;
> +}
> +#endif
> +
>  /*
>   * Some archs want to perform DMA into kmalloc caches and need a guaranteed
>   * alignment larger than the alignment of a 64-bit integer.
> diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h
> index 3d5c80b4391d..f24b99eac969 100644
> --- a/include/linux/thread_info.h
> +++ b/include/linux/thread_info.h
> @@ -155,6 +155,21 @@ static inline int arch_within_stack_frames(const void * 
> const stack,
>  }
>  #endif
>  
> +#ifdef CONFIG_HARDENED_USERCOPY
> +extern void __check_object_size(const void *ptr, unsigned long n,
> + bool to_user);
> +
> +static inline void check_object_size(const void *ptr, unsigned long n,
> +  bool to_user)
> +{
> + __check_object_size(ptr, n, to_user);
> +}
> +#else
> +static inline void check_object_size(const void *ptr, unsigned long n,
> +  bool to_user)
> +{ }
> +#endif /* CONFIG_HARDENED_USERCOPY */
> +
>  #endif   /* __KERNEL__ */
>  
>  #endif /* _LINUX_THREAD_INFO_H */
> diff --git a/mm/Makefile b/mm/Makefile
> index 78c6f7dedb83..32d37247c7e5 100644
> --- a/mm/Makefile
> +++ b/mm/Makefile
> @@ -21,6 +21,9 @@ KCOV_INSTRUMENT_memcontrol.o := n
>  KCOV_INSTRUMENT_mmzone.o := n
>  KCOV_INSTRUMENT_vmstat.o := n
>  
> +# Since __builtin_frame_address does work as used, disable the warning.
> +CFLAGS_usercopy.o += $(call cc-disable-warning, frame-address)
> +
>  mmu-y:= nommu.o
>  mmu-$(CONFIG_MMU):= gup.o highmem.o memory.o mincore.o \
>  mlock.o mmap.o mprotect.o mremap.o msync.o rmap.o \
> @@ -99,3 +102,4 @@ obj-$(CONFIG_USERFAULTFD) += userfaultfd.o
>  obj-$(CONFIG_IDLE_PAGE_TRACKING) += page_idle.o
>  obj-$(CONFIG_FRAME_VECTOR) += frame_vector.o
>  obj-$(CONFIG_DEBUG_PAGE_REF) += debug_page_ref.o
> +obj-$(CONFIG_HARDENED_USERCOPY) += usercopy.o
> diff --git a/mm/usercopy.c b/mm/usercopy.c
> new file mode 100644
> index ..4161a1fb1909
> --- /dev/null
> +++ b/mm/usercopy.c
> @@ -0,0 +1,219 @@
> +/*
> + * This 

[bug report] powerpc/qe: Increase MAX_QE_RISC to 4

[Dan Carpenter]

Hello Anton Vorontsov,

The patch 98eaa0987afd: "powerpc/qe: Increase MAX_QE_RISC to 4" from
Aug 27, 2009, leads to the following static checker warning:

drivers/soc/fsl/qe/qe.c:524 qe_upload_firmware()
error: buffer overflow 'qe_immr->rsp' 2 <= 3

drivers/soc/fsl/qe/qe.c
   425  int qe_upload_firmware(const struct qe_firmware *firmware)
   426  {
   427  unsigned int i;
   428  unsigned int j;
   429  u32 crc;
   430  size_t calc_size = sizeof(struct qe_firmware);
   431  size_t length;
   432  const struct qe_header *hdr;
   433  
   434  if (!firmware) {
   435  printk(KERN_ERR "qe-firmware: invalid pointer\n");
   436  return -EINVAL;
   437  }
   438  
   439  hdr = >header;
   440  length = be32_to_cpu(hdr->length);
   441  
   442  /* Check the magic */
   443  if ((hdr->magic[0] != 'Q') || (hdr->magic[1] != 'E') ||
   444  (hdr->magic[2] != 'F')) {
   445  printk(KERN_ERR "qe-firmware: not a microcode\n");
   446  return -EPERM;
   447  }
   448  
   449  /* Check the version */
   450  if (hdr->version != 1) {
   451  printk(KERN_ERR "qe-firmware: unsupported version\n");
   452  return -EPERM;
   453  }
   454  
   455  /* Validate some of the fields */
   456  if ((firmware->count < 1) || (firmware->count > MAX_QE_RISC)) {
  ^
This used to be capped at 2.


   457  printk(KERN_ERR "qe-firmware: invalid data\n");
   458  return -EINVAL;
   459  }
   460  
   461  /* Validate the length and check if there's a CRC */
   462  calc_size += (firmware->count - 1) * sizeof(struct 
qe_microcode);
   463  
   464  for (i = 0; i < firmware->count; i++)
   465  /*
   466   * For situations where the second RISC uses the same 
microcode
   467   * as the first, the 'code_offset' and 'count' fields 
will be
   468   * zero, so it's okay to add those.
   469   */
   470  calc_size += sizeof(__be32) *
   471  be32_to_cpu(firmware->microcode[i].count);
   472  
   473  /* Validate the length */
   474  if (length != calc_size + sizeof(__be32)) {
   475  printk(KERN_ERR "qe-firmware: invalid length\n");
   476  return -EPERM;
   477  }
   478  
   479  /* Validate the CRC */
   480  crc = be32_to_cpu(*(__be32 *)((void *)firmware + calc_size));
   481  if (crc != crc32(0, firmware, calc_size)) {
   482  printk(KERN_ERR "qe-firmware: firmware CRC is 
invalid\n");
   483  return -EIO;
   484  }
   485  
   486  /*
   487   * If the microcode calls for it, split the I-RAM.
   488   */
   489  if (!firmware->split)
   490  setbits16(_immr->cp.cercr, QE_CP_CERCR_CIR);
   491  
   492  if (firmware->soc.model)
   493  printk(KERN_INFO
   494  "qe-firmware: firmware '%s' for %u V%u.%u\n",
   495  firmware->id, be16_to_cpu(firmware->soc.model),
   496  firmware->soc.major, firmware->soc.minor);
   497  else
   498  printk(KERN_INFO "qe-firmware: firmware '%s'\n",
   499  firmware->id);
   500  
   501  /*
   502   * The QE only supports one microcode per RISC, so clear out 
all the
   503   * saved microcode information and put in the new.
   504   */
   505  memset(_firmware_info, 0, sizeof(qe_firmware_info));
   506  strlcpy(qe_firmware_info.id, firmware->id, 
sizeof(qe_firmware_info.id));
   507  qe_firmware_info.extended_modes = firmware->extended_modes;
   508  memcpy(qe_firmware_info.vtraps, firmware->vtraps,
   509  sizeof(firmware->vtraps));
   510  
   511  /* Loop through each microcode. */
   512  for (i = 0; i < firmware->count; i++) {
   513  const struct qe_microcode *ucode = 
>microcode[i];
   514  
   515  /* Upload a microcode if it's present */
   516  if (ucode->code_offset)
   517  qe_upload_microcode(firmware, ucode);
   518  
   519  /* Program the traps for this processor */
   520  for (j = 0; j < 16; j++) {
   521  u32 trap = be32_to_cpu(ucode->traps[j]);
   522  
   523  if (trap)
   524  out_be32(_immr->rsp[i].tibcr[j], 
trap);
   ^^
   525 

[bug report] Linux-2.6.12-rc2

[Dan Carpenter]

Hi PPC Devs,

The patch 1da177e4c3f4: "Linux-2.6.12-rc2" from Apr 16, 2005, leads
to the following static checker warning:

arch/powerpc/sysdev/ipic.c:783 ipic_set_priority()
error: buffer overflow 'ipic_info' 95 <= 127

arch/powerpc/sysdev/ipic.c
36  static struct ipic_info ipic_info[] = {
37  [1] = {
38  .mask   = IPIC_SIMSR_H,
39  .prio   = IPIC_SIPRR_C,
40  .force  = IPIC_SIFCR_H,
41  .bit= 16,
42  .prio_mask = 0,
43  },

 [ huge 95 element array snipped ]

   500  [94] = {
   501  .mask   = IPIC_SIMSR_L,
   502  .prio   = 0,
   503  .force  = IPIC_SIFCR_L,
   504  .bit= 30,
   505  },
   506  };

 [ more code snipped ]

   773  int ipic_set_priority(unsigned int virq, unsigned int priority)
   774  {
   775  struct ipic *ipic = ipic_from_irq(virq);
   776  unsigned int src = virq_to_hw(virq);
   777  u32 temp;
   778  
   779  if (priority > 7)
   780  return -EINVAL;
   781  if (src > 127)
^
We cap this at 127

   782  return -EINVAL;
   783  if (ipic_info[src].prio == 0)
^^
But we only have 95 elements.  Should the array be larger or should
we >= ARRAY_SIZE(ipic_info) is invalid?

   784  return -EINVAL;
   785  

regards,
dan carpenter
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[bug report] cxl: Add guest-specific code

[Dan Carpenter]

Hello Christophe Lombard,

The patch 14baf4d9c739: "cxl: Add guest-specific code" from Mar 4,
2016, leads to the following static checker warning:

drivers/misc/cxl/guest.c:1115 cxl_guest_init_adapter()
error: we previously assumed 'adapter->guest' could be null (see line 
1114)

drivers/misc/cxl/guest.c
  1105  struct cxl *cxl_guest_init_adapter(struct device_node *np, struct 
platform_device *pdev)
  1106  {
  1107  struct cxl *adapter;
  1108  bool free = true;
  1109  int rc;
  1110  
    if (!(adapter = cxl_alloc_adapter()))
  1112  return ERR_PTR(-ENOMEM);
  1113  
  1114  if (!(adapter->guest = kzalloc(sizeof(struct cxl_guest), 
GFP_KERNEL))) {
  1115  free_adapter(adapter);
^
We can't call free_adapter() if adapter->guest is NULL.

  1116  return ERR_PTR(-ENOMEM);
  1117  }


drivers/misc/cxl/guest.c:919 afu_properties_look_ok()
warn: unsigned 'afu->crs_len' is never less than zero.

drivers/misc/cxl/guest.c
   907  static int afu_properties_look_ok(struct cxl_afu *afu)
   908  {
   909  if (afu->pp_irqs < 0) {
   910  dev_err(>dev, "Unexpected per-process minimum 
interrupt value\n");
   911  return -EINVAL;
   912  }
   913  
   914  if (afu->max_procs_virtualised < 1) {
   915  dev_err(>dev, "Unexpected max number of processes 
virtualised value\n");
   916  return -EINVAL;
   917  }
   918  
   919  if (afu->crs_len < 0) {

Remove this test.  Unsigned is never less than zero.

   920  dev_err(>dev, "Unexpected configuration record 
size value\n");
   921  return -EINVAL;
   922  }
   923  
   924  return 0;
   925  }


regards,
dan carpenter
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [patch V2 30/67] powerpc/numa: Convert to hotplug state machine

[Anton Blanchard via Linuxppc-dev]

Hi,

> From: Sebastian Andrzej Siewior 
> 
> Install the callbacks via the state machine and let the core invoke
> the callbacks on the already online CPUs.

This is causing an oops on ppc64le QEMU, looks like a NULL pointer:

percpu: Embedded 3 pages/cpu @c0001fe0 s145816 r0 d50792 u1048576
Unable to handle kernel paging request for data at address 0x1e08
Faulting instruction address: 0xc01e6b78
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0-rc7-00198-g425209e #14
task: c0d82a00 ti: c0dc4000 task.ti: c0dc4000
NIP: c01e6b78 LR: c01e6df4 CTR: 
REGS: c0dc7b60 TRAP: 0300   Not tainted  (4.7.0-rc7-00198-g425209e)
MSR: 82001033   CR: 44000220  XER: 
CFAR: 8468 DAR: 1e08 DSISR: 4000 SOFTE: 0 
GPR00: 0006 c0dc7de0 c0dc6c00  
GPR04:   c0001fe1fb70 0010 
GPR08: c0dfe918 c0e50dd0 c0e56c00 0001 
GPR12:  cfe0 0060 00f1d618 
GPR16: 00efccd8 00efcb20 fffd  
GPR20: 1f15 c0dfa8e0 c0ccfafc c0dfeb18 
GPR24: c0dfee34 c0ccfaf8  0001 
GPR28: c0ebad20 c0ccfb00  c0001fe1fb00 
NIP [c01e6b78] local_memory_node+0x18/0x80
LR [c01e6df4] __build_all_zonelists+0x214/0x2d0
Call Trace:
[c0dc7de0] [c01e6ccc] __build_all_zonelists+0xec/0x2d0 
(unreliable)
[c0dc7e70] [c0c39fbc] build_all_zonelists_init+0x1c/0x3c
[c0dc7e90] [c0282acc] build_all_zonelists+0x17c/0x18c
[c0dc7f00] [c0c13c54] start_kernel+0x18c/0x514
[c0dc7f90] [c0008c60] start_here_common+0x20/0xa0
Instruction dump:
38810178 7f63db78 48769171 6000 4bfffd2c 6042 3c4c00be 384200a0 
3d420009 78631f24 392aa1d0 7c69182a <81231e08> 38631e00 2b890002 419d001c 

Anton

> Signed-off-by: Sebastian Andrzej Siewior 
> Cc: Andrew Morton 
> Cc: Benjamin Herrenschmidt 
> Cc: Bharata B Rao 
> Cc: Christophe Jaillet 
> Cc: Linus Torvalds 
> Cc: Michael Ellerman 
> Cc: Nikunj A Dadhania 
> Cc: Paul Mackerras 
> Cc: Peter Zijlstra 
> Cc: Raghavendra K T 
> Cc: Thomas Gleixner 
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Anna-Maria Gleixner 
> ---
>  arch/powerpc/mm/numa.c | 46
> --
> include/linux/cpuhotplug.h |  1 + 2 files changed, 17 insertions(+),
> 30 deletions(-)
> 
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 669a15e..d48ac48 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -581,30 +581,22 @@ static void verify_cpu_node_mapping(int cpu,
> int node) }
>  }
>  
> -static int cpu_numa_callback(struct notifier_block *nfb, unsigned
> long action,
> -  void *hcpu)
> +/* Must run before sched domains notifier. */
> +static int ppc_numa_cpu_prepare(unsigned int cpu)
>  {
> - unsigned long lcpu = (unsigned long)hcpu;
> - int ret = NOTIFY_DONE, nid;
> + int nid;
>  
> - switch (action) {
> - case CPU_UP_PREPARE:
> - case CPU_UP_PREPARE_FROZEN:
> - nid = numa_setup_cpu(lcpu);
> - verify_cpu_node_mapping((int)lcpu, nid);
> - ret = NOTIFY_OK;
> - break;
> + nid = numa_setup_cpu(cpu);
> + verify_cpu_node_mapping(cpu, nid);
> + return 0;
> +}
> +
> +static int ppc_numa_cpu_dead(unsigned int cpu)
> +{
>  #ifdef CONFIG_HOTPLUG_CPU
> - case CPU_DEAD:
> - case CPU_DEAD_FROZEN:
> - case CPU_UP_CANCELED:
> - case CPU_UP_CANCELED_FROZEN:
> - unmap_cpu_from_node(lcpu);
> - ret = NOTIFY_OK;
> - break;
> + unmap_cpu_from_node(cpu);
>  #endif
> - }
> - return ret;
> + return 0;
>  }
>  
>  /*
> @@ -913,11 +905,6 @@ static void __init
> dump_numa_memory_topology(void) }
>  }
>  
> -static struct notifier_block ppc64_numa_nb = {
> - .notifier_call = cpu_numa_callback,
> - .priority = 1 /* Must run before sched domains notifier. */
> -};
> -
>  /* Initialize NODE_DATA for a node on the local memory */
>  static void __init setup_node_data(int nid, u64 start_pfn, u64
> end_pfn) {
> @@ -953,7 +940,7 @@ static void __init setup_node_data(int nid, u64
> start_pfn, u64 end_pfn) 
>  void __init initmem_init(void)
> 

Kernel 4.1.28: Update TM user feature bits in scan_features()

[Christian Zigotzky]

Hi Michael,

I was able to compile the kernel 4.1.28 with your patch. It boots and works.

Thanks,

Christian

On 14 July 2016 at 1:33 PM, Christian Zigotzky wrote:

Hi Michael,

When I received your email with your solution, I had already compiled 
the kernel 4.1.28 with the following temporary solution:


Not suitable for 4.1-stable (no PPC_FEATURE2_HTM_NOSC_COMP).

- * If the kernel doesn't support TM (ie 
CONFIG_PPC_TRANSACTIONAL_MEM=n),

- * we don't want to turn on TM here, so we use the *_COMP versions
- * which are 0 if the kernel doesn't support TM.
+ * If the kernel doesn't support TM (ie. 
CONFIG_PPC_TRANSACTIONAL_MEM=n),
+ * we don't want to turn on CPU_FTR_TM here, so we use 
CPU_FTR_TM_COMP

+ * which is 0 if the kernel doesn't support TM.
  */
-{CPU_FTR_TM_COMP, 0, 0,
- PPC_FEATURE2_HTM_COMP|PPC_FEATURE2_HTM_NOSC_COMP, 22, 0, 0},
+{CPU_FTR_TM_COMP, 0, 0, 0,22, 0, 0},
 };

The kernel boots and KVM PR works. I tested it with Mac-on-Linux/KVM 
PR and Mac OS X Tiger as guest system. I will try your solution too.


Many thanks for your fast response!

Cheers,

Christian


On 14 July 2016 at 1:10 PM, Michael Ellerman wrote:

Christian Zigotzky  writes:


Hi All,

I tried to compile the kernel 4.1.28 today. Unfortunately it doesn't
compile because of an undeclared variable PPC_FEATURE2_HTM_NOSC_COMP.

Error message:

CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK include/generated/bounds.h
CHK include/generated/asm-offsets.h
CALLscripts/checksyscalls.sh
CHK include/generated/compile.h
CALLarch/powerpc/kernel/systbl_chk.sh
CC  arch/powerpc/kernel/prom.o
arch/powerpc/kernel/prom.c:170:25: error: 'PPC_FEATURE2_HTM_NOSC_COMP'
undeclared here (not in a function)
 PPC_FEATURE2_HTM_COMP|PPC_FEATURE2_HTM_NOSC_COMP, 22, 0, 0},
   ^
make[1]: *** [arch/powerpc/kernel/prom.o] Error 1
make: *** [arch/powerpc/kernel] Error 2

---

Commit:

f49eb503f0f9ab66874a81992b14249a1c59b6ad
Author: Anton Blanchard
Date:   Fri Apr 15 12:08:19 2016 +1000

  powerpc: Update TM user feature bits in scan_features()

  [ Upstream commit 4705e02498d6d5a7ab98dfee9595cd5e91db2017 ]

  We need to update the user TM feature bits (PPC_FEATURE2_HTM and
  PPC_FEATURE2_HTM) to mirror what we do with the kernel TM feature
  bit.

  At the moment, if firmware reports TM is not available we turn off
  the kernel TM feature bit but leave the userspace ones on. Userspace
  thinks it can execute TM instructions and it dies trying.

  This (together with a QEMU patch) fixes PR KVM, which doesn't currently
  support TM.

  Signed-off-by: Anton Blanchard
  Cc:sta...@vger.kernel.org
  Signed-off-by: Michael Ellerman
  Signed-off-by: Sasha Levin

---

PPC_FEATURE2_HTM_NOSC_COMP isn't defined or doesn't exist in the
following files:

Thanks.


arch/powerpc/include/asm/cputable.h
arch/powerpc/kernel/cputable.c
arch/powerpc/include/uapi/asm/tm.h

That means the following patches aren't included in the 4.1.28 source code:

Sorry that's the wrong fix.

PPC_FEATURE2_HTM_NOSC indicates the presence of a certain kernel
behaviour, which has *not* been backported to 4.1.

The right fix is just to remove the reference to PPC_FEATURE2_HTM_NOSC
in 4.1.28.

eg:

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 28dbbb0d12c4..9b19d96e9562 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -166,8 +166,7 @@ static struct ibm_pa_feature {
 * we don't want to turn on TM here, so we use the *_COMP versions
 * which are 0 if the kernel doesn't support TM.
 */
-   {CPU_FTR_TM_COMP, 0, 0,
-PPC_FEATURE2_HTM_COMP|PPC_FEATURE2_HTM_NOSC_COMP, 22, 0, 0},
+   {CPU_FTR_TM_COMP, 0, 0, PPC_FEATURE2_HTM_COMP, 22, 0, 0},
  };
  
  static void __init scan_features(unsigned long node, const unsigned char *ftrs,




cheers





___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 01/11] mm: Implement stack frame object validation

[Kees Cook]

On Thu, Jul 14, 2016 at 12:23 PM, Josh Poimboeuf  wrote:
> On Thu, Jul 14, 2016 at 11:10:18AM -0700, Kees Cook wrote:
>> On Wed, Jul 13, 2016 at 10:48 PM, Josh Poimboeuf  wrote:
>> > On Wed, Jul 13, 2016 at 03:04:26PM -0700, Kees Cook wrote:
>> >> On Wed, Jul 13, 2016 at 3:01 PM, Andy Lutomirski  
>> >> wrote:
>> >> > On Wed, Jul 13, 2016 at 2:55 PM, Kees Cook  
>> >> > wrote:
>> >> >> This creates per-architecture function arch_within_stack_frames() that
>> >> >> should validate if a given object is contained by a kernel stack frame.
>> >> >> Initial implementation is on x86.
>> >> >>
>> >> >> This is based on code from PaX.
>> >> >>
>> >> >
>> >> > This, along with Josh's livepatch work, are two examples of unwinders
>> >> > that matter for correctness instead of just debugging.  ISTM this
>> >> > should just use Josh's code directly once it's been written.
>> >>
>> >> Do you have URL for Josh's code? I'd love to see what happening there.
>> >
>> > The code is actually going to be 100% different next time around, but
>> > FWIW, here's the last attempt:
>> >
>> >   
>> > https://lkml.kernel.org/r/4d34d452bf8f85c7d6d5f93db1d3eeb4cba335c7.1461875890.git.jpoim...@redhat.com
>> >
>> > In the meantime I've realized the need to rewrite the x86 core stack
>> > walking code to something much more manageable so we don't need all
>> > these unwinders everywhere.  I'll probably post the patches in the next
>> > week or so.  I'll add you to the CC list.
>>
>> Awesome!
>>
>> > With the new interface I think you'll be able to do something like:
>> >
>> > struct unwind_state;
>> >
>> > unwind_start(, current, NULL, NULL);
>> > unwind_next_frame();
>> > oldframe = unwind_get_stack_pointer();
>> >
>> > unwind_next_frame();
>> > frame = unwind_get_stack_pointer();
>> >
>> > do {
>> > if (obj + len <= frame)
>> > return blah;
>> > oldframe = frame;
>> > frame = unwind_get_stack_pointer();
>> >
>> > } while (unwind_next_frame();
>> >
>> > And then at the end there'll be some (still TBD) way to query whether it
>> > reached the last syscall pt_regs frame, or if it instead encountered a
>> > bogus frame pointer along the way and had to bail early.
>>
>> Sounds good to me. Will there be any frame size information available?
>> Right now, the unwinder from PaX just drops 2 pointers (saved frame,
>> saved ip) from the delta of frame address to find the size of the
>> actual stack area used by the function. If I could shave things like
>> padding and possible stack canaries off the size too, that would be
>> great.
>
> For x86, stacks are aligned at long word boundaries, so there's no real
> stack padding.

Well, I guess I meant the possible padding between variables and the
aligned pointers, but that's a really minor concern in my mind (as far
as being a potential kernel memory exposure on a bad usercopy).

> Also the CC_STACKPROTECTOR stack canaries are created by a gcc feature
> which only affects certain functions (and thus certain frames) and I
> don't know of any reliable way to find them.

Okay, that's fine. I had a horrible idea to just have the unwinder
look at the value stored in front of the saved ip, and if it matches
the known canary (for current anyway), then reduce the frame size by
another long word. ;)

> So with frame pointers, I think the best you can do is just assume that
> the frame data area is always two words smaller than the total frame
> size.

Yeah, that's what's happening here currently. Cool.

>> Since I'm aiming the hardened usercopy series for 4.8, I figure I'll
>> just leave this unwinder in for now, and once yours lands, I can rip
>> it out again.
>
> Sure, sounds fine to me.  If your code lands before I post mine, I can
> convert it myself.

Awesome, I'll keep you posted. Thanks!

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 01/11] mm: Implement stack frame object validation

[Josh Poimboeuf]

On Thu, Jul 14, 2016 at 11:10:18AM -0700, Kees Cook wrote:
> On Wed, Jul 13, 2016 at 10:48 PM, Josh Poimboeuf  wrote:
> > On Wed, Jul 13, 2016 at 03:04:26PM -0700, Kees Cook wrote:
> >> On Wed, Jul 13, 2016 at 3:01 PM, Andy Lutomirski  
> >> wrote:
> >> > On Wed, Jul 13, 2016 at 2:55 PM, Kees Cook  wrote:
> >> >> This creates per-architecture function arch_within_stack_frames() that
> >> >> should validate if a given object is contained by a kernel stack frame.
> >> >> Initial implementation is on x86.
> >> >>
> >> >> This is based on code from PaX.
> >> >>
> >> >
> >> > This, along with Josh's livepatch work, are two examples of unwinders
> >> > that matter for correctness instead of just debugging.  ISTM this
> >> > should just use Josh's code directly once it's been written.
> >>
> >> Do you have URL for Josh's code? I'd love to see what happening there.
> >
> > The code is actually going to be 100% different next time around, but
> > FWIW, here's the last attempt:
> >
> >   
> > https://lkml.kernel.org/r/4d34d452bf8f85c7d6d5f93db1d3eeb4cba335c7.1461875890.git.jpoim...@redhat.com
> >
> > In the meantime I've realized the need to rewrite the x86 core stack
> > walking code to something much more manageable so we don't need all
> > these unwinders everywhere.  I'll probably post the patches in the next
> > week or so.  I'll add you to the CC list.
> 
> Awesome!
> 
> > With the new interface I think you'll be able to do something like:
> >
> > struct unwind_state;
> >
> > unwind_start(, current, NULL, NULL);
> > unwind_next_frame();
> > oldframe = unwind_get_stack_pointer();
> >
> > unwind_next_frame();
> > frame = unwind_get_stack_pointer();
> >
> > do {
> > if (obj + len <= frame)
> > return blah;
> > oldframe = frame;
> > frame = unwind_get_stack_pointer();
> >
> > } while (unwind_next_frame();
> >
> > And then at the end there'll be some (still TBD) way to query whether it
> > reached the last syscall pt_regs frame, or if it instead encountered a
> > bogus frame pointer along the way and had to bail early.
> 
> Sounds good to me. Will there be any frame size information available?
> Right now, the unwinder from PaX just drops 2 pointers (saved frame,
> saved ip) from the delta of frame address to find the size of the
> actual stack area used by the function. If I could shave things like
> padding and possible stack canaries off the size too, that would be
> great.

For x86, stacks are aligned at long word boundaries, so there's no real
stack padding.

Also the CC_STACKPROTECTOR stack canaries are created by a gcc feature
which only affects certain functions (and thus certain frames) and I
don't know of any reliable way to find them.

So with frame pointers, I think the best you can do is just assume that
the frame data area is always two words smaller than the total frame
size.

> Since I'm aiming the hardened usercopy series for 4.8, I figure I'll
> just leave this unwinder in for now, and once yours lands, I can rip
> it out again.

Sure, sounds fine to me.  If your code lands before I post mine, I can
convert it myself.

-- 
Josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH for -mm] signal: Consolidate {TS,TLF}_RESTORE_SIGMASK code

[Andy Lutomirski]

In general, there's no need for the "restore sigmask" flag to live in
ti->flags.  alpha, ia64, microblaze, powerpc, sh, sparc (64-bit only),
tile, and x86 use essentially identical alternative implementations,
placing the flag in ti->status.

Replace those optimized implementations with an equally good common
implementation that stores it in a bitfield in struct task_struct
and drop the custom implementations.

Additional architectures can opt in by removing their
TIF_RESTORE_SIGMASK defines.

Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: Michal Simek 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: "David S. Miller" 
Cc: Chris Metcalf 
Cc: x...@kernel.org
Cc: Peter Zijlstra 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Dmitry Safonov 
Cc: Andrew Morton 
Cc: linux-al...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-i...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Signed-off-by: Andy Lutomirski 
---

Hi Andrew-

This is a part of my virtually mapped stack series, but I think it
makes sense on its own and it's cross-arch.  Could you take it for
4.8?  If so, the final virtually mapped stack work can base off
4.8-rc1 without needing to worry about this patch.

Changes since virtually mapped stacks v5: none (offset only)

arch/alpha/include/asm/thread_info.h  | 27 -
 arch/ia64/include/asm/thread_info.h   | 28 --
 arch/microblaze/include/asm/thread_info.h | 27 -
 arch/powerpc/include/asm/thread_info.h| 25 
 arch/sh/include/asm/thread_info.h | 26 -
 arch/sparc/include/asm/thread_info_64.h   | 24 
 arch/tile/include/asm/thread_info.h   | 27 -
 arch/x86/include/asm/thread_info.h| 24 
 include/linux/sched.h | 63 +++
 include/linux/thread_info.h   | 41 
 10 files changed, 63 insertions(+), 249 deletions(-)

diff --git a/arch/alpha/include/asm/thread_info.h 
b/arch/alpha/include/asm/thread_info.h
index 32e920a83ae5..e9e90bfa2b50 100644
--- a/arch/alpha/include/asm/thread_info.h
+++ b/arch/alpha/include/asm/thread_info.h
@@ -86,33 +86,6 @@ register struct thread_info *__current_thread_info 
__asm__("$8");
 #define TS_UAC_NOPRINT 0x0001  /* ! Preserve the following three */
 #define TS_UAC_NOFIX   0x0002  /* ! flags as they match  */
 #define TS_UAC_SIGBUS  0x0004  /* ! userspace part of 'osf_sysinfo' */
-#define TS_RESTORE_SIGMASK 0x0008  /* restore signal mask in do_signal() */
-
-#ifndef __ASSEMBLY__
-#define HAVE_SET_RESTORE_SIGMASK   1
-static inline void set_restore_sigmask(void)
-{
-   struct thread_info *ti = current_thread_info();
-   ti->status |= TS_RESTORE_SIGMASK;
-   WARN_ON(!test_bit(TIF_SIGPENDING, (unsigned long *)>flags));
-}
-static inline void clear_restore_sigmask(void)
-{
-   current_thread_info()->status &= ~TS_RESTORE_SIGMASK;
-}
-static inline bool test_restore_sigmask(void)
-{
-   return current_thread_info()->status & TS_RESTORE_SIGMASK;
-}
-static inline bool test_and_clear_restore_sigmask(void)
-{
-   struct thread_info *ti = current_thread_info();
-   if (!(ti->status & TS_RESTORE_SIGMASK))
-   return false;
-   ti->status &= ~TS_RESTORE_SIGMASK;
-   return true;
-}
-#endif
 
 #define SET_UNALIGN_CTL(task,value)({  \
__u32 status = task_thread_info(task)->status & ~UAC_BITMASK;   \
diff --git a/arch/ia64/include/asm/thread_info.h 
b/arch/ia64/include/asm/thread_info.h
index d1212b84fb83..29bd59790d6c 100644
--- a/arch/ia64/include/asm/thread_info.h
+++ b/arch/ia64/include/asm/thread_info.h
@@ -121,32 +121,4 @@ struct thread_info {
 /* like TIF_ALLWORK_BITS but sans TIF_SYSCALL_TRACE or TIF_SYSCALL_AUDIT */
 #define TIF_WORK_MASK  
(TIF_ALLWORK_MASK&~(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT))
 
-#define TS_RESTORE_SIGMASK 2   /* restore signal mask in do_signal() */
-
-#ifndef __ASSEMBLY__
-#define HAVE_SET_RESTORE_SIGMASK   1
-static inline void set_restore_sigmask(void)
-{
-   struct thread_info *ti = current_thread_info();
-   ti->status |= TS_RESTORE_SIGMASK;
-   WARN_ON(!test_bit(TIF_SIGPENDING, >flags));
-}
-static inline void clear_restore_sigmask(void)
-{
-   current_thread_info()->status &= 

Re: [PATCH v2 01/11] mm: Implement stack frame object validation

[Kees Cook]

On Wed, Jul 13, 2016 at 10:48 PM, Josh Poimboeuf  wrote:
> On Wed, Jul 13, 2016 at 03:04:26PM -0700, Kees Cook wrote:
>> On Wed, Jul 13, 2016 at 3:01 PM, Andy Lutomirski  wrote:
>> > On Wed, Jul 13, 2016 at 2:55 PM, Kees Cook  wrote:
>> >> This creates per-architecture function arch_within_stack_frames() that
>> >> should validate if a given object is contained by a kernel stack frame.
>> >> Initial implementation is on x86.
>> >>
>> >> This is based on code from PaX.
>> >>
>> >
>> > This, along with Josh's livepatch work, are two examples of unwinders
>> > that matter for correctness instead of just debugging.  ISTM this
>> > should just use Josh's code directly once it's been written.
>>
>> Do you have URL for Josh's code? I'd love to see what happening there.
>
> The code is actually going to be 100% different next time around, but
> FWIW, here's the last attempt:
>
>   
> https://lkml.kernel.org/r/4d34d452bf8f85c7d6d5f93db1d3eeb4cba335c7.1461875890.git.jpoim...@redhat.com
>
> In the meantime I've realized the need to rewrite the x86 core stack
> walking code to something much more manageable so we don't need all
> these unwinders everywhere.  I'll probably post the patches in the next
> week or so.  I'll add you to the CC list.

Awesome!

> With the new interface I think you'll be able to do something like:
>
> struct unwind_state;
>
> unwind_start(, current, NULL, NULL);
> unwind_next_frame();
> oldframe = unwind_get_stack_pointer();
>
> unwind_next_frame();
> frame = unwind_get_stack_pointer();
>
> do {
> if (obj + len <= frame)
> return blah;
> oldframe = frame;
> frame = unwind_get_stack_pointer();
>
> } while (unwind_next_frame();
>
> And then at the end there'll be some (still TBD) way to query whether it
> reached the last syscall pt_regs frame, or if it instead encountered a
> bogus frame pointer along the way and had to bail early.

Sounds good to me. Will there be any frame size information available?
Right now, the unwinder from PaX just drops 2 pointers (saved frame,
saved ip) from the delta of frame address to find the size of the
actual stack area used by the function. If I could shave things like
padding and possible stack canaries off the size too, that would be
great.

Since I'm aiming the hardened usercopy series for 4.8, I figure I'll
just leave this unwinder in for now, and once yours lands, I can rip
it out again.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powernv: Use __printf in pe_level_printk

[Joe Perches]

Make the compiler detect format and argument mismatches.

Signed-off-by: Joe Perches 
---
 arch/powerpc/platforms/powernv/pci.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/platforms/powernv/pci.h 
b/arch/powerpc/platforms/powernv/pci.h
index 3a97990..1c1a586 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -213,6 +213,7 @@ extern void pnv_pci_dma_bus_setup(struct pci_bus *bus);
 extern int pnv_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type);
 extern void pnv_teardown_msi_irqs(struct pci_dev *pdev);
 
+__printf(3, 4)
 extern void pe_level_printk(const struct pnv_ioda_pe *pe, const char *level,
const char *fmt, ...);
 #define pe_err(pe, fmt, ...)   \
-- 
2.8.0.rc4.16.g56331f8

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC 0/3] extend kexec_file_load system call

[Mark Rutland]

On Wed, Jul 13, 2016 at 09:57:28PM +0200, Arnd Bergmann wrote:
> On Wednesday, July 13, 2016 6:58:32 PM CEST Mark Rutland wrote:
> > 
> > >   we may want to remove unnecessary devices and even add a dedicated
> > >   storage device for storing a core dump image.
> > 
> > I suspect that bringing up a minimal number of devices is better
> > controlled by a cmdline option. In general, figuring out what is
> > necessary and what is not is going to be board specific, so hacking the
> > FW tables (DTB or ACPI) is not a very portable/reliable approach.
> > 
> > Do we actually add devices in practice? More so than the above that
> > requires special knowledge of the platform (including things that were
> > not described in the boot DTB).
> > 
> > In the ACPI case modifying a DTB alone is not sufficient to change the
> > information regarding devices, as those won't be described in the DTB.
> > It's not possible to convert ACPI to DTB in general.
> 
> A more likely scenario would be replacing ACPI tables with a DTB that
> describes the platform in order to use devices that the ACPI tables
> don't contain.

To do so, you need special knowledge of the platform, which users are
unlikely to have in practice for ACPI-based platforms.

So, I think that boils down to the same problem, and the same comments
apply.

> > > - Say, booting BE kernel on ACPI LE kernel
> > >   In this case, there is no useful dtb in the kernel.
> 
> > If the platform only has ACPI, then you cannot boot a BE kernel to begin
> > with. As above one cannot convert ACPI to DTB, so one would need
> > extensive platform knowledge for this to work.
> 
> I think what he meant was to pass a DTB to the kexec kernel in order
> to run BE, while the original kernel can only run LE due to ACPI.

I understood that. My point was that to build that DTB, you need to have
knowledge of the platform that you are unlikely to have.

The platform firmware may expect to interact with AML, which you can't
place in DT or run in a BE context.

If you need to run BE kernels on a platform, you would likely get a
platform that could boot a BE kernel from the outset (i.e. one that
provides a DTB), or run that code ina VM under an LE host.

Thanks,
Mark.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH kernel] powerpc/mm/iommu: Put pages on process exit

[Alexey Kardashevskiy]

On 14/07/16 20:12, Balbir Singh wrote:
> On Thu, Jul 14, 2016 at 3:16 PM, Alexey Kardashevskiy  wrote:
>> At the moment VFIO IOMMU SPAPR v2 driver pins all guest RAM pages when
>> the userspace starts using VFIO. When the userspace process finishes,
>> all the pinned pages need to be put; this is done as a part of
>> the userspace memory context (MM) destruction which happens on
>> the very last mmdrop().
>>
>> This approach has a problem that a MM of the userspace process
>> may live longer than the userspace process itself as kernel threads
>> usually execute on a MM of a userspace process which was runnning
>> on a CPU where the kernel thread was scheduled to. If this happened,
>> the MM remains referenced until this exact kernel thread wakes up again
>> and releases the very last reference to the MM, on an idle system this
>> can take even hours.
>>
>> This fixes the issue by moving mm_iommu_cleanup() (the helper which puts
>> pages) from destroy_context() (called on the last mmdrop()) to
>> the arch-specific arch_exit_mmap() hook (called on the last mmput()).
>> mmdrop() decrements the mm->mm_count which is a total reference number;
>> mmput() decrements the mm->mm_users which is a number of user spaces and
>> this is actually the counter we want to watch for here.
>>
>> Cc: David Gibson 
>> Cc: Benjamin Herrenschmidt 
>> Cc: Paul Mackerras 
>> Cc: Balbir Singh 
>> Cc: Nick Piggin 
>> Signed-off-by: Alexey Kardashevskiy 
>> ---
>>  arch/powerpc/include/asm/mmu_context.h | 3 +++
>>  arch/powerpc/mm/mmu_context_book3s64.c | 4 
>>  2 files changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/mmu_context.h 
>> b/arch/powerpc/include/asm/mmu_context.h
>> index 9d2cd0c..24b590d 100644
>> --- a/arch/powerpc/include/asm/mmu_context.h
>> +++ b/arch/powerpc/include/asm/mmu_context.h
>> @@ -138,6 +138,9 @@ static inline void arch_dup_mmap(struct mm_struct *oldmm,
>>
>>  static inline void arch_exit_mmap(struct mm_struct *mm)
>>  {
>> +#ifdef CONFIG_SPAPR_TCE_IOMMU
>> +   mm_iommu_cleanup(>context);
>> +#endif
>>  }
>>
> 
> The assumption is that all necessary tear down has happened. Earlier
> we were doing the teardown
> on the last mm ref drop, do we have any dependence on that? I don't
> think so, but just checking
> 
> Does qemu dotce_iommu_register_pages on exit()/atexit() or do we rely
> on the exit path to do the teardown?

QEMU does call unregister when a memory region is deleted. Handling it in
arch_exit_mmap() is for the case when a QEMU process just dies for whatever
reason.

> Can we please remove the #ifdef CONFIG_SPAPR_TCE_IOMMU here and have a version
> of mm_iommu_cleanup that handles it


That would be a change unrelated to the fix. And I just do not see the
point in this - mm_iommu_cleanup() is declared in the very same header.


> Basically do
> 
> #ifdef CONFIG_SPAPR_TCE_IOMMU
> extern void mm_iommu_cleanup(void *ptr)
> #else
> static inline mm_iommu_cleanup(void *ptr) {}
> #endif
> 
> Otherwise looks good
> 
> Acked-by: Balbir Singh 

Thanks!


-- 
Alexey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [patch] ide: missing break statement in set_timings_mdma()

[Benjamin Herrenschmidt]

On Thu, 2016-07-14 at 13:48 +0300, Dan Carpenter wrote:
> There was clearly supposed to be a break statement here.  Currently we
> use the k2 ata timings instead of sh ata ones we intended.  Probably no
> one has this hardware anymore so it likely doesn't make a difference
> beyond the static checker warning.
> 
> Signed-off-by: Dan Carpenter 

Acked-by: Benjamin Herrenschmidt 

Should probably also:

CC: sta...@vger.kernel.org

> diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c
> index 7f0434f..0c5d3a9 100644
> --- a/drivers/ide/pmac.c
> +++ b/drivers/ide/pmac.c
> @@ -707,6 +707,7 @@ set_timings_mdma(ide_drive_t *drive, int intf_type, u32 
> *timings, u32 *timings2,
>   *timings = ((*timings) & ~TR_133_PIOREG_MDMA_MASK) | tr;
>   *timings2 = (*timings2) & ~TR_133_UDMAREG_UDMA_EN;
>   }
> + break;
>   case controller_un_ata6:
>   case controller_k2_ata6: {
>   /* 100Mhz cell */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Kernel 4.1.28: Update TM user feature bits in scan_features()

[Christian Zigotzky]

Hi Michael,

When I received your email with your solution, I had already compiled 
the kernel 4.1.28 with the following temporary solution:


Not suitable for 4.1-stable (no PPC_FEATURE2_HTM_NOSC_COMP).

- * If the kernel doesn't support TM (ie 
CONFIG_PPC_TRANSACTIONAL_MEM=n),

- * we don't want to turn on TM here, so we use the *_COMP versions
- * which are 0 if the kernel doesn't support TM.
+ * If the kernel doesn't support TM (ie. 
CONFIG_PPC_TRANSACTIONAL_MEM=n),

+ * we don't want to turn on CPU_FTR_TM here, so we use CPU_FTR_TM_COMP
+ * which is 0 if the kernel doesn't support TM.
  */
-{CPU_FTR_TM_COMP, 0, 0,
- PPC_FEATURE2_HTM_COMP|PPC_FEATURE2_HTM_NOSC_COMP, 22, 0, 0},
+{CPU_FTR_TM_COMP, 0, 0, 0,22, 0, 0},
 };

The kernel boots and KVM PR works. I tested it with Mac-on-Linux/KVM PR 
and Mac OS X Tiger as guest system. I will try your solution too.


Many thanks for your fast response!

Cheers,

Christian


On 14 July 2016 at 1:10 PM, Michael Ellerman wrote:

Christian Zigotzky  writes:


Hi All,

I tried to compile the kernel 4.1.28 today. Unfortunately it doesn't
compile because of an undeclared variable PPC_FEATURE2_HTM_NOSC_COMP.

Error message:

CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK include/generated/bounds.h
CHK include/generated/asm-offsets.h
CALLscripts/checksyscalls.sh
CHK include/generated/compile.h
CALLarch/powerpc/kernel/systbl_chk.sh
CC  arch/powerpc/kernel/prom.o
arch/powerpc/kernel/prom.c:170:25: error: 'PPC_FEATURE2_HTM_NOSC_COMP'
undeclared here (not in a function)
 PPC_FEATURE2_HTM_COMP|PPC_FEATURE2_HTM_NOSC_COMP, 22, 0, 0},
   ^
make[1]: *** [arch/powerpc/kernel/prom.o] Error 1
make: *** [arch/powerpc/kernel] Error 2

---

Commit:

f49eb503f0f9ab66874a81992b14249a1c59b6ad
Author: Anton Blanchard
Date:   Fri Apr 15 12:08:19 2016 +1000

  powerpc: Update TM user feature bits in scan_features()

  [ Upstream commit 4705e02498d6d5a7ab98dfee9595cd5e91db2017 ]

  We need to update the user TM feature bits (PPC_FEATURE2_HTM and
  PPC_FEATURE2_HTM) to mirror what we do with the kernel TM feature
  bit.

  At the moment, if firmware reports TM is not available we turn off
  the kernel TM feature bit but leave the userspace ones on. Userspace
  thinks it can execute TM instructions and it dies trying.

  This (together with a QEMU patch) fixes PR KVM, which doesn't currently
  support TM.

  Signed-off-by: Anton Blanchard
  Cc:sta...@vger.kernel.org
  Signed-off-by: Michael Ellerman
  Signed-off-by: Sasha Levin

---

PPC_FEATURE2_HTM_NOSC_COMP isn't defined or doesn't exist in the
following files:

Thanks.


arch/powerpc/include/asm/cputable.h
arch/powerpc/kernel/cputable.c
arch/powerpc/include/uapi/asm/tm.h

That means the following patches aren't included in the 4.1.28 source code:

Sorry that's the wrong fix.

PPC_FEATURE2_HTM_NOSC indicates the presence of a certain kernel
behaviour, which has *not* been backported to 4.1.

The right fix is just to remove the reference to PPC_FEATURE2_HTM_NOSC
in 4.1.28.

eg:

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 28dbbb0d12c4..9b19d96e9562 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -166,8 +166,7 @@ static struct ibm_pa_feature {
 * we don't want to turn on TM here, so we use the *_COMP versions
 * which are 0 if the kernel doesn't support TM.
 */
-   {CPU_FTR_TM_COMP, 0, 0,
-PPC_FEATURE2_HTM_COMP|PPC_FEATURE2_HTM_NOSC_COMP, 22, 0, 0},
+   {CPU_FTR_TM_COMP, 0, 0, PPC_FEATURE2_HTM_COMP, 22, 0, 0},
  };
  
  static void __init scan_features(unsigned long node, const unsigned char *ftrs,




cheers



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [patch -next] wan/fsl_ucc_hdlc: info leak in uhdlc_ioctl()

[Dan Carpenter]

Good point.  Thanks.

regards,
dan carpenter

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[patch v2 -next] wan/fsl_ucc_hdlc: info leak in uhdlc_ioctl()

[Dan Carpenter]

There is a 2 byte struct whole after line.loopback so we need to clear
that out to avoid disclosing stack information.

Fixes: c19b6d246a35 ('drivers/net: support hdlc function for QE-UCC')
Signed-off-by: Dan Carpenter 
---
v2: remove the other initialization to zero

diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 19174ac..6edd48a 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -635,9 +635,8 @@ static int uhdlc_ioctl(struct net_device *dev, struct ifreq 
*ifr, int cmd)
ifr->ifr_settings.size = size; /* data size wanted */
return -ENOBUFS;
}
+   memset(, 0, sizeof(line));
line.clock_type = priv->clocking;
-   line.clock_rate = 0;
-   line.loopback = 0;
 
if (copy_to_user(ifr->ifr_settings.ifs_ifsu.sync, , size))
return -EFAULT;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[4.1.28 PATCH] powerpc: Fix build break due to missing PPC_FEATURE2_HTM_NOSC

[Michael Ellerman]

The backport of 4705e02498d6 ("powerpc: Update TM user feature bits in
scan_features()") (f49eb503f0f9), missed the fact that 4.1 doesn't
include the commit that added PPC_FEATURE2_HTM_NOSC.

The correct fix is simply to omit PPC_FEATURE2_HTM_NOSC.

Fixes: f49eb503f0f9 ("powerpc: Update TM user feature bits in scan_features()")
Reported-by: Christian Zigotzky 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/prom.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 28dbbb0d12c4..9b19d96e9562 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -166,8 +166,7 @@ static struct ibm_pa_feature {
 * we don't want to turn on TM here, so we use the *_COMP versions
 * which are 0 if the kernel doesn't support TM.
 */
-   {CPU_FTR_TM_COMP, 0, 0,
-PPC_FEATURE2_HTM_COMP|PPC_FEATURE2_HTM_NOSC_COMP, 22, 0, 0},
+   {CPU_FTR_TM_COMP, 0, 0, PPC_FEATURE2_HTM_COMP, 22, 0, 0},
 };
 
 static void __init scan_features(unsigned long node, const unsigned char *ftrs,
-- 
2.7.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Kernel 4.1.28: Update TM user feature bits in scan_features()

[Michael Ellerman]

Christian Zigotzky  writes:

> Hi All,
>
> I tried to compile the kernel 4.1.28 today. Unfortunately it doesn't 
> compile because of an undeclared variable PPC_FEATURE2_HTM_NOSC_COMP.
>
> Error message:
>
>CHK include/config/kernel.release
>CHK include/generated/uapi/linux/version.h
>CHK include/generated/utsrelease.h
>CHK include/generated/bounds.h
>CHK include/generated/asm-offsets.h
>CALLscripts/checksyscalls.sh
>CHK include/generated/compile.h
>CALLarch/powerpc/kernel/systbl_chk.sh
>CC  arch/powerpc/kernel/prom.o
> arch/powerpc/kernel/prom.c:170:25: error: 'PPC_FEATURE2_HTM_NOSC_COMP' 
> undeclared here (not in a function)
> PPC_FEATURE2_HTM_COMP|PPC_FEATURE2_HTM_NOSC_COMP, 22, 0, 0},
>   ^
> make[1]: *** [arch/powerpc/kernel/prom.o] Error 1
> make: *** [arch/powerpc/kernel] Error 2
>
> ---
>
> Commit:
>
> f49eb503f0f9ab66874a81992b14249a1c59b6ad
> Author: Anton Blanchard 
> Date:   Fri Apr 15 12:08:19 2016 +1000
>
>  powerpc: Update TM user feature bits in scan_features()
>
>  [ Upstream commit 4705e02498d6d5a7ab98dfee9595cd5e91db2017 ]
>
>  We need to update the user TM feature bits (PPC_FEATURE2_HTM and
>  PPC_FEATURE2_HTM) to mirror what we do with the kernel TM feature
>  bit.
>
>  At the moment, if firmware reports TM is not available we turn off
>  the kernel TM feature bit but leave the userspace ones on. Userspace
>  thinks it can execute TM instructions and it dies trying.
>
>  This (together with a QEMU patch) fixes PR KVM, which doesn't currently
>  support TM.
>
>  Signed-off-by: Anton Blanchard 
>  Cc: sta...@vger.kernel.org
>  Signed-off-by: Michael Ellerman 
>  Signed-off-by: Sasha Levin 
>
> ---
>
> PPC_FEATURE2_HTM_NOSC_COMP isn't defined or doesn't exist in the 
> following files:

Thanks.

> arch/powerpc/include/asm/cputable.h
> arch/powerpc/kernel/cputable.c
> arch/powerpc/include/uapi/asm/tm.h
>
> That means the following patches aren't included in the 4.1.28 source code:

Sorry that's the wrong fix.

PPC_FEATURE2_HTM_NOSC indicates the presence of a certain kernel
behaviour, which has *not* been backported to 4.1.

The right fix is just to remove the reference to PPC_FEATURE2_HTM_NOSC
in 4.1.28.

eg:

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 28dbbb0d12c4..9b19d96e9562 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -166,8 +166,7 @@ static struct ibm_pa_feature {
 * we don't want to turn on TM here, so we use the *_COMP versions
 * which are 0 if the kernel doesn't support TM.
 */
-   {CPU_FTR_TM_COMP, 0, 0,
-PPC_FEATURE2_HTM_COMP|PPC_FEATURE2_HTM_NOSC_COMP, 22, 0, 0},
+   {CPU_FTR_TM_COMP, 0, 0, PPC_FEATURE2_HTM_COMP, 22, 0, 0},
 };
 
 static void __init scan_features(unsigned long node, const unsigned char *ftrs,



cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [patch] KVM: PPC: fix a sanity check

[Alexander Graf]

On 07/14/2016 12:15 PM, Dan Carpenter wrote:

We use logical negate where bitwise negate was intended.  It means that
we never return -EINVAL here.

Fixes: ce11e48b7fdd ('KVM: PPC: E500: Add userspace debug stub support')
Signed-off-by: Dan Carpenter 


Oops :).

Reviewed-by: Alexander Graf 


Alex

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [patch -next] wan/fsl_ucc_hdlc: info leak in uhdlc_ioctl()

[walter harms]

Am 14.07.2016 12:34, schrieb Dan Carpenter:
> There is a 2 byte struct whole after line.loopback so we need to clear
> that out to avoid disclosing stack information.
> 
> Fixes: c19b6d246a35 ('drivers/net: support hdlc function for QE-UCC')
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
> index 19174ac..7608561 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.c
> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> @@ -635,6 +635,7 @@ static int uhdlc_ioctl(struct net_device *dev, struct 
> ifreq *ifr, int cmd)
>   ifr->ifr_settings.size = size; /* data size wanted */
>   return -ENOBUFS;
>   }
> + memset(, 0, sizeof(line));
>   line.clock_type = priv->clocking;
>   line.clock_rate = 0;
>   line.loopback = 0;


In this case
line.clock_rate = 0;
line.loopback = 0;

are not need any more and can be removed
except like them to have for documentation or so.

re,
 wh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[patch] ide: missing break statement in set_timings_mdma()

[Dan Carpenter]

There was clearly supposed to be a break statement here.  Currently we
use the k2 ata timings instead of sh ata ones we intended.  Probably no
one has this hardware anymore so it likely doesn't make a difference
beyond the static checker warning.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c
index 7f0434f..0c5d3a9 100644
--- a/drivers/ide/pmac.c
+++ b/drivers/ide/pmac.c
@@ -707,6 +707,7 @@ set_timings_mdma(ide_drive_t *drive, int intf_type, u32 
*timings, u32 *timings2,
*timings = ((*timings) & ~TR_133_PIOREG_MDMA_MASK) | tr;
*timings2 = (*timings2) & ~TR_133_UDMAREG_UDMA_EN;
}
+   break;
case controller_un_ata6:
case controller_k2_ata6: {
/* 100Mhz cell */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[patch -next] wan/fsl_ucc_hdlc: info leak in uhdlc_ioctl()

[Dan Carpenter]

There is a 2 byte struct whole after line.loopback so we need to clear
that out to avoid disclosing stack information.

Fixes: c19b6d246a35 ('drivers/net: support hdlc function for QE-UCC')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 19174ac..7608561 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -635,6 +635,7 @@ static int uhdlc_ioctl(struct net_device *dev, struct ifreq 
*ifr, int cmd)
ifr->ifr_settings.size = size; /* data size wanted */
return -ENOBUFS;
}
+   memset(, 0, sizeof(line));
line.clock_type = priv->clocking;
line.clock_rate = 0;
line.loopback = 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Kernel 4.1.28: Update TM user feature bits in scan_features()

[Christian Zigotzky]

Hi All,

I tried to compile the kernel 4.1.28 today. Unfortunately it doesn't 
compile because of an undeclared variable PPC_FEATURE2_HTM_NOSC_COMP.


Error message:

  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  CHK include/generated/compile.h
  CALLarch/powerpc/kernel/systbl_chk.sh
  CC  arch/powerpc/kernel/prom.o
arch/powerpc/kernel/prom.c:170:25: error: 'PPC_FEATURE2_HTM_NOSC_COMP' 
undeclared here (not in a function)

   PPC_FEATURE2_HTM_COMP|PPC_FEATURE2_HTM_NOSC_COMP, 22, 0, 0},
 ^
make[1]: *** [arch/powerpc/kernel/prom.o] Error 1
make: *** [arch/powerpc/kernel] Error 2

---

Commit:

f49eb503f0f9ab66874a81992b14249a1c59b6ad
Author: Anton Blanchard 
Date:   Fri Apr 15 12:08:19 2016 +1000

powerpc: Update TM user feature bits in scan_features()

[ Upstream commit 4705e02498d6d5a7ab98dfee9595cd5e91db2017 ]

We need to update the user TM feature bits (PPC_FEATURE2_HTM and
PPC_FEATURE2_HTM) to mirror what we do with the kernel TM feature
bit.

At the moment, if firmware reports TM is not available we turn off
the kernel TM feature bit but leave the userspace ones on. Userspace
thinks it can execute TM instructions and it dies trying.

This (together with a QEMU patch) fixes PR KVM, which doesn't currently
support TM.

Signed-off-by: Anton Blanchard 
Cc: sta...@vger.kernel.org
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 

---

PPC_FEATURE2_HTM_NOSC_COMP isn't defined or doesn't exist in the 
following files:


arch/powerpc/include/asm/cputable.h
arch/powerpc/kernel/cputable.c
arch/powerpc/include/uapi/asm/tm.h

That means the following patches aren't included in the 4.1.28 source code:

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h

index 22d5a7d..4ec19da 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -236,11 +236,13 @@ extern const char *powerpc_base_platform;

 /* We only set the TM feature if the kernel was compiled with TM supprt */
 #ifdef CONFIG_PPC_TRANSACTIONAL_MEM
-#define CPU_FTR_TM_COMPCPU_FTR_TM
-#define PPC_FEATURE2_HTM_COMPPPC_FEATURE2_HTM
+#define CPU_FTR_TM_COMPCPU_FTR_TM
+#define PPC_FEATURE2_HTM_COMPPPC_FEATURE2_HTM
+#define PPC_FEATURE2_HTM_NOSC_COMPPPC_FEATURE2_HTM_NOSC
 #else
-#define CPU_FTR_TM_COMP0
-#define PPC_FEATURE2_HTM_COMP0
+#define CPU_FTR_TM_COMP0
+#define PPC_FEATURE2_HTM_COMP0
+#define PPC_FEATURE2_HTM_NOSC_COMP0
 #endif

 /* We need to mark all pages as being coherent if we're SMP or we have a
diff --git a/arch/powerpc/include/uapi/asm/cputable.h 
b/arch/powerpc/include/uapi/asm/cputable.h

index 67de80a..2734c00 100644
--- a/arch/powerpc/include/uapi/asm/cputable.h
+++ b/arch/powerpc/include/uapi/asm/cputable.h
@@ -43,5 +43,6 @@
 #define PPC_FEATURE2_ISEL0x0800
 #define PPC_FEATURE2_TAR0x0400
 #define PPC_FEATURE2_VEC_CRYPTO0x0200
+#define PPC_FEATURE2_HTM_NOSC0x0100

 #endif /* _UAPI__ASM_POWERPC_CPUTABLE_H */
diff --git a/arch/powerpc/include/uapi/asm/tm.h 
b/arch/powerpc/include/uapi/asm/tm.h

index 5d836b7..5047659 100644
--- a/arch/powerpc/include/uapi/asm/tm.h
+++ b/arch/powerpc/include/uapi/asm/tm.h
@@ -11,7 +11,7 @@
 #define TM_CAUSE_RESCHED0xde
 #define TM_CAUSE_TLBI0xdc
 #define TM_CAUSE_FAC_UNAV0xda
-#define TM_CAUSE_SYSCALL0xd8  /* future use */
+#define TM_CAUSE_SYSCALL0xd8
 #define TM_CAUSE_MISC0xd6  /* future use */
 #define TM_CAUSE_SIGNAL0xd4
 #define TM_CAUSE_ALIGNMENT0xd2
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index c18a2ea..bf3eb39 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -108,7 +108,9 @@ extern void __restore_cpu_e6500(void);
  PPC_FEATURE_TRUE_LE | \
  PPC_FEATURE_PSERIES_PERFMON_COMPAT)
 #define COMMON_USER2_POWER8(PPC_FEATURE2_ARCH_2_07 | \
- PPC_FEATURE2_HTM_COMP | PPC_FEATURE2_DSCR | \
+ PPC_FEATURE2_HTM_COMP | \
+ PPC_FEATURE2_HTM_NOSC_COMP | \
+ PPC_FEATURE2_DSCR | \
  PPC_FEATURE2_ISEL | PPC_FEATURE2_TAR | \
  PPC_FEATURE2_VEC_CRYPTO)
 #define COMMON_USER_PA6T(COMMON_USER_PPC64 | PPC_FEATURE_PA6T |\

--

Temporary solution:

Not suitable for 4.1-stable (no PPC_FEATURE2_HTM_NOSC_COMP).

- * If the kernel doesn't support TM (ie 
CONFIG_PPC_TRANSACTIONAL_MEM=n),

- * we don't want to turn on TM here, so we use the *_COMP versions
- * which are 0 if the kernel doesn't support TM.
+ * If 

[patch] KVM: PPC: fix a sanity check

[Dan Carpenter]

We use logical negate where bitwise negate was intended.  It means that
we never return -EINVAL here.

Fixes: ce11e48b7fdd ('KVM: PPC: E500: Add userspace debug stub support')
Signed-off-by: Dan Carpenter 

diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 02b4672..df3f270 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -2038,7 +2038,7 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu 
*vcpu,
if (type == KVMPPC_DEBUG_NONE)
continue;
 
-   if (type & !(KVMPPC_DEBUG_WATCH_READ |
+   if (type & ~(KVMPPC_DEBUG_WATCH_READ |
 KVMPPC_DEBUG_WATCH_WRITE |
 KVMPPC_DEBUG_BREAKPOINT))
return -EINVAL;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/configs: Enable VMX crypto

[Michael Ellerman]

Anton Blanchard  writes:

> From: Anton Blanchard 
>
> We see big improvements with the VMX crypto functions (often 10x or more),
> so enable it as a module.

I can't build pseries_defconfig with this applied:

  /tmp/ccsjEdNB.s: Assembler messages:
  /tmp/ccsjEdNB.s: Error: .size expression for aes_p8_set_encrypt_key does not 
evaluate to a constant
  /tmp/ccsjEdNB.s: Error: .size expression for aes_p8_set_decrypt_key does not 
evaluate to a constant
  /tmp/ccsjEdNB.s: Error: .size expression for aes_p8_encrypt does not evaluate 
to a constant
  /tmp/ccsjEdNB.s: Error: .size expression for aes_p8_decrypt does not evaluate 
to a constant
  /tmp/ccsjEdNB.s: Error: .size expression for aes_p8_cbc_encrypt does not 
evaluate to a constant
  /tmp/ccsjEdNB.s: Error: .size expression for aes_p8_ctr32_encrypt_blocks does 
not evaluate to a constant

That's with GCC 6.1.0 / binutils 2.26.

Haven't debugged it any further.

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH kernel] powerpc/mm/iommu: Put pages on process exit

[Balbir Singh]

On Thu, Jul 14, 2016 at 3:16 PM, Alexey Kardashevskiy  wrote:
> At the moment VFIO IOMMU SPAPR v2 driver pins all guest RAM pages when
> the userspace starts using VFIO. When the userspace process finishes,
> all the pinned pages need to be put; this is done as a part of
> the userspace memory context (MM) destruction which happens on
> the very last mmdrop().
>
> This approach has a problem that a MM of the userspace process
> may live longer than the userspace process itself as kernel threads
> usually execute on a MM of a userspace process which was runnning
> on a CPU where the kernel thread was scheduled to. If this happened,
> the MM remains referenced until this exact kernel thread wakes up again
> and releases the very last reference to the MM, on an idle system this
> can take even hours.
>
> This fixes the issue by moving mm_iommu_cleanup() (the helper which puts
> pages) from destroy_context() (called on the last mmdrop()) to
> the arch-specific arch_exit_mmap() hook (called on the last mmput()).
> mmdrop() decrements the mm->mm_count which is a total reference number;
> mmput() decrements the mm->mm_users which is a number of user spaces and
> this is actually the counter we want to watch for here.
>
> Cc: David Gibson 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Balbir Singh 
> Cc: Nick Piggin 
> Signed-off-by: Alexey Kardashevskiy 
> ---
>  arch/powerpc/include/asm/mmu_context.h | 3 +++
>  arch/powerpc/mm/mmu_context_book3s64.c | 4 
>  2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mmu_context.h 
> b/arch/powerpc/include/asm/mmu_context.h
> index 9d2cd0c..24b590d 100644
> --- a/arch/powerpc/include/asm/mmu_context.h
> +++ b/arch/powerpc/include/asm/mmu_context.h
> @@ -138,6 +138,9 @@ static inline void arch_dup_mmap(struct mm_struct *oldmm,
>
>  static inline void arch_exit_mmap(struct mm_struct *mm)
>  {
> +#ifdef CONFIG_SPAPR_TCE_IOMMU
> +   mm_iommu_cleanup(>context);
> +#endif
>  }
>

The assumption is that all necessary tear down has happened. Earlier
we were doing the teardown
on the last mm ref drop, do we have any dependence on that? I don't
think so, but just checking

Does qemu dotce_iommu_register_pages on exit()/atexit() or do we rely
on the exit path to do the teardown?

Can we please remove the #ifdef CONFIG_SPAPR_TCE_IOMMU here and have a version
of mm_iommu_cleanup that handles it

Basically do

#ifdef CONFIG_SPAPR_TCE_IOMMU
extern void mm_iommu_cleanup(void *ptr)
#else
static inline mm_iommu_cleanup(void *ptr) {}
#endif

Otherwise looks good

Acked-by: Balbir Singh 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [kernel-hardening] [PATCH v2 11/11] mm: SLUB hardened usercopy support

[Michael Ellerman]

Kees Cook  writes:

> Under CONFIG_HARDENED_USERCOPY, this adds object size checking to the
> SLUB allocator to catch any copies that may span objects. Includes a
> redzone handling fix from Michael Ellerman.

Actually I think you wrote the fix, I just pointed you in that
direction. But anyway, this works for me, so if you like:

Tested-by: Michael Ellerman 

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V2 4/5] kvm/stats: Add provisioning for 64-bit vcpu statistics

[Paolo Bonzini]

On 13/07/2016 20:00, Christian Borntraeger wrote:
>>> >> I thought u64 still existed on 32-bit architectures. unsigned long
>>> >> would be fine but with the caveat that certain stats would overflow on
>>> >> 32-bit architectures.
>> > 
>> > Yes, but not all 32-bit architectures can do atomic read-modify-write
>> > (e.g. add) operations on 64-bit values.
> So what about only doing it for the VCPU events? Those should be only
> modified by one CPU. We would have some odd values on 32bit overflow, but
> this will be certainly better than just start with 0

If that's good enough for PPC, that's fine.

Paolo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH for-4.8 12/12] powerpc/mm/radix: Add a kernel command line to disable radix

[Aneesh Kumar K.V]

Balbir Singh  writes:

> On Wed, Jul 13, 2016 at 03:05:31PM +0530, Aneesh Kumar K.V wrote:
>> This patch adds the kernel command line disable_radix which disable
>> the radix MMU mode even if firmware indicates radix support via
>> ibm,pa-features device tree node.
>> 
>> This helps in testing different MMU mode easily.
>> 
>> Signed-off-by: Aneesh Kumar K.V 
>> ---
>>  Documentation/kernel-parameters.txt |  3 +++
>>  arch/powerpc/kernel/prom.c  | 13 +
>>  2 files changed, 16 insertions(+)
>> 
>> diff --git a/Documentation/kernel-parameters.txt 
>> b/Documentation/kernel-parameters.txt
>> index 738bae4a5958..bba7ef30d74e 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -929,6 +929,9 @@ bytes respectively. Such letter suffixes can also be 
>> entirely omitted.
>>  disable=[IPV6]
>>  See Documentation/networking/ipv6.txt.
>>  
>> +disable_radix   [PPC]
>> +Disable RADIX MMU mode on POWER9
>> +
>>  disable_cpu_apicid= [X86,APIC,SMP]
>>  Format: 
>>  The number of initial APIC ID for the
>> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
>> index 946e34ffeae9..022540b9366d 100644
>> --- a/arch/powerpc/kernel/prom.c
>> +++ b/arch/powerpc/kernel/prom.c
>> @@ -645,6 +645,14 @@ static void __init early_reserve_mem(void)
>>  #endif
>>  }
>>  
>> +static bool disable_radix;
>
> __read_mostly?

We actually read it only once.

>
>> +static int __init parse_disable_radix(char *p)
>> +{
>> +disable_radix = true;
>> +return 0;
>> +}
>> +early_param("disable_radix", parse_disable_radix);
>> +
>>  void __init early_init_devtree(void *params)
>>  {
>>  phys_addr_t limit;
>> @@ -739,6 +747,11 @@ void __init early_init_devtree(void *params)
>>  /* Scan and build the list of machine check recoverable ranges */
>>  of_scan_flat_dt(early_init_dt_scan_recoverable_ranges, NULL);
>>  #endif
>> +/*
>> + * now fixup radix MMU mode based on kernel command line
>> + */
>> +if (disable_radix)
>> +cur_cpu_spec->mmu_features &= ~MMU_FTR_RADIX;
>
> Shouldn't this happen before prom_init() and exchanging capabilities?

Didn't get that. We actually set the FTR_RADIX in
check_cpu_pa_features(node) which is called via
of_scan_flat_dt(early_init_dt_scan_cpus, NULL); We clear that
immediately after if the feature is disabled via kernel command line.

-aneesh


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC 0/3] extend kexec_file_load system call

[Arnd Bergmann]

On Wednesday, July 13, 2016 11:18:04 PM CEST Thiago Jung Bauermann wrote:
> Am Mittwoch, 13 Juli 2016, 21:59:18 schrieb Arnd Bergmann:
> > On Wednesday, July 13, 2016 3:45:41 PM CEST Thiago Jung Bauermann wrote:
> > > Am Mittwoch, 13 Juli 2016, 15:13:42 schrieb Arnd Bergmann:
> > > 
> > > For secure boot, Petitboot needs to use kexec_file_load, because of the
> > > following two features which the system call enables:
> > > 
> > > 1. only allow loading of signed kernels.
> > > 2. "measure" (i.e., record the hashes of) the kernel, initrd, kernel
> > > 
> > >command line and other boot inputs for the Integrity Measurement
> > >Architecture subsystem.
> > > 
> > > Those can't be done with kexec_load.
> > 
> > Can't petitboot do both of these in user space?
> 
> To be honest I'm not sure if it *can't* be done from userspace but if you do 
> it from the kernel you can guarantee that any kernel image that is loaded 
> gets verified and measured.
> 
> Whereas if you verify and measure the kernel in userspace then if there's a 
> vulnerability in the system which allows an attacker to upload their own 
> binary, then they can use kexec_load directly and bypass the verification 
> and measurement.
> 
> So it's a more resilient design.

Right, but the question remains whether this helps while you allow the
boot loader to modify the dtb. If an attacker gets in and cannot modify
the kernel or initid but can modify the DT, a successful attack would
be a bit harder than having a modified kernel, but you may still need
to treat the system as compromised.

Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev