Hi
On Sat, Apr 12, 2014 at 12:07 AM, Andy Lutomirski wrote:
> I bet this is missing from lots of places. For example, I can't find
> any write_access stuff in the rdma code.
>
> I suspect that the VM_DENYWRITE code is just generally racy.
So what does S_IMMUTABLE do to prevent such races? I
Hi
On Sat, Apr 12, 2014 at 12:07 AM, Andy Lutomirski l...@amacapital.net wrote:
I bet this is missing from lots of places. For example, I can't find
any write_access stuff in the rdma code.
I suspect that the VM_DENYWRITE code is just generally racy.
So what does S_IMMUTABLE do to prevent
On Fri, Apr 11, 2014 at 2:42 PM, David Herrmann wrote:
> Hi
>
> On Fri, Apr 11, 2014 at 11:36 PM, Andy Lutomirski wrote:
>> A quick grep of the kernel tree finds exactly zero code paths
>> incrementing i_mmap_writable outside of mmap and fork.
>>
>> Or do you mean a different kind of write ref?
Hi
On Fri, Apr 11, 2014 at 11:36 PM, Andy Lutomirski wrote:
> A quick grep of the kernel tree finds exactly zero code paths
> incrementing i_mmap_writable outside of mmap and fork.
>
> Or do you mean a different kind of write ref? What am I missing here?
Sorry, I meant i_writecount.
Thanks
On 04/11/2014 02:31 PM, David Herrmann wrote:
> Hi
>
> On Fri, Apr 11, 2014 at 3:43 PM, Tony Battersby wrote:
>> Exactly. For O_DIRECT, that would be the call to get_user_pages_fast()
>> from dio_refill_pages() in fs/direct-io.c, which is ultimately called
>> from blkdev_direct_IO().
>
> If
Hi
On Fri, Apr 11, 2014 at 3:43 PM, Tony Battersby wrote:
> Exactly. For O_DIRECT, that would be the call to get_user_pages_fast()
> from dio_refill_pages() in fs/direct-io.c, which is ultimately called
> from blkdev_direct_IO().
If you drop mmap_sem after pinning a page without taking a
Andy Lutomirski wrote:
> On 04/10/2014 05:22 PM, David Herrmann wrote:
>
>> Hi
>>
>> On Thu, Apr 10, 2014 at 11:33 PM, Tony Battersby
>> wrote:
>>
>>> For O_DIRECT the kernel pins the submitted pages in memory for DMA by
>>> incrementing the page reference counts when the I/O is
Andy Lutomirski wrote:
On 04/10/2014 05:22 PM, David Herrmann wrote:
Hi
On Thu, Apr 10, 2014 at 11:33 PM, Tony Battersby to...@cybernetics.com
wrote:
For O_DIRECT the kernel pins the submitted pages in memory for DMA by
incrementing the page reference counts when the I/O is
Hi
On Fri, Apr 11, 2014 at 3:43 PM, Tony Battersby to...@cybernetics.com wrote:
Exactly. For O_DIRECT, that would be the call to get_user_pages_fast()
from dio_refill_pages() in fs/direct-io.c, which is ultimately called
from blkdev_direct_IO().
If you drop mmap_sem after pinning a page
On 04/11/2014 02:31 PM, David Herrmann wrote:
Hi
On Fri, Apr 11, 2014 at 3:43 PM, Tony Battersby to...@cybernetics.com wrote:
Exactly. For O_DIRECT, that would be the call to get_user_pages_fast()
from dio_refill_pages() in fs/direct-io.c, which is ultimately called
from
Hi
On Fri, Apr 11, 2014 at 11:36 PM, Andy Lutomirski l...@amacapital.net wrote:
A quick grep of the kernel tree finds exactly zero code paths
incrementing i_mmap_writable outside of mmap and fork.
Or do you mean a different kind of write ref? What am I missing here?
Sorry, I meant
On Fri, Apr 11, 2014 at 2:42 PM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Fri, Apr 11, 2014 at 11:36 PM, Andy Lutomirski l...@amacapital.net wrote:
A quick grep of the kernel tree finds exactly zero code paths
incrementing i_mmap_writable outside of mmap and fork.
Or do you mean a
On 04/10/2014 05:22 PM, David Herrmann wrote:
> Hi
>
> On Thu, Apr 10, 2014 at 11:33 PM, Tony Battersby
> wrote:
>> For O_DIRECT the kernel pins the submitted pages in memory for DMA by
>> incrementing the page reference counts when the I/O is submitted,
>> allowing the pages to be modified by
Hi
On Thu, Apr 10, 2014 at 11:33 PM, Tony Battersby wrote:
> For O_DIRECT the kernel pins the submitted pages in memory for DMA by
> incrementing the page reference counts when the I/O is submitted,
> allowing the pages to be modified by DMA even if they are no longer
> mapped in the address
(reposted from my comments at http://lwn.net/Articles/593918/)
I may have thought of a way to subvert SEAL_WRITE using O_DIRECT and
asynchronous I/O. I am not sure if this is a real problem or not, but
better to ask, right?
The exploit would go like this:
1) mmap() the shared memory
2) open
(reposted from my comments at http://lwn.net/Articles/593918/)
I may have thought of a way to subvert SEAL_WRITE using O_DIRECT and
asynchronous I/O. I am not sure if this is a real problem or not, but
better to ask, right?
The exploit would go like this:
1) mmap() the shared memory
2) open
Hi
On Thu, Apr 10, 2014 at 11:33 PM, Tony Battersby to...@cybernetics.com wrote:
For O_DIRECT the kernel pins the submitted pages in memory for DMA by
incrementing the page reference counts when the I/O is submitted,
allowing the pages to be modified by DMA even if they are no longer
mapped
On 04/10/2014 05:22 PM, David Herrmann wrote:
Hi
On Thu, Apr 10, 2014 at 11:33 PM, Tony Battersby to...@cybernetics.com
wrote:
For O_DIRECT the kernel pins the submitted pages in memory for DMA by
incrementing the page reference counts when the I/O is submitted,
allowing the pages to be
18 matches
Mail list logo
