From: Daniel Axtens <dja@axtens.net>
To: Jordan Niethe <jniethe5@gmail.com>
Cc: aneesh.kumar@linux.ibm.com, linux-kernel@vger.kernel.org,
kasan-dev@googlegroups.com, linux-mm@kvack.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v3 3/3] powerpc: Book3S 64-bit "heavyweight" KASAN support
Date: Wed, 18 Dec 2019 18:01:34 +1100 [thread overview]
Message-ID: <87y2vat8vl.fsf@dja-thinkpad.axtens.net> (raw)
In-Reply-To: <CACzsE9q1iLgoMLzVy0AYeRvWbj=kY-Ry52y84PGtWw3YXXFipA@mail.gmail.com>
>> [For those not immersed in ppc64, in real mode, the top nibble or 2 bits
>> (depending on radix/hash mmu) of the address is ignored. The linear
>> mapping is placed at 0xc000000000000000. This means that a pointer to
>> part of the linear mapping will work both in real mode, where it will be
>> interpreted as a physical address of the form 0x000..., and out of real
>> mode, where it will go via the linear mapping.]
>>
>
> How does hash or radix mmu mode effect how many bits are ignored in real mode?
Bah, you're picking on details that I picked up from random
conversations in the office rather than from reading the spec! :P
The ISA suggests that real addresses space is limited to at most 64
bits. ISAv3, Book III s5.7:
| * Host real address space size is 2^m bytes, m <= 60;
| see Note 1.
| * Guest real address space size is 2 m bytes, m <= 60;
| see Notes 1 and 2.
...
| Notes:
| 1. The value of m is implementation-dependent (sub-
| ject to the maximum given above). When used to
| address storage or to represent a guest real
| address, the high-order 60-m bits of the “60-bit”
| real address must be zeros.
| 2. The hypervisor may assign a guest real address
| space size for each partition that uses Radix Tree
| translation. Accesses to guest real storage out-
| side this range but still mappable by the second
| level Radix Tree will cause an HISI or HDSI.
| Accesses to storage outside the mappable range
| will have boundedly undefined results.
However, it doesn't follow from that passage that the top 4 bits are
always ignored when translations are off ('real mode'): see for example
the discussion of the HRMOR in s 5.7.3 and s 5.7.3.1.
I think I got the 'top 2 bits on radix' thing from the discussion of
'quadrants' in arch/powerpc/include/asm/book3s/64/radix.h, which in turn
is discussed in s 5.7.5.1. Table 20 in particular is really helpful for
understanding it. But it's not especially relevant to what I'm actually
doing here.
I think to fully understand all of what's going on I would need to spend
some serious time with the entirety of s5.7, because there a lot of
quirks about how storage works! But I think for our purposes it suffices
to say:
The kernel installs a linear mapping at effective address
c000... onward. This is a one-to-one mapping with physical memory from
0000... onward. Because of how memory accesses work on powerpc 64-bit
Book3S, a kernel pointer in the linear map accesses the same memory
both with translations on (accessing as an 'effective address'), and
with translations off (accessing as a 'real address'). This works in
both guests and the hypervisor. For more details, see s5.7 of Book III
of version 3 of the ISA, in particular the Storage Control Overview,
s5.7.3, and s5.7.5 - noting that this KASAN implementation currently
only supports Radix.
Thanks for your attention to detail!
Regards,
Daniel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Axtens <dja@axtens.net>
To: Jordan Niethe <jniethe5@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linuxppc-dev@lists.ozlabs.org, kasan-dev@googlegroups.com,
christophe.leroy@c-s.fr, aneesh.kumar@linux.ibm.com,
bsingharora@gmail.com, Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [PATCH v3 3/3] powerpc: Book3S 64-bit "heavyweight" KASAN support
Date: Wed, 18 Dec 2019 18:01:34 +1100 [thread overview]
Message-ID: <87y2vat8vl.fsf@dja-thinkpad.axtens.net> (raw)
In-Reply-To: <CACzsE9q1iLgoMLzVy0AYeRvWbj=kY-Ry52y84PGtWw3YXXFipA@mail.gmail.com>
>> [For those not immersed in ppc64, in real mode, the top nibble or 2 bits
>> (depending on radix/hash mmu) of the address is ignored. The linear
>> mapping is placed at 0xc000000000000000. This means that a pointer to
>> part of the linear mapping will work both in real mode, where it will be
>> interpreted as a physical address of the form 0x000..., and out of real
>> mode, where it will go via the linear mapping.]
>>
>
> How does hash or radix mmu mode effect how many bits are ignored in real mode?
Bah, you're picking on details that I picked up from random
conversations in the office rather than from reading the spec! :P
The ISA suggests that real addresses space is limited to at most 64
bits. ISAv3, Book III s5.7:
| * Host real address space size is 2^m bytes, m <= 60;
| see Note 1.
| * Guest real address space size is 2 m bytes, m <= 60;
| see Notes 1 and 2.
...
| Notes:
| 1. The value of m is implementation-dependent (sub-
| ject to the maximum given above). When used to
| address storage or to represent a guest real
| address, the high-order 60-m bits of the “60-bit”
| real address must be zeros.
| 2. The hypervisor may assign a guest real address
| space size for each partition that uses Radix Tree
| translation. Accesses to guest real storage out-
| side this range but still mappable by the second
| level Radix Tree will cause an HISI or HDSI.
| Accesses to storage outside the mappable range
| will have boundedly undefined results.
However, it doesn't follow from that passage that the top 4 bits are
always ignored when translations are off ('real mode'): see for example
the discussion of the HRMOR in s 5.7.3 and s 5.7.3.1.
I think I got the 'top 2 bits on radix' thing from the discussion of
'quadrants' in arch/powerpc/include/asm/book3s/64/radix.h, which in turn
is discussed in s 5.7.5.1. Table 20 in particular is really helpful for
understanding it. But it's not especially relevant to what I'm actually
doing here.
I think to fully understand all of what's going on I would need to spend
some serious time with the entirety of s5.7, because there a lot of
quirks about how storage works! But I think for our purposes it suffices
to say:
The kernel installs a linear mapping at effective address
c000... onward. This is a one-to-one mapping with physical memory from
0000... onward. Because of how memory accesses work on powerpc 64-bit
Book3S, a kernel pointer in the linear map accesses the same memory
both with translations on (accessing as an 'effective address'), and
with translations off (accessing as a 'real address'). This works in
both guests and the hypervisor. For more details, see s5.7 of Book III
of version 3 of the ISA, in particular the Storage Control Overview,
s5.7.3, and s5.7.5 - noting that this KASAN implementation currently
only supports Radix.
Thanks for your attention to detail!
Regards,
Daniel
next prev parent reply other threads:[~2019-12-18 7:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-12 15:16 [PATCH v3 0/3] KASAN for powerpc64 radix Daniel Axtens
2019-12-12 15:16 ` [PATCH v3 1/3] kasan: define and use MAX_PTRS_PER_* for early shadow tables Daniel Axtens
2019-12-12 15:55 ` Christophe Leroy
2019-12-13 21:37 ` Balbir Singh
2019-12-12 15:16 ` [PATCH v3 2/3] kasan: Document support on 32-bit powerpc Daniel Axtens
2019-12-12 15:16 ` [PATCH v3 3/3] powerpc: Book3S 64-bit "heavyweight" KASAN support Daniel Axtens
2019-12-12 15:16 ` Daniel Axtens
2019-12-12 23:55 ` Jordan Niethe
2019-12-12 23:55 ` Jordan Niethe
2019-12-18 7:01 ` Daniel Axtens [this message]
2019-12-18 7:01 ` Daniel Axtens
2019-12-13 12:27 ` Christophe Leroy
2019-12-13 12:27 ` Christophe Leroy
2019-12-17 13:30 ` Daniel Axtens
2019-12-17 13:30 ` Daniel Axtens
2019-12-18 4:32 ` Daniel Axtens
2019-12-18 4:32 ` Daniel Axtens
2019-12-18 13:39 ` Christophe Leroy
2019-12-18 13:39 ` Christophe Leroy
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=87y2vat8vl.fsf@dja-thinkpad.axtens.net \
--to=dja@axtens.net \
--cc=aneesh.kumar@linux.ibm.com \
--cc=jniethe5@gmail.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.