Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #26377
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: exposing resource usage |
| Date | 2017-04-14 11:44 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <ocr556$lsb$1@dont-email.me> (permalink) |
| References | <ocp81u$gtm$1@dont-email.me> <iMWdnRxmsKwkkWzFnZ2dnUU7-XWdnZ2d@giganews.com> |
On 4/14/2017 10:54 AM, Tim Wescott wrote: > On Thu, 13 Apr 2017 18:22:05 -0700, Don Y wrote: > >> Is there any potential downside to intentionally exposing (to a >> task/process/job/etc.) its current resource commitments? >> I.e., "You are currently holding X memory, Y CPU, Z ..." >> >> *If* the job is constrained to a particular set of quotas, then knowing >> *what* it is using SHOULDN'T give it any "exploitable" information, >> should it? >> >> [Open system; possibility for hostile actors] > > It's one less barrier to some outside actor getting that information, and > therefor using it in an attack (if I know to do something that might make > a task overflow its stack, for instance, I'll have something concrete to > try to help me break in). Of course. The challenge in the design of an OPEN system is coming to a balance between what you do *for* the developer (to allow him to more efficiently design more robust applications) vs. the "levers" that you can unintentionally expose to a developer. In *closed* systems, the system design can tend to assume the developers are not malicious; that every "lever" thus provided is exploited to improve cost, performance, etc. Any flaws in the resulting system are consequences of developer "shortcomings". In an open system, you have all the same possibilities -- PLUS the possibility of a malicious developer (or user!) exploiting one of those levers in a counterproductive manner. > How hard are you going to work to keep that information out of the hands > of outside actors? The only way to completely prevent exploits is to completely deny access. But, that's contrary to the goal of an open system.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Find similar | Unroll thread
exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-13 18:22 -0700
Re: exposing resource usage Robert Wessel <robertwessel2@yahoo.com> - 2017-04-13 20:56 -0500
Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-13 22:26 -0700
Re: exposing resource usage upsidedown@downunder.com - 2017-04-14 10:24 +0300
Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-14 00:53 -0700
Re: exposing resource usage upsidedown@downunder.com - 2017-04-14 12:53 +0300
Re: exposing resource usage upsidedown@downunder.com - 2017-04-14 15:33 +0300
Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-14 10:22 -0700
Re: exposing resource usage upsidedown@downunder.com - 2017-04-17 20:24 +0300
Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-17 12:13 -0700
Re: exposing resource usage Dimiter_Popoff <dp@tgi-sci.com> - 2017-04-14 21:26 +0300
Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-14 12:45 -0700
Re: exposing resource usage Dimiter_Popoff <dp@tgi-sci.com> - 2017-04-15 00:27 +0300
Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-14 20:45 -0700
Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-14 10:11 -0700
Re: exposing resource usage Tim Wescott <seemywebsite@myfooter.really> - 2017-04-14 12:54 -0500
Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-14 11:44 -0700
csiph-web