[lkml]   [1998]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] New phys_addr() syscall
Tony Cook writes:
> On Mon, 20 Jul 1998, Richard Gooch wrote:
> > Just so I'm clear on this: I'm in no way saying that phys_addr(2)
> > combined with mlock(2) is the proper way to do this. I just wanted to
> > point out that you *could*, if you wanted. Sigh. Maybe I shouldn't
> > have mentioned that aspect at all.
> I'm wondering if phys_addr(2) could be used in combination with
> mlock(2) to fragment physical memory.
> Could an attacker:
> for() {
> allocate a large block of memory and page it in (memset(base, 1, size))
> scan the block with phys_addr(2) looking for blocks matching a pattern
> (eg. every second block)
> mlock those blocks
> }

Yes, it's true that you could misuse phys_addr(2) this way. On the
other hand your attack relies on mlock(2) privileges in the first
place. This option is not available to non-root processes. If I want
to bring a machine to its knees, and I have root access, I'm not going
to bother with fragmenting memory. I'll just run halt(8)!

So far all the "security problems" I've seen raised about phys_addr(2)
are in fact just problems with existing facilities being abused. The
phys_addr(2) syscall confers no extra benefits/privileges other than

> This simple version could be easily defeated with ulimit, but is it
> possible a more sophisticated version wouldn't be?

Show me a way of abusing phys_addr(2) which doesn't rely on root
privileges and can't be done without phys_addr(2) (note that I can
write an unprivileged programme which will punish your machine with
resorting to phys_addr(2) at all).

Please, everyone. I'm convinced that phys_addr(2) "abuse" is a
non-issue. Show me *how* phys_addr(2) can lead to attacks that you
otherwise couldn't do.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:43    [W:0.031 / U:1.284 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site