Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #26370

Re: exposing resource usage

Show all headers | View raw

On 4/14/2017 12:24 AM, upsidedown@downunder.com wrote:
> On Thu, 13 Apr 2017 20:56:19 -0500, Robert Wessel
> <robertwessel2@yahoo.com> wrote:
>
>> On Thu, 13 Apr 2017 18:22:05 -0700, Don Y
>> <blockedofcourse@foo.invalid> 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 depends on how paranoid you want to be.
>
> IIRC, some high security systems require that process should _not_ be
> able to determine, if it is running on a single CPU machine, multiple
> CPU systems or in a virtual machine and in all cases what the  CPU
> speed is.

In practice, that's almost impossible to guarantee.  Especially if you can
access other agencies that aren't thusly constrained.  E.g., issue a
request to a time service, count a large number of iterations of a
loop, access the time service again...

> Regarding quotas in more normal systems, quotas are used to limit
> rogue processes to overclaiming the resources.

But, that can be to limit the "damage" done by malicious processes
as well as processes that have undetected faults.  It can also be
used to impose limits on tasks that are otherwise unconstrainable
(e.g., how would you otherwise limit the resources devoted to
solving a particular open-ended problem?)

> In practice the sum of
> specific quotas for all processes can be much greater than the total
> resources available.  Thus, a process my have to handle a denied
> requests even if the own quota would have allowed it.

Yes, but how the "failure" is handled can vary tremendously -- see
below.

> Only in the case in which the sum of all (specific) quotas in a system
> is less than the total available resources, in that case you should be
> able to claim resources without checks as long as your claim is less
> than the quota allocated to that process.

That assumes the application is bug-free.

> But how would a process know, if the sum of quotas is less or more
> than the resources available ? Thus, the only safe way is to do the
> checks for failed resource allocations in any case.

How a resource request that can't be *currently* satisfied is
handled need not be an outright "failure".  The "appropriate"
semantics are entirely at the discretion of the developer.

When a process goes to push a character out a serial port
while the output queue/buffer is currently full (i.e., "resource
unavailable), it's common for the process to block until the
call can progress as expected.

When a process goes to reference a memory location that has
been swapped out of physical memory, the request *still*
completes -- despite the fact that the reference may take
thousands of times longer than "normal" (who knows *when* the
page will be restored?!)

When a process goes to fetch the next opcode (in a fully preemptible
environment), there are no guarantees that it will retain ownership
of the processor for the next epsilon of time.

When a process wants to take a mutex, it can end up blocking
in that operation, "indefinitely".

Yet, developers have no problem adapting to these semantics.

Why can't a memory allocation request *block* until it can
be satisfied?  Or, any other request for a resource that is
in scarce supply/overcommitted, currently?

This is especially true in cases where resources can be overcommitted
as you may not be able to 'schedule' the use of those resources
to ensure that the "in use" amount is always less than the
"total available".

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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