linux-kernel - Re: [RFC] mm: Allow 64-bit mmap syscalls to access higher addresses.

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20200925165343.292885-1-dlesho@codeweavers.com>
Date:   Fri, 25 Sep 2020 11:53:44 -0500
From:   Derek Lesho <dlesho@...eweavers.com>
To:     linux-kernel@...r.kernel.org
Cc:     Derek Lesho <dlesho@...eweavers.com>
Subject: Re: [RFC] mm: Allow 64-bit mmap syscalls to access higher addresses.

For some reason, git send-email cut off the first paragprah in my first email, so I'm resending it now:

Hello everyone, I am sending this mostly as a discussion starter/curiosity.  I would like to be able to use the 48-bit address range while in long mode on an IA32 process.  However,
these two checks prevent mmap and munmap from dealing with addresses in that range.  My question, is there any will to support something like this in the kernel, and if so, how
would it be accomplished, generally.  Maybe the TASK_SIZE macro could check for whether we are currently in the context of a x86-64 syscall?

For those curious about my usecase, I'm working on running some windows 64-bit driver code in context of any given process.  I accomplish this by mapping some of the fake kernel
bits in the target process, and running the code in a dedicated thread.
---