[lkml]   [2012]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/9] exec: add a global execve counter

    * Solar Designer <> wrote:

    > > Actually, using a pure counter is horrible, because even if
    > > it takes four days to wrap, it *will* wrap, and the attacker
    > > can just count his own execve's.
    > Four days (for a 32-bit counter) is just not enough, so the
    > counter needs to be e.g. 64-bit as proposed. A 64-bit counter
    > won't wrap during lifetime of a system.

    A 64-bit counter is OK on 32-bit platforms as well as long as
    it's not *atomic*.

    Linus's scheme of using the CPU ID for the high bits would solve
    that particular problem IMO. Each CPU would have its own count
    set apart in a percpu area, accessible via __this_cpu_inc() or

    16 bits for the CPU ID and 48 bits for the actual count should
    be enough for everyone! ;-) It wraps in about 700 years, with
    current CPU speeds and assuming that exec() will be relatively
    slow in the future as well.

    Some other kernel code might make use of such a fast, global
    generation count as well, so if this is reasonably abstracted
    out and named properly it would not just be a single-purpose
    security facility. DEFINE_GENCOUNT() or so? [the count itself
    would not be reused, of course.]

    > The CPUs' timestamp counters were not designed for security.
    > I would not be too surprised if some implementation of a CPU
    > architecture (maybe emulated, maybe under a hypervisor) has
    > such timestamp counter granularity that we may see the same
    > value across a second execve().

    Not using the TSC would certainly make this logic simpler and
    faster - which is a big plus for any security measure.



     \ /
      Last update: 2012-03-11 10:59    [W:0.020 / U:1.616 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site