Proxy memory objects (was: Denial of service attack via libpager)

Hi, On Mon, Aug 29, 2016 at 11:15:48AM +0200, Richard Braun wrote: > OK, this comes from the fact that io_map directly provides memory > objects indeed... Do we actually want to pass them around ? How > come calls like memory_object_init (specifically meant to be used > between the kernel and

Re: Denial of service attack via libpager

On Mon, Aug 29, 2016 at 03:58:29PM -1000, Brent W. Baccala wrote: > On Sun, Aug 28, 2016 at 11:15 PM, Richard Braun wrote: > > OK, this comes from the fact that io_map directly provides memory > > objects indeed... Do we actually want to pass them around ? How > > come calls

Re: Denial of service attack via libpager

On Sun, Aug 28, 2016 at 11:15 PM, Richard Braun wrote: > On Sun, Aug 28, 2016 at 05:12:35PM -1000, Brent W. Baccala wrote: > > > The obvious additional client would be a remote kernel, but as the > exploit > > program that I posted shows, it could just as easily be an

Re: Denial of service attack via libpager

On Mon, Aug 29, 2016 at 11:20:47AM +0200, Richard Braun wrote: > In addition, I've just thought about something else : if we handle > multiple clients, how do we make sure that two kernels, caching the > same file, don't just completely corrupt its content ? We'd need > some kind of cooperation to

Re: Denial of service attack via libpager

On Sun, Aug 28, 2016 at 05:12:35PM -1000, Brent W. Baccala wrote: > I should elaborate on what I found with exec. After I fixed the problem > with the exec server mmap'ing the library's ELF headers, it just got on a > little bit further in the process, and then croaked when it tried to mmap > the

Re: Denial of service attack via libpager

On Sun, Aug 28, 2016 at 05:12:35PM -1000, Brent W. Baccala wrote: > So we still have to mmap across the network. We certainly don't want to > avoid mmap's entirely for program text and (especially) for shared > libraries. Although I admit that it would be best to detect when the mmap > fails and

Re: Denial of service attack via libpager

On Sun, Aug 28, 2016 at 12:49 PM, Richard Braun wrote: > > I'm really not seeing the relation between "multiple clients" and > "multiple threads". Libpager must be able to handle multiple clients > with a single thread, otherwise we don't control scalability and we're > back to

Denial of service attack via libpager

Aloha - I've written a short program (attached) that demonstrates how libpager's support for only a single client can be used to mount a denial of service attack against the kernel. It works by opening a file, grabbing its associated memory object (if it can), and holding it until you hit