Handling TIP.PGD for an address filter for a guest kernel is the same as a
host kernel, but user space decoding, and hence address filters, are not
supported.
Signed-off-by: Adrian Hunter
---
tools/perf/util/intel-pt.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/to
invalid virtual addresses (e.g. 0x0).
Fix the detection checking that it's actually a kernel address starting
at PAGE_OFFSET.
Fixes: 68dd8ef32162 ("arm64: memory: Fix virt_addr_valid() using
__is_lm_address()")
Cc: # 5.4.x
Cc: Will Deacon
Suggested-by: Catalin Marinas
Reviewed-by:
invalid virtual addresses (e.g. 0x0).
Fix the detection checking that it's actually a kernel address starting
at PAGE_OFFSET.
Fixes: 68dd8ef32162 ("arm64: memory: Fix virt_addr_valid() using
__is_lm_address()")
Cc: # 5.4.x
Cc: Will Deacon
Suggested-by: Catalin Marinas
Reviewed-by:
alid virtual addresses (e.g. 0x0).
>
> Fix the detection checking that it's actually a kernel address starting
> at PAGE_OFFSET.
Applied to arm64 (for-next/fixes), thanks!
[1/1] arm64: Fix kernel address detection of __is_lm_address()
https://git.kernel.org/arm64/c/519ea6f1c82f
--
Catalin
as a side effect that virt_addr_valid() returns true even for
>> invalid virtual addresses (e.g. 0x0).
>>
>> Fix the detection checking that it's actually a kernel address starting
>> at PAGE_OFFSET.
>>
>> Fixes: f4693c2716b35 ("arm64: mm: extend linear regi
alid virtual addresses (e.g. 0x0).
>
> Fix the detection checking that it's actually a kernel address starting
> at PAGE_OFFSET.
>
> Fixes: f4693c2716b35 ("arm64: mm: extend linear region for 52-bit VA
> configurations")
> Cc: # 5.4.x
Not sure what happened w
lly a kernel address starting
at PAGE_OFFSET.
Fixes: f4693c2716b35 ("arm64: mm: extend linear region for 52-bit VA
configurations")
Cc: # 5.4.x
Cc: Catalin Marinas
Cc: Will Deacon
Suggested-by: Catalin Marinas
Reviewed-by: Catalin Marinas
Acked-by: Mark Rutland
Signed-off-by: Vi
ently, the __is_lm_address() check just masks out the top 12 bits
>>>>>>>> of the address, but if they are 0, it still yields a true result.
>>>>>>>> This has as a side effect that virt_addr_valid() returns true even for
>>>>>>>&g
;>>>>> of the address, but if they are 0, it still yields a true result.
> >>>>>> This has as a side effect that virt_addr_valid() returns true even for
> >>>>>> invalid virtual addresses (e.g. 0x0).
> >>>>>>
>
;>>> This has as a side effect that virt_addr_valid() returns true even for
>>>>>> invalid virtual addresses (e.g. 0x0).
>>>>>>
>>>>>> Improve the detection checking that it's actually a kernel address
>>>>>> sta
even for
> invalid virtual addresses (e.g. 0x0).
>
> Improve the detection checking that it's actually a kernel address
> starting at PAGE_OFFSET.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Suggested-by: Catalin Marinas
> Reviewed-by: Catalin Marinas
> Signed-of
even for
> >>>> invalid virtual addresses (e.g. 0x0).
> >>>>
> >>>> Improve the detection checking that it's actually a kernel address
> >>>> starting at PAGE_OFFSET.
> >>>>
> >>>> Cc: Catalin Marinas
> &
On Mon, Jan 25, 2021 at 02:59:12PM +, Catalin Marinas wrote:
> On Mon, Jan 25, 2021 at 02:36:34PM +, Vincenzo Frascino wrote:
> > On 1/25/21 1:02 PM, Mark Rutland wrote:
> > > On Fri, Jan 22, 2021 at 03:56:40PM +, Vincenzo Frascino wrote:
> > > This patch itself looks fine, but it's not
heck just masks out the top 12 bits
>>>> of the address, but if they are 0, it still yields a true result.
>>>> This has as a side effect that virt_addr_valid() returns true even for
>>>> invalid virtual addresses (e.g. 0x0).
>>>>
>>&g
ress, but if they are 0, it still yields a true result.
> >> This has as a side effect that virt_addr_valid() returns true even for
> >> invalid virtual addresses (e.g. 0x0).
> >>
> >> Improve the detection checking that it's actually a kernel address
> &
ult.
>> This has as a side effect that virt_addr_valid() returns true even for
>> invalid virtual addresses (e.g. 0x0).
>>
>> Improve the detection checking that it's actually a kernel address
>> starting at PAGE_OFFSET.
>>
>> Cc: Catalin Marinas
lly a kernel address
starting at PAGE_OFFSET.
Cc: Catalin Marinas
Cc: Will Deacon
Suggested-by: Catalin Marinas
Reviewed-by: Catalin Marinas
Signed-off-by: Vincenzo Frascino
---
arch/arm64/include/asm/memory.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/
alid virtual addresses (e.g. 0x0).
>
> Improve the detection checking that it's actually a kernel address
> starting at PAGE_OFFSET.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Suggested-by: Catalin Marinas
> Signed-off-by: Vincenzo Frascino
Reviewed-by: Catalin M
lly a kernel address
starting at PAGE_OFFSET.
Cc: Catalin Marinas
Cc: Will Deacon
Suggested-by: Catalin Marinas
Signed-off-by: Vincenzo Frascino
---
arch/arm64/include/asm/memory.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/memory.h b/arch/
On 1/21/21 4:02 PM, Vincenzo Frascino wrote:
>> I think it'd be worth checking, if we're going to use this in common
>> code.
>>
> Ok, I will run some tests and let you know.
>
I checked on x86_64 and ppc64 (they both have KASAN implementation):
I added the following:
printk("%s: %d\n", __fun
e kernel VA range, instead.
>
> I have no strong opinion either way even if personally I feel that modifying
> __is_lm_address() is more clear. Feel free to propose something.
Sure; I'm happy for it to live within __is_lm_address() if that's
simpler overall, given it doesn
I think it'd be worth checking, if we're going to use this in common
> code.
>
Ok, I will run some tests and let you know.
>>> I wonder if it's worth virt_addr_valid() having an explicit check for
>>> the kernel VA range, instead.
>>
>> I have no
explicit check for
> the kernel VA range, instead.
>
I have no strong opinion either way even if personally I feel that modifying
__is_lm_address() is more clear. Feel free to propose something.
>> Fix the detection checking that it's actually a kernel address starting
>> at P
h virt_addr_valid() having an explicit check for
the kernel VA range, instead.
> Fix the detection checking that it's actually a kernel address starting
> at PAGE_OFFSET.
>
> Fixes: f4693c2716b35 ("arm64: mm: extend linear region for 52-bit VA
> configurations")
> Cc:
lly a kernel address starting
at PAGE_OFFSET.
Fixes: f4693c2716b35 ("arm64: mm: extend linear region for 52-bit VA
configurations")
Cc: Catalin Marinas
Cc: Will Deacon
Suggested-by: Catalin Marinas
Signed-off-by: Vincenzo Frascino
---
arch/arm64/include/asm/memory.h | 2 +-
1 file chang
One thing that the address filters can't do at the moment is cover
anonymous mappings. Apparently, there is code out there that generates
executable code in anonymous mappings and executes it in place. And at
the moment we only allow file-based address filters for userspace.
The easiest way to do
On 28-08-20, 14:23, Ulf Hansson wrote:
> Anders, Naresh - thanks for testing and reporting. I am dropping the
> patch from my tree.
>
> Viresh, I suggest to keep Anders/Naresh in the cc, for the next
> version. Then I can wait for their tested-by tag before I apply again.
Sorry for the trouble, I
On Fri, 28 Aug 2020 at 12:29, Anders Roxell wrote:
>
> On Fri, 28 Aug 2020 at 11:35, Ulf Hansson wrote:
> >
> > On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju
> > wrote:
> > >
> > > On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju
> > > wrote:
> > > >
> > > > On Thu, 27 Aug 2020 at 15:42, Viresh Ku
On Fri, 28 Aug 2020 at 11:35, Ulf Hansson wrote:
>
> On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju
> wrote:
> >
> > On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju
> > wrote:
> > >
> > > On Thu, 27 Aug 2020 at 15:42, Viresh Kumar
> > > wrote:
> > > >
> > > > On 27-08-20, 11:48, Arnd Bergmann wro
On Fri, 28 Aug 2020 at 15:05, Ulf Hansson wrote:
>
> On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju
> wrote:
> >
> > On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju
> > wrote:
> > >
> > > On Thu, 27 Aug 2020 at 15:42, Viresh Kumar
> > > wrote:
> > > >
> > > > On 27-08-20, 11:48, Arnd Bergmann wro
On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju wrote:
>
> On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju
> wrote:
> >
> > On Thu, 27 Aug 2020 at 15:42, Viresh Kumar wrote:
> > >
> > > On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > > > > [3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > > > > [
On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju wrote:
>
> On Thu, 27 Aug 2020 at 15:42, Viresh Kumar wrote:
> >
> > On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > > > [3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > > > [3.683431] sdhci_msm_probe+0x284/0x9a0
> > >
> > > dev_pm_opp_put_cl
On Thu, 27 Aug 2020 at 15:42, Viresh Kumar wrote:
>
> On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > > [3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > > [3.683431] sdhci_msm_probe+0x284/0x9a0
> >
> > dev_pm_opp_put_clkname() is part of the error handling in the
> > probe function, so I
On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > [3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > [3.683431] sdhci_msm_probe+0x284/0x9a0
>
> dev_pm_opp_put_clkname() is part of the error handling in the
> probe function, so I would deduct there are two problems:
>
> - something failed du
;next = LIST_POISON1;
n->pprev = LIST_POISON2;
}
> > [3.514695] Mem abort info:
> > [3.522421] ESR = 0x9644
> > [3.525096] EC = 0x25: DABT (current EL), IL = 32 bits
> > [3.528236] SET = 0, FnV = 0
> > [3.533703] EA = 0, S1PTW =
] Mem abort info:
> [3.522421] ESR = 0x9644
> [3.525096] EC = 0x25: DABT (current EL), IL = 32 bits
> [3.528236] SET = 0, FnV = 0
> [3.533703] EA = 0, S1PTW = 0
> [3.536561] Data abort info:
> [3.539601] ISV = 0, ISS = 0x0044
> [3.5
0, S1PTW = 0
> [3.536561] Data abort info:
> [3.539601] ISV = 0, ISS = 0x0044
> [3.542727] CM = 0, WnR = 1
> [3.546287] [dead0108] address between user and kernel address
> ranges
> [3.549414] Internal error: Oops: 9644 [#1] PRE
[3.528236] SET = 0, FnV = 0
[3.533703] EA = 0, S1PTW = 0
[3.536561] Data abort info:
[3.539601] ISV = 0, ISS = 0x0044
[3.542727] CM = 0, WnR = 1
[3.546287] [dead0108] address between user and kernel address ranges
[3.549414] Internal error: Oops
How about performance when running with ASI?
How about performance when running with ASI?
How about performance when running kvm example or isolate other kernel data?
0x8000
/* By simply checking Address >= 0x8000, we know if its a kernel address */
-#define SIMPLE_KERNEL_ADDRESS 1
+ not.\scratch, \addr
+#else
+ rlwinm \scratch, \addr, 16, 0xfff8
+ cmpli cr0, \scratch, PAGE_OFFSET@h
#endif
+.endm
/*
* We need an
0x8000
/* By simply checking Address >= 0x8000, we know if its a kernel address */
-#define SIMPLE_KERNEL_ADDRESS 1
+ not.\scratch, \addr
+#else
+ rlwinm \scratch, \addr, 16, 0xfff8
+ cmpli cr0, \scratch, PAGE_OFFSET@h
#endif
+.endm
/*
* We need an
0x8000
/* By simply checking Address >= 0x8000, we know if its a kernel address */
-#define SIMPLE_KERNEL_ADDRESS 1
+ not.\scratch, \addr
+#else
+ rlwinm \scratch, \addr, 16, 0xfff8
+ cmpli cr0, \scratch, PAGE_OFFSET@h
#endif
+.endm
/*
* We need an
Introduce core functions and structures for implementing Address Space
Isolation (ASI). Kernel address space isolation provides the ability to
run some kernel code with a reduced kernel address space.
An address space isolation is defined with a struct asi structure and
associated with an ASI
On Tue, Oct 08, 2019 at 05:25:17PM +0300, Dan Carpenter wrote:
> On Tue, Oct 08, 2019 at 04:21:54PM +0200, Matteo Croce wrote:
> > On Tue, Oct 8, 2019 at 3:16 PM Dan Carpenter
> > wrote:
> > >
> > > The subject doesn't match the patch. It should just be "remove useless
> > > printk".
> > >
> > >
On Tue, Oct 08, 2019 at 04:21:54PM +0200, Matteo Croce wrote:
> On Tue, Oct 8, 2019 at 3:16 PM Dan Carpenter wrote:
> >
> > The subject doesn't match the patch. It should just be "remove useless
> > printk".
> >
> > regards,
> > dan carpenter
> >
>
> Well, it avoids leaking an address by removin
On Tue, Oct 8, 2019 at 3:16 PM Dan Carpenter wrote:
>
> The subject doesn't match the patch. It should just be "remove useless
> printk".
>
> regards,
> dan carpenter
>
Well, it avoids leaking an address by removing an useless printk.
It seems that GKH already picked the patch in his staging tre
The subject doesn't match the patch. It should just be "remove useless
printk".
regards,
dan carpenter
Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with %p"),
an obfuscated kernel pointer is printed at boot:
vchiq: vchiq_init_state: slot_zero = (ptrval)
Remove the the print completely, as it's useless without the address.
Signed-off-by: Matteo Croce
---
drivers/sta
Hi Adrian,
On Wed, Sep 04, 2019 at 10:26:13AM +0300, Adrian Hunter wrote:
[...]
> > Could you take chance to review my below replying? I'd like to get
> > your confirmation before I send out offical patch.
>
> It is not necessary to do kallsyms__parse for x86_64, so it would be better
> to che
On 2/09/19 5:15 PM, Leo Yan wrote:
> Hi Adrian,
>
> On Mon, Aug 26, 2019 at 08:51:05PM +0800, Leo Yan wrote:
>> Hi Adrian,
>>
>> On Fri, Aug 16, 2019 at 04:00:02PM +0300, Adrian Hunter wrote:
>>> On 16/08/19 4:45 AM, Leo Yan wrote:
Hi Adrian,
On Thu, Aug 15, 2019 at 02:45:57PM +0300
Hi Adrian,
On Mon, Aug 26, 2019 at 08:51:05PM +0800, Leo Yan wrote:
> Hi Adrian,
>
> On Fri, Aug 16, 2019 at 04:00:02PM +0300, Adrian Hunter wrote:
> > On 16/08/19 4:45 AM, Leo Yan wrote:
> > > Hi Adrian,
> > >
> > > On Thu, Aug 15, 2019 at 02:45:57PM +0300, Adrian Hunter wrote:
> > >
> > > [..
Hi Adrian,
On Fri, Aug 16, 2019 at 04:00:02PM +0300, Adrian Hunter wrote:
> On 16/08/19 4:45 AM, Leo Yan wrote:
> > Hi Adrian,
> >
> > On Thu, Aug 15, 2019 at 02:45:57PM +0300, Adrian Hunter wrote:
> >
> > [...]
> >
> How come you cannot use kallsyms to get the information?
> >>>
> >>> Tha
On 7/31/19 6:31 PM, Dario Faggioli wrote:
Hello all,
I know this is a bit of an old thread, so apologies for being late to
the party. :-)
And sorry for the late reply, I was away for a while.
I would have a question about this:
On 7/12/19 2:36 PM, Peter Zijlstra wrote:
On Fri, Jul 12, 2
On 16/08/19 4:45 AM, Leo Yan wrote:
> Hi Adrian,
>
> On Thu, Aug 15, 2019 at 02:45:57PM +0300, Adrian Hunter wrote:
>
> [...]
>
How come you cannot use kallsyms to get the information?
>>>
>>> Thanks for pointing out this. Sorry I skipped your comment "I don't
>>> know how you intend to ca
Hi Adrian,
On Thu, Aug 15, 2019 at 02:45:57PM +0300, Adrian Hunter wrote:
[...]
> >> How come you cannot use kallsyms to get the information?
> >
> > Thanks for pointing out this. Sorry I skipped your comment "I don't
> > know how you intend to calculate ARM_PRE_START_SIZE" when you reviewed
>
4
>>> --- a/tools/perf/util/machine.c
>>> +++ b/tools/perf/util/machine.c
>>> @@ -2687,13 +2687,26 @@ int machine__get_kernel_start(struct machine
>>> *machine)
>>> machine->kernel_start = 1ULL << 63;
>>> if (map) {
>>&g
< 63;
> > if (map) {
> > err = map__load(map);
> > + if (err)
> > + return err;
> > +
> > /*
> > * On x86_64, PTI entry trampolines are less than the
> > * start of kernel text, but still above 2^63. So
ls/perf/util/machine.c
> index f6ee7fbad3e4..e993f891bb82 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -2687,13 +2687,26 @@ int machine__get_kernel_start(struct machine *machine)
> machine->kernel_start = 1ULL << 63;
>
err && !machine__is(machine, "x86_64"))
+ if (!machine__is(machine, "x86_64"))
machine->kernel_start = map->start;
+
+ /*
+* On arm/arm64, the kernel uses some memory regions which are
+* prior to '_s
++ b/tools/perf/arch/arm/util/machine.c
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+#include
+
+#include "../../util/machine.h"
+
+void arch__fix_kernel_text_start(u64 *start)
+{
+ /*
+* On arm, the 16MB virtual memory space prior
This patch set is to improve completeness for kernel address space for
arm/arm64; it adds architecture specific tweaking for the kernel start
address, thus can include the memory regions which are prior to '_stext'
symbol. With this change, we can see the eBPF program can be parsed
p
Hello all,
I know this is a bit of an old thread, so apologies for being late to
the party. :-)
I would have a question about this:
> > > On 7/12/19 2:36 PM, Peter Zijlstra wrote:
> > > > On Fri, Jul 12, 2019 at 02:17:20PM +0200, Alexandre Chartre
> > > > wrote:
> > > > > On 7/12/19 1:44 PM, Pet
On Sun, Jul 14, 2019 at 08:06:12AM -0700, Andy Lutomirski wrote:
> On Fri, Jul 12, 2019 at 12:06 PM Peter Zijlstra wrote:
> >
> > On Fri, Jul 12, 2019 at 06:37:47PM +0200, Alexandre Chartre wrote:
> > > On 7/12/19 5:16 PM, Thomas Gleixner wrote:
> >
> > > > Right. If we decide to expose more parts
Alexandre,
On Mon, 15 Jul 2019, Alexandre Chartre wrote:
> On 7/12/19 9:48 PM, Thomas Gleixner wrote:
> > As I said before, come up with a list of possible usage scenarios and
> > protection scopes first and please take all the ideas other people have
> > with this into account. This includes PTI
On 7/12/19 9:48 PM, Thomas Gleixner wrote:
On Fri, 12 Jul 2019, Alexandre Chartre wrote:
On 7/12/19 5:16 PM, Thomas Gleixner wrote:
On Fri, 12 Jul 2019, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
And then we've fully replaced PTI.
So no, they'r
On 12.07.19 16:36, Andy Lutomirski wrote:
On Fri, Jul 12, 2019 at 6:45 AM Alexandre Chartre
wrote:
On 7/12/19 2:50 PM, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
I think that's precisely what makes ASI and PTI different and independent.
PTI
On Fri, Jul 12, 2019 at 10:45:06AM -0600, Andy Lutomirski wrote:
>
>
> > On Jul 12, 2019, at 10:37 AM, Alexandre Chartre
> > wrote:
> >
> >
> >
> >> On 7/12/19 5:16 PM, Thomas Gleixner wrote:
> >>> On Fri, 12 Jul 2019, Peter Zijlstra wrote:
> On Fri, Jul 12, 2019 at 01:56:44PM +0200, Al
On Fri, Jul 12, 2019 at 12:06 PM Peter Zijlstra wrote:
>
> On Fri, Jul 12, 2019 at 06:37:47PM +0200, Alexandre Chartre wrote:
> > On 7/12/19 5:16 PM, Thomas Gleixner wrote:
>
> > > Right. If we decide to expose more parts of the kernel mappings then
> > > that's
> > > just adding more stuff to th
On Fri, 12 Jul 2019, Alexandre Chartre wrote:
> On 7/12/19 5:16 PM, Thomas Gleixner wrote:
> > On Fri, 12 Jul 2019, Peter Zijlstra wrote:
> > > On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
> > > And then we've fully replaced PTI.
> > >
> > > So no, they're not orthogonal.
> >
On Fri, Jul 12, 2019 at 06:37:47PM +0200, Alexandre Chartre wrote:
> On 7/12/19 5:16 PM, Thomas Gleixner wrote:
> > Right. If we decide to expose more parts of the kernel mappings then that's
> > just adding more stuff to the existing user (PTI) map mechanics.
>
> If we expose more parts of the k
> On Jul 12, 2019, at 10:37 AM, Alexandre Chartre
> wrote:
>
>
>
>> On 7/12/19 5:16 PM, Thomas Gleixner wrote:
>>> On Fri, 12 Jul 2019, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
I think that's precisely what makes ASI and PTI di
On 7/12/19 5:16 PM, Thomas Gleixner wrote:
On Fri, 12 Jul 2019, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
I think that's precisely what makes ASI and PTI different and independent.
PTI is just about switching between userland and kernel page-ta
On Fri, 12 Jul 2019, Alexandre Chartre wrote:
> On 7/12/19 12:44 PM, Thomas Gleixner wrote:
> > That ASI thing is just PTI on steroids.
> >
> > So why do we need two versions of the same thing? That's absolutely bonkers
> > and will just introduce subtle bugs and conflicting decisions all over the
On Fri, 12 Jul 2019, Alexandre Chartre wrote:
> On 7/12/19 3:51 PM, Dave Hansen wrote:
> > BTW, the PTI CR3 writes are not *strictly* about the interrupt coming
> > from user vs. kernel. It's tricky because there's a window both in the
> > entry and exit code where you are in the kernel but have a
On Fri, Jul 12, 2019 at 06:54:22AM -0700, Dave Hansen wrote:
> On 7/12/19 5:50 AM, Peter Zijlstra wrote:
> > PTI is not mapping kernel space to avoid speculation
> > crap (meltdown).
> > ASI is not mapping part of kernel space to avoid (different) speculation
> > crap (MDS).
>
On Fri, 12 Jul 2019, Peter Zijlstra wrote:
> On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
>
> > I think that's precisely what makes ASI and PTI different and independent.
> > PTI is just about switching between userland and kernel page-tables, while
> > ASI is about switching
On Fri, Jul 12, 2019 at 6:45 AM Alexandre Chartre
wrote:
>
>
> On 7/12/19 2:50 PM, Peter Zijlstra wrote:
> > On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
> >
> >> I think that's precisely what makes ASI and PTI different and independent.
> >> PTI is just about switching betwe
interrupt handlers
+ * to figure out if we have entered isolation and switch back to
+ * the kernel address space.
+ */
+ err = ASI_MAP_CPUVAR(asi, cpu_asi_session);
+ if (err)
+ return err;
Also, this stuff seems to do naughty stuff (calling C code, touching
per-cpu data)
On 7/12/19 6:43 AM, Alexandre Chartre wrote:
> The current approach is assuming that anything in the user address space
> can be sensitive, and so the user address space shouldn't be mapped in ASI.
Is this universally true?
There's certainly *some* mitigation provided by SMAP that would allow
use
exposed to speculation attacks. We have to be very
careful about what we map and expose here.
The other (full kernel) address space we are more careful about what we
*do* instead of what we map. We map everything but have to add
mitigations to ensure that we don't leak anything back to
On 7/12/19 3:07 PM, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 02:47:23PM +0200, Alexandre Chartre wrote:
On 7/12/19 2:36 PM, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 02:17:20PM +0200, Alexandre Chartre wrote:
On 7/12/19 1:44 PM, Peter Zijlstra wrote:
AFAIK3 this wants/needs to be
interrupt handlers
> + * to figure out if we have entered isolation and switch back to
> + * the kernel address space.
> + */
> + err = ASI_MAP_CPUVAR(asi, cpu_asi_session);
> + if (err)
> + return err;
>
>
>> Also, this stuff seems to do na
On 7/12/19 2:50 PM, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
I think that's precisely what makes ASI and PTI different and independent.
PTI is just about switching between userland and kernel page-tables, while
ASI is about switching page-table
On Fri, Jul 12, 2019 at 02:47:23PM +0200, Alexandre Chartre wrote:
> On 7/12/19 2:36 PM, Peter Zijlstra wrote:
> > On Fri, Jul 12, 2019 at 02:17:20PM +0200, Alexandre Chartre wrote:
> > > On 7/12/19 1:44 PM, Peter Zijlstra wrote:
> >
> > > > AFAIK3 this wants/needs to be combined with core-schedul
On 7/12/19 2:36 PM, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 02:17:20PM +0200, Alexandre Chartre wrote:
On 7/12/19 1:44 PM, Peter Zijlstra wrote:
AFAIK3 this wants/needs to be combined with core-scheduling to be
useful, but not a single mention of that is anywhere.
No. This is actual
On Fri, Jul 12, 2019 at 01:56:44PM +0200, Alexandre Chartre wrote:
> I think that's precisely what makes ASI and PTI different and independent.
> PTI is just about switching between userland and kernel page-tables, while
> ASI is about switching page-table inside the kernel. You can have ASI witho
On Fri, Jul 12, 2019 at 02:17:20PM +0200, Alexandre Chartre wrote:
> On 7/12/19 1:44 PM, Peter Zijlstra wrote:
> > AFAIK3 this wants/needs to be combined with core-scheduling to be
> > useful, but not a single mention of that is anywhere.
>
> No. This is actually an alternative to core-scheduling
On 7/12/19 1:44 PM, Peter Zijlstra wrote:
On Thu, Jul 11, 2019 at 04:25:12PM +0200, Alexandre Chartre wrote:
Kernel Address Space Isolation aims to use address spaces to isolate some
parts of the kernel (for example KVM) to prevent leaking sensitive data
between hyper-threads under
all over the entry code?
From a semantical perspective VMENTER/VMEXIT are very similar to the return
to user / enter to user mechanics. Just that the transition happens in the
VMM code and not at the regular user/kernel transition points.
VMExit returns to the kernel, and ASI is used to run the
On Thu, Jul 11, 2019 at 04:25:12PM +0200, Alexandre Chartre wrote:
> Kernel Address Space Isolation aims to use address spaces to isolate some
> parts of the kernel (for example KVM) to prevent leaking sensitive data
> between hyper-threads under speculative execution attacks. You can r
On Thu, 11 Jul 2019, Dave Hansen wrote:
> On 7/11/19 7:25 AM, Alexandre Chartre wrote:
> > - Kernel code mapped to the ASI page-table has been reduced to:
> > . the entire kernel (I still need to test with only the kernel text)
> > . the cpu entry area (because we need the GDT to be mapped)
>
atch 15/26):
+ /*
+* Map the percpu ASI sessions. This is used by interrupt handlers
+* to figure out if we have entered isolation and switch back to
+* the kernel address space.
+*/
+ err = ASI_MAP_CPUVAR(asi, cpu_asi_session);
+ if (err)
+ return err;
On 7/11/19 11:33 PM, Thomas Gleixner wrote:
On Thu, 11 Jul 2019, Alexandre Chartre wrote:
+/*
+ * When isolation is active, the address space doesn't necessarily map
+ * the percpu offset value (this_cpu_off) which is used to get pointers
+ * to percpu variables. So functions which can be invo
On 7/11/19 7:25 AM, Alexandre Chartre wrote:
> - Kernel code mapped to the ASI page-table has been reduced to:
> . the entire kernel (I still need to test with only the kernel text)
> . the cpu entry area (because we need the GDT to be mapped)
> . the cpu ASI session (for managing ASI)
> .
On Thu, 11 Jul 2019, Alexandre Chartre wrote:
> +/*
> + * When isolation is active, the address space doesn't necessarily map
> + * the percpu offset value (this_cpu_off) which is used to get pointers
> + * to percpu variables. So functions which can be invoked while isolation
> + * is active shoul
t; RFC. The code
has been completely changed compared to v1 and it now provides a generic
kernel framework which provides Address Space Isolation; and KVM is now
a simple consumer of that framework. That's why the RFC title has been
changed from "KVM Address Space Isolation" to "
as been
changed from "KVM Address Space Isolation" to "Kernel Address Space
Isolation".
Kernel Address Space Isolation aims to use address spaces to isolate some
parts of the kernel (for example KVM) to prevent leaking sensitive data
between hyper-threads under speculative exec
Introduce core functions and structures for implementing Address Space
Isolation (ASI). Kernel address space isolation provides the ability to
run some kernel code with a reduced kernel address space.
An address space isolation is defined with a struct asi structure which
has its own page-table
1 - 100 of 430 matches
Mail list logo
