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
https://bugzilla.kernel.org/show_bug.cgi?id=204479
Christophe Leroy (christophe.le...@c-s.fr) changed:
What|Removed |Added
CC||christophe.le
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
Mips uses the KSEG1 kernel memory segment do map dma coherent
allocations for non-coherent devices as uncachable, 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 mappings
All the way back to introducing dma_common_mmap we've defaulyed 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
Hello!
On 05.08.2019 11:01, Christoph Hellwig wrote:
Mips uses the KSEG1 kernel memory segment do map dma coherent
MIPS. s/do/to/?
allocations for n
on-coherent devices as uncachable, and does not have
Uncacheable?
any kind of special support for DMA_ATTR_WRITE_COMBINE in the al
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 output below).
> If I set maxcpu
On Mon, Aug 05, 2019 at 11:01:44AM +0300, Christoph Hellwig wrote:
> All the way back to introducing dma_common_mmap we've defaulyed to mark
s/defaultyed/defaulted/
> the pages as uncached. But this is wrong for DMA coherent devices.
> Later on DMA_ATTR_WRITE_COMBINE also got incorrect treatment
Hi all,
we have a few places where the DMA mapping layer has non-trivial default
actions that are questionable and/or dangerous.
This series instead wires up the mmap, get_sgtable and get_required_mask
methods explicitly and cleans up some surrounding areas. This also means
we could get rid of t
While the default ->mmap and ->get_sgtable implementations work for the
majority of our dma_map_ops impementations they are inherently safe
for others that don't use the page allocator or CMA and/or use their
own way of remapping not covered by the common code. So remove the
defaults if these meth
The comments are spot on and should be near the central API, not just
near a single implementation.
Signed-off-by: Christoph Hellwig
---
arch/arm/mm/dma-mapping.c | 11 ---
kernel/dma/mapping.c | 11 +++
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/a
Add a helper to check if DMA allocations for a specific device can be
mapped to userspace using dma_mmap_*.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-mapping.h | 5 +
kernel/dma/mapping.c| 23 +++
2 files changed, 28 insertions(+)
diff --git a/inclu
Replace the local hack with the dma_can_mmap helper to check if
a given device supports mapping DMA allocations to userspace.
Signed-off-by: Christoph Hellwig
---
sound/core/pcm_native.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/sound/core/pcm_native.c b/sound/core
Provide a pgprot_noncached like all the other nommu ports so that
common code can rely on it being able to be present. Note that this is
generally code that is not actually run on nommu, but at least we can
avoid nasty ifdefs by having a stub.
Signed-off-by: Christoph Hellwig
---
arch/m68k/incl
Now that we never use a default ->mmap implementation, and non-coherent
architectures can control the presence of ->mmap support by enabling
ARCH_HAS_DMA_COHERENT_TO_PFN for the dma direct implementation there
is no need for a global config option to control the availability
of dma_common_mmap.
Si
Most dma_map_ops instances are IOMMUs that work perfectly fine in 32-bits
of IOVA space, and the generic direct mapping code already provides its
own routines that is intelligent based on the amount of memory actually
present. Wire up the dma-direct routine for the ARM direct mapping code
as well,
On Mon, 05 Aug 2019 11:11:56 +0200,
Christoph Hellwig wrote:
>
> Replace the local hack with the dma_can_mmap helper to check if
> a given device supports mapping DMA allocations to userspace.
>
> Signed-off-by: Christoph Hellwig
> ---
> sound/core/pcm_native.c | 5 ++---
> 1 file changed, 2 in
Linus Torvalds writes:
> On Sun, Aug 4, 2019 at 4:49 AM Michael Ellerman wrote:
>>
>> Please pull some more powerpc fixes for 5.3:
>
> Hmm. This was caught by the gmail spam-filter for some reason. I don't
> see anything particularly different from your normal pull requests, so
> don't ask me why
On Wednesday, July 24, 2019 9:47:20 AM CEST Ran Wang wrote:
> Some user might want to go through all registered wakeup sources
> and doing things accordingly. For example, SoC PM driver might need to
> do HW programming to prevent powering down specific IP which wakeup
> source depending on. So add
Le 24/06/2019 à 05:12, Nicholas Piggin a écrit :
Christophe Leroy's on June 20, 2019 2:25 am:
Le 19/06/2019 à 05:59, Nicholas Piggin a écrit :
Christophe Leroy's on June 11, 2019 4:46 pm:
Le 10/06/2019 à 05:08, Nicholas Piggin a écrit :
I would like to remove the early ioremap or make
Hi Thiago,
> > The patch looks good now.
>
> Thanks! Can I add your Reviewed-by?
sorry, for the late answer, but I was on vacation the last two weeks. I hope
it's not too late now.
Reviewed-by: Philipp Rudo
https://bugzilla.kernel.org/show_bug.cgi?id=204479
--- Comment #3 from Erhard F. (erhar...@mailbox.org) ---
Yes, at least one usb driver is also affected.
Also radeon.ko sometimes loads ok, sometimes it stalls:
# modprobe -v radeon
insmod /lib/modules/5.3.0-rc2+/kernel/drivers/i2c/algos/i2c-algo-
On Mon, 2019-08-05 at 15:11 +0200, Philipp Rudo wrote:
> Hi Thiago,
>
> > > The patch looks good now.
> >
> > Thanks! Can I add your Reviewed-by?
>
> sorry, for the late answer, but I was on vacation the last two weeks. I hope
> it's not too late now.
>
> Reviewed-by: Philipp Rudo
Thanks!
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 8/2/19 12:29 PM, Nathan Lynch wrote:
> The LPAR migration implementation and userspace-initiated cpu hotplug
> can interleave their executions like so:
>
> 1. Set cpu 7 offline via sysfs.
>
> 2. Begin a partition migration, whose implementation requires the OS
>to ensure all present cpus a
Hi Christophe ,
Can you take a look at patch 6,7,9 of this version?
Thank you,
Jason
On 2019/8/5 14:43, Jason Yan wrote:
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 CO
Determining if a processor is in shared processor mode is not a constant
so don't hide it behind a #define.
Signed-off-by: Christopher M. Riedl
Reviewed-by: Andrew Donnellan
---
arch/powerpc/include/asm/spinlock.h | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
Booting w/ ppc64le_defconfig + CONFIG_PREEMPT results in the attached
kernel trace due to calling shared-processor spinlocks while not running
in an SPLPAR. Previously, the out-of-line spinlocks implementations were
selected based on CONFIG_PPC_SPLPAR at compile time without a runtime
shared-proces
The __rw_yield and __spin_yield locks only pertain to SPLPAR mode.
Rename them to make this relationship obvious.
Signed-off-by: Christopher M. Riedl
Reviewed-by: Andrew Donnellan
---
arch/powerpc/include/asm/spinlock.h | 6 --
arch/powerpc/lib/locks.c| 6 +++---
2 files changed
Fixes an oops when calling the shared-processor spinlock implementation
from a non-SP LPAR. Also take this opportunity to refactor
SHARED_PROCESSOR a bit.
Reference: https://github.com/linuxppc/issues/issues/229
Changes since v2:
- Directly call splpar_*_yield() to avoid duplicate call to
is
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 files changed, 19 insertions(+)
dif
Mikey, mpe ...
Any thoughts?
> /* create a coherent mapping */
> ret = dma_common_contiguous_remap(page, size, VM_USERMAP,
> - arch_dma_mmap_pgprot(dev, PAGE_KERNEL, attrs),
> + dma_pgprot(dev, PAGE_KERNEL, attrs),
> __builtin_return_address(0)
Hi Xiaowei,
> -Original Message-
> From: Xiaowei Bao [mailto:xiaowei@nxp.com]
> Sent: 2019年8月5日 12:05
> To: bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; Leo Li ; kis...@ti.com;
> lorenzo.pieral...@arm.com; a...@arndb.de; gre...@linuxfoundation.o
Hello,
This version has only a small change in the last patch as requested by
Christoph and Halil, and collects Reviewed-by's.
These patches are applied on top of v5.3-rc2.
I don't have a way to test SME, SEV, nor s390's PEF so the patches have only
been build tested.
Changelog
Since v3:
- Pa
powerpc is also going to use this feature, so put it in a generic location.
Signed-off-by: Thiago Jung Bauermann
Reviewed-by: Thomas Gleixner
Reviewed-by: Christoph Hellwig
---
arch/Kconfig | 3 +++
arch/s390/Kconfig | 4 +---
arch/x86/Kconfig | 4 +---
3 files changed, 5 insertions(+),
sme_active() is an x86-specific function so it's better not to call it from
generic code. Christoph Hellwig mentioned that "There is no reason why we
should have a special debug printk just for one specific reason why there
is a requirement for a large DMA mask.", so just remove dma_check_mask().
sme_active() is an x86-specific function so it's better not to call it from
generic code.
There's no need to mention which memory encryption feature is active, so
just use a more generic message. Besides, other architectures will have
different names for similar technology.
Signed-off-by: Thiago
Now that generic code doesn't reference them, move sme_active() and
sme_me_mask to x86's .
Also remove the export for sme_active() since it's only used in files that
won't be built as modules. sme_me_mask on the other hand is used in
arch/x86/kvm/svm.c (via __sme_set() and __psp_pa()) which can be
Secure Encrypted Virtualization is an x86-specific feature, so it shouldn't
appear in generic kernel code because it forces non-x86 architectures to
define the sev_active() function, which doesn't make a lot of sense.
To solve this problem, add an x86 elfcorehdr_read() function to override
the gen
All references to sev_active() were moved to arch/x86 so we don't need to
define it for s390 anymore.
Signed-off-by: Thiago Jung Bauermann
Reviewed-by: Christoph Hellwig
Reviewed-by: Halil Pasic
---
arch/s390/include/asm/mem_encrypt.h | 1 -
arch/s390/mm/init.c | 7 +--
2 f
On Mon, Aug 05, 2019 at 07:55:44PM -0700, Gavin Li wrote:
> > /* create a coherent mapping */
> > ret = dma_common_contiguous_remap(page, size, VM_USERMAP,
> > - arch_dma_mmap_pgprot(dev, PAGE_KERNEL, attrs),
> > + dma_pgprot(dev, PAGE_KER
From: Claudio Carvalho
The ultracalls (ucalls for short) allow the Secure Virtual Machines
(SVM)s and hypervisor to request services from the ultravisor such as
accessing a register or memory region that can only be accessed when
running in ultravisor-privileged mode.
This patch adds ucall_noret
Hello,
There are three new patches from Claudio's "kvmppc: Paravirtualize KVM to
support ultravisor" series. Two of them are borrowed (meaning that he will
submit them with his series as well) and included here so that this series
can stand on its own. They are the one introducing ucall_norets() (
Introduce CONFIG_PPC_SVM to control support for secure guests and include
Ultravisor-related helpers when it is selected
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/include/asm/asm-prototypes.h | 2 +-
arch/powerpc/kernel/Makefile | 4 +++-
arch/powerpc/platforms/pseries
From: Benjamin Herrenschmidt
For secure VMs, the signing tool will create a ticket called the "ESM blob"
for the Enter Secure Mode ultravisor call with the signatures of the kernel
and initrd among other things.
This adds support to the wrapper script for adding that blob via the "-e"
option to
From: Ram Pai
Make the Enter-Secure-Mode (ESM) ultravisor call to switch the VM to secure
mode. Pass kernel base address and FDT address so that the Ultravisor is
able to verify the integrity of the VM using information from the ESM blob.
Add "svm=" command line option to turn on switching to se
From: Ram Pai
These functions are used when the guest wants to grant the hypervisor
access to certain pages.
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/include/asm/ultravisor-api.h | 2 ++
arch/powerpc/include/asm/ultravisor.h | 24 ++
From: Sukadev Bhattiprolu
The ultravisor processor mode is introduced in POWER platforms that
supports the Protected Execution Facility (PEF). Ultravisor is higher
privileged than hypervisor mode.
In PEF enabled platforms, the MSR_S bit is used to indicate if the
thread is in secure state. With
Helps document what the hard-coded number means.
Also take the opportunity to fix an #endif comment.
Suggested-by: Alexey Kardashevskiy
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/kernel/paca.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/power
From: Anshuman Khandual
LPPACA structures need to be shared with the host. Hence they need to be in
shared memory. Instead of allocating individual chunks of memory for a
given structure from memblock, a contiguous chunk of memory is allocated
and then converted into shared memory. Subsequent all
From: Anshuman Khandual
Secure guests need to share the DTL buffers with the hypervisor. To that
end, use a kmem_cache constructor which converts the underlying buddy
allocated SLUB cache pages into shared memory.
Signed-off-by: Anshuman Khandual
Signed-off-by: Thiago Jung Bauermann
---
arch/
From: Ram Pai
A new kernel deserves a clean slate. Any pages shared with the hypervisor
is unshared before invoking the new kernel. However there are exceptions.
If the new kernel is invoked to dump the current kernel, or if there is a
explicit request to preserve the state of the current kernel,
From: Ryan Grimm
User space might want to know it's running in a secure VM. It can't do
a mfmsr because mfmsr is a privileged instruction.
The solution here is to create a cpu attribute:
/sys/devices/system/cpu/svm
which will read 0 or 1 based on the S bit of the guest's CPU 0.
Signed-off-by
From: Sukadev Bhattiprolu
Normally, the HV emulates some instructions like MSGSNDP, MSGCLRP
from a KVM guest. To emulate the instructions, it must first read
the instruction from the guest's memory and decode its parameters.
However for a secure guest (aka SVM), the page containing the
instructi
Secure guest memory is inacessible to devices so regular DMA isn't
possible.
In that case set devices' dma_map_ops to NULL so that the generic
DMA code path will use SWIOTLB and DMA to bounce buffers.
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/platforms/pseries/iommu.c | 6 +-
1
From: Anshuman Khandual
SWIOTLB checks range of incoming CPU addresses to be bounced and sees if
the device can access it through its DMA window without requiring bouncing.
In such cases it just chooses to skip bouncing. But for cases like secure
guests on powerpc platform all addresses need to b
On Mon, Aug 05, 2019 at 11:22:03AM +0200, Takashi Iwai wrote:
> This won't work as expected, unfortunately. It's a bit tricky check,
> since the driver may have its own mmap implementation via
> substream->ops->mmap, and the dma_buffer.dev.dev might point to
> another object depending on the dma_b
From: Sukadev Bhattiprolu
POWER9 processor includes support for Protected Execution Facility (PEF).
Attached documentation provides an overview of PEF and defines the API
for various interfaces that must be implemented in the Ultravisor
firmware as well as in the KVM Hypervisor.
Based on input f
From: Ryan Grimm
Enables running as a secure guest in platforms with an Ultravisor.
Signed-off-by: Ryan Grimm
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/configs/ppc64_defconfig | 1 +
arch/powerpc/configs/pseries_defconfig | 1 +
2 files changed, 2 inserti
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(&iommu_mem_nb);
>
> - set_pci_dma_ops(&dma_iommu_ops);
> + if (is
On Tue, 06 Aug 2019 07:29:49 +0200,
Christoph Hellwig wrote:
>
> On Mon, Aug 05, 2019 at 11:22:03AM +0200, Takashi Iwai wrote:
> > This won't work as expected, unfortunately. It's a bit tricky check,
> > since the driver may have its own mmap implementation via
> > substream->ops->mmap, and the d
Add the PCIe compatible string for LS1028A
Signed-off-by: Xiaowei Bao
Signed-off-by: Hou Zhiqiang
---
v2:
- no change.
v3:
- no change.
Documentation/devicetree/bindings/pci/layerscape-pci.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pci/layerscap
LS1028a implements 2 PCIe 3.0 controllers.
Signed-off-by: Xiaowei Bao
Signed-off-by: Hou Zhiqiang
---
v2:
- Fix up the legacy INTx allocate failed issue.
v3:
- no change.
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 52 ++
1 file changed, 52 insertions(+)
diff --
Add support for the LS1028a PCIe controller.
Signed-off-by: Xiaowei Bao
Signed-off-by: Hou Zhiqiang
---
v2:
- no change.
v3:
- Reuse the ls2088 driver data structurt.
drivers/pci/controller/dwc/pci-layerscape.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/controller/dwc/pc
65 matches
Mail list logo
