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

Tomeu Vizoso tomeu at sugarlabs.org
Thu Mar 19 05:55:37 EDT 2009


On Mon, Mar 9, 2009 at 22:25, Luke Faraone <luke at faraone.cc> wrote:
> On Mon, Mar 9, 2009 at 5:22 PM, Sascha Silbe
> <sascha-ml-ui-sugar-devel at silbe.org> 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. Strangely, Bitfrost [1] only
>> seems to address CPU and NAND exhaustion, but not RAM.
>> No activity should be able to do what you describe above, whether
>> intentionally or not.
>> While a low memory warning has merits on its own, the underlying issue
>> should be fixed as well. The most simple thing to do would be limiting
>> segment sizes. Better solutions might tweak priorities for "core" system
>> components (like sugar-shell) and/or require kernel changes (e.g. implement
>> RLIMIT_RSS handling).
>
> But unfortunately most Sugar installations other than XOs will lack
> bitfrost, which is a wider issue that merits further investigation: Should
> sugar adopt bitfrost?

Well, I don't think bitfrost has any dependency on sugar, it should be
generally applicable to other platforms.

That said, as we would like kids to share code without their data
integrity and privacy being compromised, bitfrost goals fit very well
with our intentions.

I see two possible scenarios:

- Rainbow is developed as an independent project and Sugar depends on
it in the same way as depends on NetworkManager.

- Rainbow becomes part of glucose.

But in both cases, someone needs to stand up and do the integration work.

Regards,

Tomeu


More information about the Sugar-devel mailing list