[Sugar-devel] RAM DoS (was: Re: Fwd: Activity startup idea)

[Michael Stone]

On Mon, Mar 09, 2009 at 10:22:06PM +0100, Sascha Silbe wrote:
> On Mon, Mar 09, 2009 at 11:52:53AM -0500, Wade Brainerd wrote:
>
>> It happens to me at least once every couple of days on build  
>> 767...first the
>> UI freezes, then the trackpad stops responding, and if I'm lucky I can
>> manage to Ctrl-Alt-F1 and kill Browse before having to just hard power  
>> off.
> This sounds like a security issue to me. 

To me, it's more of a "we don't understand the kernel's memory allocator"
issue, for two reasons. First, there aren't any persistent side-effects other
than perhaps wasted time and lost data and these transient side-effects are
tightly correlated with the proximate cause of the issue. So far as I know,
people still get conditioned by this sort of thing quite quickly. Second, if
the 767 kernel's OOM killer were invoked faster, then there would be much less
of an issue here.

As for memory limits on activities -- there's some interesting work to be done
here, and some interesting UI problems as well. For example, we used to offer
activities access to size-limited tmpfsen. Unfortunately, nobody had any good
ways to figure out what size the tmpfsen should be so, eventually, we just
removed the size limits in order to avoid the "my activity crashed because I
didn't catch ENOSPC" bugs.

Similarly, while it is trivial to set per-process memory limits with
setrlimit(RLIMIT_AS) and possible but more exciting to set per-activity memory
limits with the cgroups memory resource controller, I've never heard of anyone
doing these things, even though rainbow provides explicit support for the
former and even though I've mentioned the latter to a wide variety of people.

All this being said, though, it's nice to hear people (e.g. Ben) thinking
creatively about the issue.

Regards,

Michael