The original kernel still exists in the memory, clear it now.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Nicholas Piggin
Cc: Kees Cook
Reviewed-by: Christophe Leroy
Reviewed-by: Diana Craciun
Test
When kaslr is enabled, the kernel offset is different for every boot.
This brings some difficult to debug the kernel. Dump out the kernel
offset when panic so that we can easily debug the kernel.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin
One may want to disable kaslr when boot, so provide a cmdline parameter
'nokaslr' to support this.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Nicholas Piggin
Cc: Kees Cook
Reviewed-by: Diana Craciun
This patch add support to boot kernel from places other than KERNELBASE.
Since CONFIG_RELOCATABLE has already supported, what we need to do is
map or copy kernel to a proper place and relocate. Freescale Book-E
parts expect lowmem to be mapped by fixed TLB entries(TLB1). The TLB1
entries are not su
Add a new helper reloc_kernel_entry() to jump back to the start of the
new kernel. After we put the new kernel in a randomized place we can use
this new helper to enter the kernel and begin to relocate again.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Now the kernel base is a fixed value - KERNELBASE. To support KASLR, we
need a variable to store the kernel base.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Nicholas Piggin
Cc: Kees Cook
Reviewed-by
After we have the basic support of relocate the kernel in some
appropriate place, we can start to randomize the offset now.
Entropy is derived from the banner and timer, which will change every
build and boot. This not so much safe so additionally the bootloader may
pass entropy via the /chosen/ka
Add a new helper create_tlb_entry() to create a tlb entry by the virtual
and physical address. This is a preparation to support boot kernel at a
randomized address.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerr
These two variables are both defined in init_32.c and init_64.c. Move
them to init-common.c.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Nicholas Piggin
Cc: Kees Cook
Reviewed-by: Christophe Leroy
R
M_IF_NEEDED is defined too many times. Move it to a common place.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Nicholas Piggin
Cc: Kees Cook
Reviewed-by: Christophe Leroy
Reviewed-by: Diana Craciun
This series implements KASLR for powerpc/fsl_booke/32, as a security
feature that deters exploit attempts relying on knowledge of the location
of kernel internals.
Since CONFIG_RELOCATABLE has already supported, what we need to do is
map or copy kernel to a proper place and relocate. Freescale Boo
Mips uses the KSEG1 kernel memory segment to map dma coherent
allocations for non-coherent devices as uncacheable, and does not have
any kind of special support for DMA_ATTR_WRITE_COMBINE in the allocation
path. Thus supporting DMA_ATTR_WRITE_COMBINE in dma_mmap_attrs will
lead to multiple mapping
All the way back to introducing dma_common_mmap we've defaulted to mark
the pages as uncached. But this is wrong for DMA coherent devices.
Later on DMA_ATTR_WRITE_COMBINE also got incorrect treatment as that
flag is only treated special on the alloc side for non-coherent devices.
Introduce a new
Hi all,
As Shawn pointed out we've had issues with the dma mmap pgprots ever
since the dma_common_mmap helper was added beyong the initial
architectures - we default to uncached mappings, but for devices that
are DMA coherent, or if the DMA_ATTR_NON_CONSISTENT is set (and
supported) this can lead
On Tue, Aug 06, 2019 at 05:45:03PM +0100, Russell King - ARM Linux admin wrote:
> We could have used a different approach, making all IO writes contain
> a "drain write buffer" instruction, and map DMA memory as "buffered",
> but as there were no Linux barriers defined to order memory accesses
> to
On Tue, Aug 06, 2019 at 09:39:06PM +0200, Shawn Anastasio wrote:
>> -#ifdef CONFIG_ARCH_HAS_DMA_MMAP_PGPROT
>> pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
>> unsigned long attrs);
>> -#else
>> -# define arch_dma_mmap_pgprot(dev, prot, attrs) pgprot_noncached(
On 8/7/19 10:22 AM, Dan Williams wrote:
On Tue, Aug 6, 2019 at 9:17 PM Aneesh Kumar K.V
wrote:
On 8/7/19 9:43 AM, Dan Williams wrote:
On Tue, Aug 6, 2019 at 9:00 PM Aneesh Kumar K.V
wrote:
ndctl utility requires the ndbus to have unique names. If not while
enumerating the bus in userspace
"Aneesh Kumar K.V" writes:
> ndctl utility requires the ndbus to have unique names. If not while
> enumerating the bus in userspace it drops bus with similar names.
> This results in us not listing devices beneath the bus.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> drivers/nvdimm/of_pmem.c | 2
On Tue, Aug 6, 2019 at 9:17 PM Aneesh Kumar K.V
wrote:
>
> On 8/7/19 9:43 AM, Dan Williams wrote:
> > On Tue, Aug 6, 2019 at 9:00 PM Aneesh Kumar K.V
> > wrote:
> >>
> >> ndctl utility requires the ndbus to have unique names. If not while
> >> enumerating the bus in userspace it drops bus with si
On 8/7/19 9:43 AM, Dan Williams wrote:
On Tue, Aug 6, 2019 at 9:00 PM Aneesh Kumar K.V
wrote:
ndctl utility requires the ndbus to have unique names. If not while
enumerating the bus in userspace it drops bus with similar names.
This results in us not listing devices beneath the bus.
It does?
On Tue, Aug 6, 2019 at 9:00 PM Aneesh Kumar K.V
wrote:
>
> ndctl utility requires the ndbus to have unique names. If not while
> enumerating the bus in userspace it drops bus with similar names.
> This results in us not listing devices beneath the bus.
It does?
>
> Signed-off-by: Aneesh Kumar K.
ndctl utility requires the ndbus to have unique names. If not while
enumerating the bus in userspace it drops bus with similar names.
This results in us not listing devices beneath the bus.
Signed-off-by: Aneesh Kumar K.V
---
drivers/nvdimm/of_pmem.c | 2 +-
1 file changed, 1 insertion(+), 1 del
Convert existing messages, where appropriate, to use the eeh_edev_*
logging macros.
The only effect should be minor adjustments to the log messages, apart
from:
- A new message in pseries_eeh_probe() "Probing device" to match the
powernv case.
- The "Probing device" message in pnv_eeh_probe() is
Now that EEH support for all devices (on PowerNV and pSeries) is
provided by the pcibios bus add device hooks, eeh_probe_devices() and
eeh_addr_cache_build() are redundant and can be removed.
Move the EEH enabled message into it's own function so that it can be
called from multiple places.
Note t
From: Oliver O'Halloran
Preparation for removing pci_dn from the powernv EEH code. The only
thing we really use pci_dn for is to get the bdfn of the device for
config space accesses, so adding that information to eeh_dev reduces
the need to carry around the pci_dn.
Signed-off-by: Oliver O'Hallor
The EEH_DEV_NO_HANDLER flag is used by the EEH system to prevent the
use of driver callbacks in drivers that have been bound part way
through the recovery process. This is necessary to prevent later stage
handlers from being called when the earlier stage handlers haven't,
which can be confusing for
The pcibios_init() function for 64 bit PowerPC currently calls
pci_bus_add_devices() before pcibios_resource_survey(), which seems
incorrect because it adds devices and attempts to bind their drivers
before allocating their resources (although no problems seem to be
apparent).
So move the call to
On PowerNV and pSeries, devices currently acquire EEH support from
several different places: Boot-time devices from eeh_probe_devices()
and eeh_addr_cache_build(), Virtual Function devices from the pcibios
bus add device hooks and hot plugged devices from pci_hp_add_devices()
(with other platforms
Now that struct eeh_dev includes the BDFN of it's PCI device, make use
of it to replace eeh_edev_info() with a set of dev_dbg()-style macros
that only need a struct edev.
With the BDFN available without the struct pci_dev, eeh_pci_name() is
now unnecessary, so remove it.
While only the "info" lev
Hi all,
Here is v4, with only a fix for a warning when CONFIG_IOV isn't defined.
Cover letter:
This patch set adds support for EEH recovery of hot plugged devices on pSeries
machines. Specifically, devices discovered by PCI rescanning using
/sys/bus/pci/rescan, which includes devices hotplugged
Also remove useless comment.
Signed-off-by: Sam Bobroff
Reviewed-by: Alexey Kardashevskiy
---
arch/powerpc/kernel/eeh.c| 2 +-
arch/powerpc/platforms/powernv/eeh-powernv.c | 14
arch/powerpc/platforms/pseries/eeh_pseries.c | 23 +++-
3 files cha
The EEH address cache is currently initialized and populated by a
single function: eeh_addr_cache_build(). While the initial population
of the cache can only be done once resources are allocated,
initialization (just setting up a spinlock) could be done much
earlier.
So move the initialization st
On 2019/8/6 15:59, Christophe Leroy wrote:
Le 05/08/2019 à 08:43, Jason Yan a écrit :
One may want to disable kaslr when boot, so provide a cmdline parameter
'nokaslr' to support this.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Her
On 2019/8/6 15:56, Christophe Leroy wrote:
Le 05/08/2019 à 08:43, Jason Yan a écrit :
After we have the basic support of relocate the kernel in some
appropriate place, we can start to randomize the offset now.
Entropy is derived from the banner and timer, which will change every
build and
Sourabh Jain writes:
> Add a sys interface to allow querying the memory reserved by fadump
> for saving the crash dump.
>
> Signed-off-by: Sourabh Jain
> ---
> Documentation/powerpc/firmware-assisted-dump.rst | 5 +
> arch/powerpc/kernel/fadump.c | 14 ++
> 2
Hello Christoph,
Thanks for your review.
Christoph Hellwig writes:
> On Tue, Aug 06, 2019 at 02:22:34AM -0300, Thiago Jung Bauermann wrote:
>> @@ -1318,7 +1319,10 @@ void iommu_init_early_pSeries(void)
>> of_reconfig_notifier_register(&iommu_reconfig_nb);
>> register_memory_notifier
From: John Hubbard
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder v
On Wed, Aug 07, 2019 at 09:08:11AM +0900, Masami Hiramatsu wrote:
> On Tue, 6 Aug 2019 18:00:12 +0800
> Leo Yan wrote:
>
> > This small patch set is to add support for function error injection;
> > this can be used to eanble more advanced debugging feature, e.g.
> > CONFIG_BPF_KPROBE_OVERRIDE.
>
On Wed, 2019-08-07 at 11:13 +1000, Michael Ellerman wrote:
> Chris Packham writes:
> >
> > On Tue, 2019-08-06 at 21:32 +1000, Michael Ellerman wrote:
> > >
> > > Chris Packham writes:
> > > >
> > > > On Mon, 2019-08-05 at 14:06 +1200, Chris Packham wrote:
> > > > >
> > > > >
> > > > > Hi All
Chris Packham writes:
> On Tue, 2019-08-06 at 21:32 +1000, Michael Ellerman wrote:
>> Chris Packham writes:
>> > On Mon, 2019-08-05 at 14:06 +1200, Chris Packham wrote:
>> > >
>> > > Hi All,
>> > >
>> > > I have a custom board that uses the Freescale/NXP T2080 SoC.
>> > >
>> > > The board boot
On Tue, 6 Aug 2019 18:00:12 +0800
Leo Yan wrote:
> This small patch set is to add support for function error injection;
> this can be used to eanble more advanced debugging feature, e.g.
> CONFIG_BPF_KPROBE_OVERRIDE.
>
> The patch 01/03 is to consolidate the function definition which can be
> s
On Tue, 2019-08-06 at 21:32 +1000, Michael Ellerman wrote:
> Chris Packham writes:
> >
> > On Mon, 2019-08-05 at 14:06 +1200, Chris Packham wrote:
> > >
> > > Hi All,
> > >
> > > I have a custom board that uses the Freescale/NXP T2080 SoC.
> > >
> > > The board boots fine using v4.19.60 but wh
KASAN support on powerpc64 is interesting:
- We want to be able to support inline instrumentation so as to be
able to catch global and stack issues.
- We run a lot of code at boot in real mode. This includes stuff like
printk(), so it's not feasible to just disable instrumentation
arou
In KASAN development I noticed that the powerpc-specific bitops
were not being picked up by the KASAN test suite.
Instrumentation is done via the bitops-instrumented.h header. It
requies that arch-specific versions of bitop functions are renamed
to arch_*. Do this renaming.
For clear_bit_unlock_i
Currently bitops-instrumented.h assumes that the architecture provides
both the atomic and non-atomic versions of the bitops (e.g. both
set_bit and __set_bit). This is true on x86, but is not always true:
there is a generic bitops/non-atomic.h header that provides generic
non-atomic versions. power
powerpc supports several different MMUs. In particular, book3s
machines support both a hash-table based MMU and a radix MMU.
These MMUs support different numbers of entries per directory
level: the PTES_PER_* defines evaluate to variables, not constants.
This leads to complier errors as global vari
Building on the work of Christophe, Aneesh and Balbir, I've ported
KASAN to 64-bit Book3S kernels running on the Radix MMU.
It builds on top Christophe's work on 32bit. It also builds on my
generic KASAN_VMALLOC series, available at:
https://patchwork.kernel.org/project/linux-mm/list/?series=15320
On Tue, 6 Aug 2019 11:23:08 -0500, Thomas Falcon wrote:
> Reported ethtool link settings for the ibmveth driver are currently
> hardcoded and no longer reflect the actual capabilities of supported
> hardware. There is no interface designed for retrieving this information
> from device firmware nor
From: "Aneesh Kumar K.V"
[ Upstream commit da1115fdbd6e86c62185cdd2b4bf7add39f2f82b ]
Currently, nvdimm subsystem expects the device numa node for SCM device to be
an online node. It also doesn't try to bring the device numa node online. Hence
if we use a non-online numa node as device node we h
https://bugzilla.kernel.org/show_bug.cgi?id=204371
--- Comment #8 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 284243
--> https://bugzilla.kernel.org/attachment.cgi?id=284243&action=edit
kernel .config (PowerMac G5 11,2, kernel 5.3-rc3)
--
You are receiving this mail because:
Y
https://bugzilla.kernel.org/show_bug.cgi?id=204371
--- Comment #7 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 284241
--> https://bugzilla.kernel.org/attachment.cgi?id=284241&action=edit
dmesg (PowerMac G5 11,2, kernel 5.3-rc3)
--
You are receiving this mail because:
You are on
https://bugzilla.kernel.org/show_bug.cgi?id=204371
--- Comment #6 from Erhard F. (erhar...@mailbox.org) ---
On Wed, 31 Jul 2019 12:09:54 +
bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=204371
>
> --- Comment #4 from m...@ellerman.id.au ---
> bugzill
On 8/5/19 10:01 AM, Christoph Hellwig wrote:
diff --git a/include/linux/dma-noncoherent.h b/include/linux/dma-noncoherent.h
index 3813211a9aad..9ae5cee543c4 100644
--- a/include/linux/dma-noncoherent.h
+++ b/include/linux/dma-noncoherent.h
@@ -42,13 +42,8 @@ void arch_dma_free(struct device *dev,
When a vCPU is brought done, the XIVE VP is first disabled and then
the event notification queues are freed. When freeing the queues, we
check for possible escalation interrupts and free them also.
But when a XIVE VP is disabled, the underlying XIVE ENDs also are
disabled in OPAL. When an END is d
On Tue, Aug 06, 2019 at 05:08:54PM +0100, Will Deacon wrote:
> On Sat, Aug 03, 2019 at 08:48:12AM +0200, Christoph Hellwig wrote:
> > On Fri, Aug 02, 2019 at 11:38:03AM +0100, Will Deacon wrote:
> > >
> > > So this boils down to a terminology mismatch. The Arm architecture
> > > doesn't have
> >
On Tue, Aug 06, 2019 at 05:45:03PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Aug 06, 2019 at 05:08:54PM +0100, Will Deacon wrote:
> > On Sat, Aug 03, 2019 at 08:48:12AM +0200, Christoph Hellwig wrote:
> > > On Fri, Aug 02, 2019 at 11:38:03AM +0100, Will Deacon wrote:
> > > >
> > > > S
Hi Thomas,
On 7/15/19 11:43 AM, Thomas Gleixner wrote:
> On Thu, 11 Jul 2019, Hoan Tran OS wrote:
>
>> Remove CONFIG_NODES_SPAN_OTHER_NODES as it's enabled
>> by default with NUMA.
>
> As I told you before this does not mention that the option is now enabled
> even for x86(32bit) configurations
Reported ethtool link settings for the ibmveth driver are currently
hardcoded and no longer reflect the actual capabilities of supported
hardware. There is no interface designed for retrieving this information
from device firmware nor is there any way to update current settings
to reflect observed
On Sat, Aug 03, 2019 at 08:48:12AM +0200, Christoph Hellwig wrote:
> On Fri, Aug 02, 2019 at 11:38:03AM +0100, Will Deacon wrote:
> >
> > So this boils down to a terminology mismatch. The Arm architecture doesn't
> > have
> > anything called "write combine", so in Linux we instead provide what th
On Tue, Aug 06, 2019 at 10:14:27PM +1000, Michael Ellerman wrote:
> Christopher M Riedl writes:
> > Yep, and that's no good. Hmm, executing the barrier() in the
> > non-shared-processor
> > case probably hurts performance here?
>
> It's only a "compiler barrier", so it shouldn't generate any cod
This patch implements arm specific functions regs_set_return_value() and
override_function_with_return() to support function error injection.
In the exception flow, it updates pt_regs::ARM_pc with pt_regs::ARM_lr
so can override the probed function return.
Signed-off-by: Leo Yan
---
arch/arm/Kc
Inspired by the commit 7cd01b08d35f ("powerpc: Add support for function
error injection"), this patch supports function error injection for
Arm64.
This patch mainly support two functions: one is regs_set_return_value()
which is used to overwrite the return value; the another function is
override_f
The function override_function_with_return() is defined separately for
each architecture and every architecture's definition is almost same
with each other. E.g. x86 and powerpc both define function in its own
asm/error-injection.h header and override_function_with_return() has
the same definition
This small patch set is to add support for function error injection;
this can be used to eanble more advanced debugging feature, e.g.
CONFIG_BPF_KPROBE_OVERRIDE.
The patch 01/03 is to consolidate the function definition which can be
suared cross architectures, patches 02,03/03 are used for enablin
On 8/6/19 5:25 AM, Michael Ellerman wrote:
Thomas Falcon writes:
Reported ethtool link settings for the ibmveth driver are currently
hardcoded and no longer reflect the actual capabilities of supported
hardware. There is no interface designed for retrieving this information
from device firmwa
> On August 6, 2019 at 7:14 AM Michael Ellerman wrote:
>
>
> Christopher M Riedl writes:
> >> On August 2, 2019 at 6:38 AM Michael Ellerman wrote:
> >> "Christopher M. Riedl" writes:
> >>
> >> This leaves us with a double test of is_shared_processor() doesn't it?
> >
> > Yep, and that's no
Christopher M Riedl writes:
>> On August 2, 2019 at 6:38 AM Michael Ellerman wrote:
>> "Christopher M. Riedl" writes:
>> > diff --git a/arch/powerpc/include/asm/spinlock.h
>> > b/arch/powerpc/include/asm/spinlock.h
>> > index 0a8270183770..6aed8a83b180 100644
>> > --- a/arch/powerpc/include/asm
"Christopher M. Riedl" writes:
> Xmon should be either fully or partially disabled depending on the
> kernel lockdown state.
>
> Put xmon into read-only mode for lockdown=integrity and completely
> disable xmon when lockdown=confidentiality. Xmon checks the lockdown
> state and takes appropriate a
Chris Packham writes:
> On Mon, 2019-08-05 at 14:06 +1200, Chris Packham wrote:
>> Hi All,
>>
>> I have a custom board that uses the Freescale/NXP T2080 SoC.
>>
>> The board boots fine using v4.19.60 but when I use v5.1.21 it locks
>> up
>> waiting for the other CPUs to come online (earlyprintk
On 8/6/19 8:42 AM, Sourabh Jain wrote:
> Add a sys interface to allow querying the memory reserved by fadump
> for saving the crash dump.
>
> Signed-off-by: Sourabh Jain
Looks good to me.
Reviewed-by: Mahesh Salgaonkar
Thanks,
-Mahesh.
> ---
> Documentation/powerpc/firmware-assisted-dump.rs
Thomas Falcon writes:
> Reported ethtool link settings for the ibmveth driver are currently
> hardcoded and no longer reflect the actual capabilities of supported
> hardware. There is no interface designed for retrieving this information
> from device firmware nor is there any way to update curren
Le 05/08/2019 à 08:43, Jason Yan a écrit :
One may want to disable kaslr when boot, so provide a cmdline parameter
'nokaslr' to support this.
Signed-off-by: Jason Yan
Cc: Diana Craciun
Cc: Michael Ellerman
Cc: Christophe Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Nicholas P
Le 05/08/2019 à 08:43, Jason Yan a écrit :
After we have the basic support of relocate the kernel in some
appropriate place, we can start to randomize the offset now.
Entropy is derived from the banner and timer, which will change every
build and boot. This not so much safe so additionally th
Le 05/08/2019 à 08:43, Jason Yan a écrit :
This patch add support to boot kernel from places other than KERNELBASE.
Since CONFIG_RELOCATABLE has already supported, what we need to do is
map or copy kernel to a proper place and relocate. Freescale Book-E
parts expect lowmem to be mapped by fixe
74 matches
Mail list logo
