2015-08-17 12:50 GMT+03:00 Aneesh Kumar K.V :
> Because of the above I concluded that we may not be able to do
> inline instrumentation. Now if we are not doing inline instrumentation,
> we can simplify kasan support by not creating a shadow mapping at all
> for vmalloc and vmemmap region. Hence th
On 08/17/2015 09:36 AM, Aneesh Kumar K.V wrote:
> We can't use generic functions like print_hex_dump to access kasan
> shadow region. This require us to setup another kasan shadow region
> for the address passed (kasan shadow address). Most architecture won't
> be able to do that. Hence remove dump
On 08/17/2015 09:36 AM, Aneesh Kumar K.V wrote:
> We use the region with region ID 0xe as the kasan shadow region. Since
> we use hash page table, we can't have the early zero page based shadow
> region support. Hence we disable kasan in the early code and runtime
> enable this. We could imporve th
2015-08-17 15:13 GMT+03:00 Andrey Ryabinin :
>
> Did you disable stack instrumentation (in scripts/Makefile.kasa),
> or you version of gcc doesn't support it (e.g. like 4.9.x on x86) ?
>
> Because this can't work with stack instrumentation as you don't have sha
2015-08-18 8:36 GMT+03:00 Aneesh Kumar K.V :
> Andrey Ryabinin writes:
>
>> 2015-08-17 15:13 GMT+03:00 Andrey Ryabinin :
>>>
>>> Did you disable stack instrumentation (in scripts/Makefile.kasa),
>>> or you version of gcc doesn't support it (e.g. lik
2015-08-18 8:42 GMT+03:00 Aneesh Kumar K.V :
> Andrey Ryabinin writes:
>
>> 2015-08-17 12:50 GMT+03:00 Aneesh Kumar K.V
>> :
>>> Because of the above I concluded that we may not be able to do
>>> inline instrumentation. Now if we are not doing inline instru
2015-08-18 8:29 GMT+03:00 Aneesh Kumar K.V :
> Andrey Ryabinin writes:
>
>> On 08/17/2015 09:36 AM, Aneesh Kumar K.V wrote:
>>> We can't use generic functions like print_hex_dump to access kasan
>>> shadow region. This require us to setup another kasan shado
2015-08-18 12:21 GMT+03:00 Aneesh Kumar K.V :
> Andrey Ryabinin writes:
>
>> 2015-08-18 8:42 GMT+03:00 Aneesh Kumar K.V :
>>> Andrey Ryabinin writes:
>>>
>>>
>>> But that is introducting conditionals in core code for no real benefit.
>>>
2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V :
> Hi,
>
> This patchset implements kernel address sanitizer for ppc64.
> Since ppc64 virtual address range is divided into different regions,
> we can't have one contigous area for the kasan shadow range. Hence
> we don't support the INLINE kasan instru
2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V :
> Conditionalize the check using #ifdef
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> mm/kasan/report.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index e07c94fbd0ac..71ce
2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V :
> The function only disable/enable reporting. In the later patch
> we will be adding a kasan early enable/disable. Rename kasan_enabled
> to properly reflect its function.
>
> Signed-off-by: Aneesh Kumar K.V
Reviewed-by:
2015-08-26 11:54 GMT+03:00 Aneesh Kumar K.V :
>
> Missed to cherry-pick the updated version of this patch, before sending
> the series out.
>
> commit aeb324e09d95c189eda4ce03790da94b535d1dfc
> Author: Aneesh Kumar K.V
> Date: Fri Aug 14 12:28:58 2015 +0530
>
> kasan: Don't use kasan shadow
2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V :
> We add enable/disable callbacks in this patch which architecture
> can implemement. We will use this in the later patches for architecture
> like ppc64, that cannot have early zero page kasan shadow region for the
> entire virtual address space. Such
2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V :
> Some archs may want to provide kasan shadow memory as a constant
> offset from the address. Such arch even though cannot use inline kasan
> support, they can work with outofline kasan support.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> include/linu
2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V :
> Some of the archs, may find it difficult to support inline KASan
> mode. Add HAVE_ARCH_KASAN_INLINE so that we can disable inline
> support at config time.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/x86/Kconfig | 1 +
> lib/Kconfig.kasa
2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V :
> We we end up calling kasan_report in real mode, our shadow mapping
> for even spinlock variable will show poisoned.
Generally I agree with this patch. We should disable reports when we
print report as early
as possible to prevent recursion in case of
2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V :
> + k_start = (unsigned long)kasan_mem_to_shadow(start);
> + k_end = (unsigned long)kasan_mem_to_shadow(end);
> + for (; k_start < k_end; k_start += page_size) {
> + p = vmemmap_alloc_block
On 2/27/19 11:25 AM, Christophe Leroy wrote:
> With version v8 of the series implementing KASAN on 32 bits powerpc
> (https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=94309), I'm
> now able to activate KASAN on a mac99 is QEMU.
>
> Then I get the following reports at startup. Wh
On 2/27/19 4:11 PM, Christophe Leroy wrote:
>
>
> Le 27/02/2019 à 10:19, Andrey Ryabinin a écrit :
>>
>>
>> On 2/27/19 11:25 AM, Christophe Leroy wrote:
>>> With version v8 of the series implementing KASAN on 32 bits powerpc
>>> (https://patchwork
On 2/28/19 12:27 PM, Dmitry Vyukov wrote:
> On Thu, Feb 28, 2019 at 10:22 AM Andrey Ryabinin
> wrote:
>>
>>
>>
>> On 2/27/19 4:11 PM, Christophe Leroy wrote:
>>>
>>>
>>> Le 27/02/2019 à 10:19, Andrey Ryabinin a écrit :
>>>&
On 4/2/19 12:43 PM, Christophe Leroy wrote:
> Hi Dmitry, Andrey and others,
>
> Do you have any comments to this series ?
>
I don't see justification for adding all these non-instrumented functions. We
need only some subset of these functions
and only on powerpc so far. Arches that don't use
ark Rutland
> Signed-off-by: Mark Rutland [shadow rework]
> Signed-off-by: Daniel Axtens
Small nit bellow, otherwise looks fine:
Reviewed-by: Andrey Ryabinin
> static __always_inline bool
> @@ -1196,8 +1201,8 @@ static void free_vmap_area(struct vmap_area *va)
>
On 10/29/19 7:20 AM, Daniel Axtens wrote:
> Test kasan vmalloc support by adding a new test to the module.
>
> Signed-off-by: Daniel Axtens
>
Reviewed-by: Andrey Ryabinin
v
> Signed-off-by: Daniel Axtens
> ---
Reviewed-by: Andrey Ryabinin
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 954e875e72b1..a6e5249ad74b 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -94,6 +94,7 @@
> #include
> #include
> #include
>
r the corresponding shadow (yet),
we only install pgd/p4d.
I guess we could just use NUMA_NO_NODE.
The rest looks ok, so with that fixed:
Reviewed-by: Andrey Ryabinin
On 10/29/19 7:20 AM, Daniel Axtens wrote:
> Provide the current number of vmalloc shadow pages in
> /sys/kernel/debug/kasan/vmalloc_shadow_pages.
>
I wouldn't merge this. I don't see use-case for this, besides
testing this patch set. And I think that number should be possible to
extract via page_
On 10/30/19 4:50 PM, Daniel Axtens wrote:
> Andrey Ryabinin writes:
>
>> On 10/29/19 7:20 AM, Daniel Axtens wrote:
>>> In the case where KASAN directly allocates memory to back vmalloc
>>> space, don't map the early shadow page over it.
>>>
>
On 10/31/19 12:39 PM, Daniel Axtens wrote:
> Daniel Axtens (4):
> kasan: support backing vmalloc space with real shadow memory
> kasan: add test for vmalloc
> fork: support VMAP_STACK with KASAN_VMALLOC
> x86/kasan: support KASAN_VMALLOC
>
> Documentation/dev-tools/kasan.rst | 63
On 11/18/19 6:29 AM, Daniel Axtens wrote:
> Qian Cai writes:
>
>> On Thu, 2019-10-31 at 20:39 +1100, Daniel Axtens wrote:
>>> /*
>>> * In this function, newly allocated vm_struct has VM_UNINITIALIZED
>>> * flag. It means that vm_struct is not fully initialized.
>>> @@ -3377,6 +34
On 11/29/19 2:02 PM, Dmitry Vyukov wrote:
> On Fri, Nov 29, 2019 at 11:58 AM Dmitry Vyukov wrote:
>>
>> On Fri, Nov 29, 2019 at 11:43 AM Dmitry Vyukov wrote:
>>>
>>> On Tue, Nov 19, 2019 at 10:54 AM Andrey Ryabinin
>>> wrote:
>>>> On
On 11/29/19 2:47 PM, Dmitry Vyukov wrote:
> On Fri, Nov 29, 2019 at 12:38 PM Andrey Ryabinin
> wrote:
>>>>>
>>>>>
>>>>> Not sure if it's the same or not. Is it addressed by something in flight?
>>>>
On 11/01/2018 07:32 PM, Peter Zijlstra wrote:
> On Thu, Nov 01, 2018 at 03:22:15PM +, Trond Myklebust wrote:
>> On Thu, 2018-11-01 at 15:59 +0100, Peter Zijlstra wrote:
>>> On Thu, Nov 01, 2018 at 01:18:46PM +, Mark Rutland wrote:
>
> My one question (and the reason why I went with
On 1/12/19 2:16 PM, Christophe Leroy wrote:
> +KASAN_SANITIZE_early_32.o := n
> +KASAN_SANITIZE_cputable.o := n
> +KASAN_SANITIZE_prom_init.o := n
> +
Usually it's also good idea to disable branch profiling - define
DISABLE_BRANCH_PROFILING
either in top of these files or via Makefile. Branch
On 1/15/19 2:14 PM, Dmitry Vyukov wrote:
> On Tue, Jan 15, 2019 at 8:27 AM Christophe Leroy
> wrote:
>> On 01/14/2019 09:34 AM, Dmitry Vyukov wrote:
>>> On Sat, Jan 12, 2019 at 12:16 PM Christophe Leroy
>>> wrote:
>>> >
>>> > In kernel/cputable.c, explicitly use memcpy() in order
>>> > to allo
On 2/11/19 3:25 PM, Andrey Konovalov wrote:
> On Sat, Feb 9, 2019 at 12:55 PM christophe leroy
> wrote:
>>
>> Hi Andrey,
>>
>> Le 08/02/2019 à 18:40, Andrey Konovalov a écrit :
>>> On Fri, Feb 8, 2019 at 6:17 PM Christophe Leroy
>>> wrote:
Hi Daniel,
Le 08/02/2019 à 17:18,
On 2/12/19 4:08 AM, Daniel Axtens wrote:
> Andrey Ryabinin writes:
>
>> On 2/11/19 3:25 PM, Andrey Konovalov wrote:
>>> On Sat, Feb 9, 2019 at 12:55 PM christophe leroy
>>> wrote:
>>>>
>>>> Hi Andrey,
>>>>
>>>> Le
On 2/12/19 2:38 PM, Christophe Leroy wrote:
>
>
> Le 12/02/2019 à 02:08, Daniel Axtens a écrit :
>> Andrey Ryabinin writes:
>>
>>>
>>> Christophe, you can specify KASAN_SHADOW_OFFSET either in Kconfig (e.g.
>>> x86_64) or
>>> in Makefi
On 2/15/19 11:41 AM, Christophe Leroy wrote:
>
>
> Le 14/02/2019 à 23:04, Daniel Axtens a écrit :
>> Hi Christophe,
>>
>>> --- a/arch/powerpc/include/asm/string.h
>>> +++ b/arch/powerpc/include/asm/string.h
>>> @@ -27,6 +27,20 @@ extern int memcmp(const void *,const void
>>> *,__kernel_size_t
On 2/15/19 1:10 PM, Christophe Leroy wrote:
>
>
> Le 15/02/2019 à 11:01, Andrey Ryabinin a écrit :
>>
>>
>> On 2/15/19 11:41 AM, Christophe Leroy wrote:
>>>
>>>
>>> Le 14/02/2019 à 23:04, Daniel Axtens a écrit :
>>>>
On 12/11/19 5:24 PM, Daniel Axtens wrote:
> Hi Balbir,
>
> +Discontiguous memory can occur when you have a machine with memory spread
> +across multiple nodes. For example, on a Talos II with 64GB of RAM:
> +
> + - 32GB runs from 0x0 to 0x_0008__,
> + - then there's
On 10/1/19 9:58 AM, Daniel Axtens wrote:
> core_initcall(kasan_memhotplug_init);
> #endif
> +
> +#ifdef CONFIG_KASAN_VMALLOC
> +static int kasan_populate_vmalloc_pte(pte_t *ptep, unsigned long addr,
> + void *unused)
> +{
> + unsigned long page;
> +
On 10/14/19 4:57 PM, Daniel Axtens wrote:
> Hi Andrey,
>
>
>>> + /*
>>> +* Ensure poisoning is visible before the shadow is made visible
>>> +* to other CPUs.
>>> +*/
>>> + smp_wmb();
>>
>> I'm not quite understand what this barrier do and why it needed.
>> And if it's really ne
On 10/16/19 4:22 PM, Mark Rutland wrote:
> Hi Andrey,
>
> On Wed, Oct 16, 2019 at 03:19:50PM +0300, Andrey Ryabinin wrote:
>> On 10/14/19 4:57 PM, Daniel Axtens wrote:
>>>>> + /*
>>>>> + * Ensure poisoning is visible before the sh
On 10/18/2017 08:14 PM, Pavel Tatashin wrote:
> Thank you Andrey, I will test this patch. Should it go on top or replace the
> existing patch in mm-tree? ARM and x86 should be done the same either both as
> follow-ups or both replace.
>
It's a replacement of your patch.
> Pavel
>
> --
> To
2017-01-16 15:53 GMT+03:00 Peter Zijlstra :
> On Mon, Jan 16, 2017 at 10:42:29PM +1100, Anton Blanchard wrote:
>> Hi Peter,
>>
>> > Last I checked I couldn't build a x86_64 kernel with llvm. So no, not
>> > something I've ever ran into.
>> >
>> > Also, I would argue that this is broken in llvm, the
On 07/29/2017 05:09 PM, Balbir Singh wrote:
> This is the first attempt to implement KASAN for radix
> on powerpc64. Aneesh Kumar implemented KASAN for hash 64
> in limited mode (support only for kernel linear mapping)
> (https://lwn.net/Articles/655642/)
>
> This patch does the following:
> 1. De
46 matches
Mail list logo
