On Tue, Jul 16, 2019 at 05:00:44PM +1000, Oliver O'Halloran wrote:
> On Tue, 2019-07-16 at 16:48 +1000, Sam Bobroff wrote:
> > On Thu, Jun 20, 2019 at 01:45:24PM +1000, Oliver O'Halloran wrote:
> > > On Thu, Jun 20, 2019 at 12:40 PM Alexey Kardashevskiy
> > > wrote:
> > > > On 19/06/2019 14:27,
At the moment we create a small window only for 32bit devices, the window
maps 0..2GB of the PCI space only. For other devices we either use
a sketchy bypass or hardware bypass but the former can only work if
the amount of RAM is no bigger than the device's DMA mask and the latter
requires devices
We allocate only the first level of multilevel TCE tables for KVM
already (alloc_userspace_copy==true), and the rest is allocated on demand.
This is not enabled though for bare metal.
This removes the KVM limitation (implicit, via the alloc_userspace_copy
parameter) and always allocates just the
POWER8 and newer support a bypass mode which maps all host memory to
PCI buses so an IOMMU table is not always required. However if we fail to
create such a table, the DMA setup fails and the kernel does not boot.
This skips the 32bit DMA setup check if the bypass is selected.
Signed-off-by:
This is an attempt to allow DMA masks between 32..59 which are not large
enough to use either a PHB3 bypass mode or a sketchy bypass. Depending
on the max order, up to 40 is usually available.
This is an optimization and not a bug fix for DMA API usage.
Changelogs are in the patches.
This is
pnv_tce() returns a pointer to a TCE entry and originally a TCE table
would be pre-allocated. For the default case of 2GB window the table
needs only a single level and that is fine. However if more levels are
requested, it is possible to get a race when 2 threads want a pointer
to a TCE entry
There is a race between releasing an irq on one cpu and fetching it
from XIVE on another cpu. When such released irq appears in a queue,
we take it from the queue but we do not change the current priority
on that cpu and since there is no handler for the irq, EOI is never
called and the cpu
The test on generic_handle_irq() catches interrupt events that
were served on a target CPU while the source interrupt was being
shutdown on another CPU. This may lead to a blocked interrupt queue
on a target CPU so if there is another assigned irq on that CPU, that
device stops working.
This adds
Now 2 patches.
v3 is here: https://patchwork.ozlabs.org/patch/1133106/
This is based on sha1
a2b6f26c264e Christophe Leroy "powerpc/module64: Use symbolic instructions
names.".
Please comment. Thanks.
Alexey Kardashevskiy (2):
powerpc: Add handler for orphaned interrupts
powerpc/xive:
On Thu, Jul 18, 2019 at 1:16 PM Shawn Anastasio wrote:
>
> On 7/17/19 9:59 PM, Alexey Kardashevskiy wrote:
> >
> > On 18/07/2019 09:54, Shawn Anastasio wrote:
> >> The refactor of powerpc DMA functions in commit cc17d780
> >> ("powerpc/dma: remove dma_nommu_mmap_coherent") incorrectly
> >>
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
---
arch/s390/include/asm/mem_encrypt.h | 1 -
arch/s390/mm/init.c | 8 +---
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git
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
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
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
Hello,
This version is mostly about splitting up patch 2/3 into three separate
patches, as suggested by Christoph Hellwig. Two other changes are a fix in
patch 1 which wasn't selecting ARCH_HAS_MEM_ENCRYPT for s390 spotted by
Janani and removal of sme_active and sev_active symbol exports as
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(+),
On Tue, Jul 16, 2019 at 7:08 PM Aneesh Kumar K.V
wrote:
>
> This is similar to what ACPI does. Nvdimm layer doesn't bring the SCM device
> numa node online. Hence we need to make sure we always use an online node
> as ndr_desc.numa_node. Otherwise this result in kernel crashes. The target
> node
On 2019-07-14, Al Viro wrote:
> On Sun, Jul 14, 2019 at 05:00:29PM +1000, Aleksa Sarai wrote:
> > The basic property being guaranteed by LOOKUP_IN_ROOT is that it will
> > not result in resolution of a path component which was not inside the
> > root of the dirfd tree at some point during
On 7/17/19 9:59 PM, Alexey Kardashevskiy wrote:
On 18/07/2019 09:54, Shawn Anastasio wrote:
The refactor of powerpc DMA functions in commit cc17d780
("powerpc/dma: remove dma_nommu_mmap_coherent") incorrectly
changes the way DMA mappings are handled on powerpc.
Since this change, all
On 18/07/2019 09:54, Shawn Anastasio wrote:
The refactor of powerpc DMA functions in commit cc17d780
("powerpc/dma: remove dma_nommu_mmap_coherent") incorrectly
changes the way DMA mappings are handled on powerpc.
Since this change, all mapped pages are marked as cache-inhibited
through
Michael Ellerman [m...@ellerman.id.au] wrote:
> Claudio Carvalho writes:
> > From: Sukadev Bhattiprolu
> >
> > To enter a secure guest, we have to go through the ultravisor, therefore
> > we do a ucall when we are entering a secure guest.
> >
> > This change is needed for any sort of entry to
On Thu, Jul 18, 2019 at 1:46 AM Segher Boessenkool
wrote:
>
> On Thu, Jul 18, 2019 at 12:19:36AM +0900, Masahiro Yamada wrote:
> > On Wed, Jul 17, 2019 at 11:38 PM Segher Boessenkool
> > wrote:
> > >
> > > On Tue, Jul 16, 2019 at 10:15:47PM +1000, Michael Ellerman wrote:
> > > > Segher
While removing an ibmvfc client adapter a WARN_ON like the following WARN_ON
is seen in the kernel log:
WARNING: CPU: 6 PID: 5421 at ./include/linux/dma-mapping.h:541
ibmvfc_free_event_pool+0x12c/0x1f0 [ibmvfc]
CPU: 6 PID: 5421 Comm: rmmod Tainted: GE
The refactor of powerpc DMA functions in commit cc17d780
("powerpc/dma: remove dma_nommu_mmap_coherent") incorrectly
changes the way DMA mappings are handled on powerpc.
Since this change, all mapped pages are marked as cache-inhibited
through the default implementation of
On Thu, Jul 18, 2019 at 12:19:36AM +0900, Masahiro Yamada wrote:
> On Wed, Jul 17, 2019 at 11:38 PM Segher Boessenkool
> wrote:
> >
> > On Tue, Jul 16, 2019 at 10:15:47PM +1000, Michael Ellerman wrote:
> > > Segher Boessenkool writes:
> > > And it's definitely calling ar with no flags, eg:
> > >
On Wed, 17 Jul 2019 09:28:17 -0300
Mauro Carvalho Chehab wrote:
> Some files over there won't parse well by Sphinx.
>
> Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab
Hi Mauro,
Does feel like this one should perhaps have been broken up a touch!
For the IIO ones I've eyeballed it rather
On Wed, Jul 17, 2019 at 11:38 PM Segher Boessenkool
wrote:
>
> On Tue, Jul 16, 2019 at 10:15:47PM +1000, Michael Ellerman wrote:
> > Segher Boessenkool writes:
> > And it's definitely calling ar with no flags, eg:
> >
> > rm -f init/built-in.a; powerpc-linux-ar rcSTPD init/built-in.a
> >
On Thu, 2019-07-11 at 22:57 +1000, Michael Ellerman wrote:
> Claudio Carvalho writes:
> > From: Michael Anderson
> >
> > When running under an ultravisor, the ultravisor controls the real
> > partition table and has it in secure memory where the hypervisor
> > can't
> > access it, and therefore
On Tue, Jul 16, 2019 at 10:15:47PM +1000, Michael Ellerman wrote:
> Segher Boessenkool writes:
> And it's definitely calling ar with no flags, eg:
>
> rm -f init/built-in.a; powerpc-linux-ar rcSTPD init/built-in.a init/main.o
> init/version.o init/do_mounts.o init/do_mounts_rd.o
Em Tue, Jul 16, 2019 at 06:27:19PM -0700, Palmer Dabbelt escreveu:
> I'm not sure why it's necessary to add this explicitly to tools/ as well
> as arch/, but there were a few instances of fspick in here so I blindly
> added fchmodat4 in the same fashion.
The copies in tools/ for these specific
Several entries at the stable ABI files won't parse if we pass
them directly to the ReST output.
Adjust them, in order to allow adding their contents as-is at
the stable ABI book.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/stable/firewire-cdev| 4 +
Several entries at the stable ABI files won't parse if we pass
them directly to the ReST output.
Adjust them, in order to allow adding their contents as-is at
the stable ABI book.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/stable/firewire-cdev| 4 +
On Wed, Jul 17, 2019 at 3:29 AM Palmer Dabbelt wrote:
>
> This registers the new fchmodat4 syscall in most places as nuber 434,
> with alpha being the exception where it's 544. I found all these sites
> by grepping for fspick, which I assume has found me everything.
434 is now pidfd_open, the
From: "Gautham R. Shenoy"
xive_find_target_in_mask() has the following for(;;) loop which has a
bug when @first == cpumask_first(@mask) and condition 1 fails to hold
for every CPU in @mask. In this case we loop forever in the for-loop.
first = cpu;
for (;;) {
if (cpu_online(cpu)
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
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
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
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
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
---
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
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
---
arch/powerpc/kernel/kaslr_booke.c | 11 +++
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
---
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
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
---
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
---
arch/powerpc/include/asm/nohash/mmu-book3e.h | 10
On 17/07/2019 15:00, Alexey Kardashevskiy wrote:
There is a race between releasing an irq on one cpu and fetching it
from XIVE on another cpu as there does not seem to be any locking between
these, probably because xive_irq_chip::irq_shutdown() is supposed to
remove the irq from all queues in
47 matches
Mail list logo
