lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-Id: <20171227164614.835029879@linuxfoundation.org> Date: Wed, 27 Dec 2017 17:45:51 +0100 From: Greg Kroah-Hartman <gregkh@...uxfoundation.org> To: linux-kernel@...r.kernel.org Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, stable@...r.kernel.org, "Peter Zijlstra (Intel)" <peterz@...radead.org>, Thomas Gleixner <tglx@...utronix.de>, Andy Lutomirski <luto@...nel.org>, Boris Ostrovsky <boris.ostrovsky@...cle.com>, Borislav Petkov <bp@...en8.de>, Brian Gerst <brgerst@...il.com>, Dave Hansen <dave.hansen@...ux.intel.com>, David Laight <David.Laight@...lab.com>, Denys Vlasenko <dvlasenk@...hat.com>, Eduardo Valentin <eduval@...zon.com>, "H. Peter Anvin" <hpa@...or.com>, Josh Poimboeuf <jpoimboe@...hat.com>, Juergen Gross <jgross@...e.com>, Linus Torvalds <torvalds@...ux-foundation.org>, Will Deacon <will.deacon@....com>, aliguori@...zon.com, daniel.gruss@...k.tugraz.at, hughd@...gle.com, keescook@...gle.com, linux-mm@...ck.org, Ingo Molnar <mingo@...nel.org> Subject: [PATCH 4.14 18/74] x86/doc: Remove obvious weirdnesses from the x86 MM layout documentation 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Peter Zijlstra <peterz@...radead.org> commit e8ffe96e5933d417195268478479933d56213a3f upstream. Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org> Signed-off-by: Thomas Gleixner <tglx@...utronix.de> Cc: Andy Lutomirski <luto@...nel.org> Cc: Boris Ostrovsky <boris.ostrovsky@...cle.com> Cc: Borislav Petkov <bp@...en8.de> Cc: Brian Gerst <brgerst@...il.com> Cc: Dave Hansen <dave.hansen@...ux.intel.com> Cc: David Laight <David.Laight@...lab.com> Cc: Denys Vlasenko <dvlasenk@...hat.com> Cc: Eduardo Valentin <eduval@...zon.com> Cc: Greg KH <gregkh@...uxfoundation.org> Cc: H. Peter Anvin <hpa@...or.com> Cc: Josh Poimboeuf <jpoimboe@...hat.com> Cc: Juergen Gross <jgross@...e.com> Cc: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Peter Zijlstra <peterz@...radead.org> Cc: Will Deacon <will.deacon@....com> Cc: aliguori@...zon.com Cc: daniel.gruss@...k.tugraz.at Cc: hughd@...gle.com Cc: keescook@...gle.com Cc: linux-mm@...ck.org Signed-off-by: Ingo Molnar <mingo@...nel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org> --- Documentation/x86/x86_64/mm.txt | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) --- a/Documentation/x86/x86_64/mm.txt +++ b/Documentation/x86/x86_64/mm.txt @@ -1,6 +1,4 @@ -<previous description obsolete, deleted> - Virtual memory map with 4 level page tables: 0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm @@ -49,8 +47,9 @@ ffffffffffe00000 - ffffffffffffffff (=2 Architecture defines a 64-bit virtual address. Implementations can support less. Currently supported are 48- and 57-bit virtual addresses. Bits 63 -through to the most-significant implemented bit are set to either all ones -or all zero. This causes hole between user space and kernel addresses. +through to the most-significant implemented bit are sign extended. +This causes hole between user space and kernel addresses if you interpret them +as unsigned. The direct mapping covers all memory in the system up to the highest memory address (this means in some cases it can also include PCI memory @@ -60,9 +59,6 @@ vmalloc space is lazily synchronized int the processes using the page fault handler, with init_top_pgt as reference. -Current X86-64 implementations support up to 46 bits of address space (64 TB), -which is our current limit. This expands into MBZ space in the page tables. - We map EFI runtime services in the 'efi_pgd' PGD in a 64Gb large virtual memory window (this size is arbitrary, it can be raised later if needed). The mappings are not part of any other kernel PGD and are only available @@ -74,5 +70,3 @@ following fixmap section. Note that if CONFIG_RANDOMIZE_MEMORY is enabled, the direct mapping of all physical memory, vmalloc/ioremap space and virtual memory map are randomized. Their order is preserved but their base will be offset early at boot time. - --Andi Kleen, Jul 2004
Powered by blists - more mailing lists