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 som
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
Dav
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 you
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 write-
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 submitted
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 D
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 spac
(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 som
If two processes share a common memory region, they usually want some
guarantees to allow safe access. This often includes:
- one side cannot overwrite data while the other reads it
- one side cannot shrink the buffer while the other accesses it
- one side cannot grow the buffer beyond previo
10 matches
Mail list logo
