From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
paulus@samba.org, mpe@ellerman.id.au
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH V1 4/8] kasan: Don't use kasan shadow pointer in generic functions
Date: Tue, 18 Aug 2015 10:59:21 +0530 [thread overview]
Message-ID: <87egj1p3ke.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAPAsAGxs8NhxJ22DXOgcbBkuALzd0zd7WL+SCGeNmsWCrMi3nA@mail.gmail.com>
Andrey Ryabinin <ryabinin.a.a@gmail.com> 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 shadow region
>> for the address passed (kasan shadow address). Most architecture won't
>> be able to do that. Hence remove dumping kasan shadow region dump. If
>> we really want to do this we will have to have a kasan internal implemen
>> tation of print_hex_dump for which we will disable address sanitizer
>> operation.
>>
>
> I didn't understand that.
> Yes, you don't have shadow for shadow. But, for shadow addresses you
> return return (void *)kasan_zero_page in kasan_mem_to_shadow(), so we
> should be fine to access shadow in generic code.
>
But in general IMHO it is not correct to pass shadow address to generic
functions, because that requires arch to setup shadow for the shadow.
With one of the initial implementation of ppc64 support, I had page
table entries setup for vmalloc and vmemmap shadow and that is when I
hit the issue. We cannot expect arch to setup shadow regions like what is
expected here. If we really need to print the shadow memory content, we
could possibly make a copy of print_hex_dump in kasan_init.c . Let me
know whether you think printing shadow area content is needed.
-aneesh
next prev parent reply other threads:[~2015-08-18 5:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-17 6:36 [RFC PATCH V1 0/8] KASAN ppc64 support Aneesh Kumar K.V
2015-08-17 6:36 ` [RFC PATCH V1 1/8] powerpc/mm: Add virt_to_pfn and use this instead of opencoding Aneesh Kumar K.V
2015-08-17 6:36 ` [RFC PATCH V1 2/8] kasan: MODULE_VADDR is not available on all archs Aneesh Kumar K.V
2015-08-17 6:36 ` [RFC PATCH V1 3/8] kasan: Rename kasan_enabled to kasan_report_enabled Aneesh Kumar K.V
2015-08-17 6:36 ` [RFC PATCH V1 4/8] kasan: Don't use kasan shadow pointer in generic functions Aneesh Kumar K.V
2015-08-17 11:36 ` Andrey Ryabinin
2015-08-18 5:29 ` Aneesh Kumar K.V [this message]
2015-08-18 9:12 ` Andrey Ryabinin
2015-08-17 6:36 ` [RFC PATCH V1 5/8] kasan: Enable arch to hook into kasan callbacks Aneesh Kumar K.V
2015-08-17 6:36 ` [RFC PATCH V1 6/8] kasan: Allow arch to overrride kasan shadow offsets Aneesh Kumar K.V
2015-08-17 6:36 ` [RFC PATCH V1 7/8] powerpc/mm: kasan: Add kasan support for ppc64 Aneesh Kumar K.V
2015-08-17 12:13 ` Andrey Ryabinin
2015-08-17 12:17 ` Andrey Ryabinin
2015-08-18 5:36 ` Aneesh Kumar K.V
2015-08-18 8:40 ` Andrey Ryabinin
2015-08-18 5:34 ` Aneesh Kumar K.V
2015-08-17 6:36 ` [RFC PATCH V1 8/8] powerpc: Disable kasan for kernel/ and mm/ directory Aneesh Kumar K.V
2015-08-17 6:54 ` [RFC PATCH V1 0/8] KASAN ppc64 support Benjamin Herrenschmidt
2015-08-17 9:50 ` Aneesh Kumar K.V
2015-08-17 10:01 ` Benjamin Herrenschmidt
2015-08-17 10:50 ` Aneesh Kumar K.V
2015-08-17 11:21 ` Benjamin Herrenschmidt
2015-08-17 11:29 ` Andrey Ryabinin
2015-08-18 5:42 ` Aneesh Kumar K.V
2015-08-18 8:50 ` Andrey Ryabinin
2015-08-18 9:21 ` Aneesh Kumar K.V
2015-08-18 9:30 ` Andrey Ryabinin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87egj1p3ke.fsf@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=ryabinin.a.a@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).