I mean not to put too fine a point on it but isn't GMP used for
authentication on a certain major linux desktop?
I presume those guys thought of this, and statically link, or that I
am just wrong.
Bill.
On 25 Aug, 16:15, Bill Hart <goodwillh...@googlemail.com> wrote:
> I think by "this capability" I mean the capability GMP/MPIR has of
> allowing user code to supply a memory manager.
>
> I mean, if that is global, doesn't it imply that user code can spy on
> the memory of other user code, say when it comes up for realloc?
>
> And it is also potentially possible for one process to crash another
> by controlling its memory allocation.
>
> Maybe I completely misunderstand what "this capability" is all about.
>
> Bill.
>
> On 24 Aug, 23:54, Nils Bruin <nbr...@sfu.ca> wrote:
>
>
>
> > On Aug 24, 2:44 pm, Bill Hart <goodwillh...@googlemail.com> wrote:
>
> > > void
> > > mp_set_memory_functions (void *(*alloc_func) (size_t),
> > > void *(*realloc_func) (void *, size_t, size_t),
> > > void (*free_func) (void *, size_t))
> > > {
> > > if (alloc_func == 0)
> > > alloc_func = __gmp_default_allocate;
> > > if (realloc_func == 0)
> > > realloc_func = __gmp_default_reallocate;
> > > if (free_func == 0)
> > > free_func = __gmp_default_free;
>
> > > __gmp_allocate_func = alloc_func;
> > > __gmp_reallocate_func = realloc_func;
> > > __gmp_free_func = free_func;
>
> > > }
>
> > > Not very extensive huh. I actually don't see a solution to this
> > > problem that involves mpir. In fact I think this is a security issue
> > > and I don't think this capability should even exist.
>
> > I do not understand what you mean, partially because I don't
> > understand what you mean by "this capability". If you think it's
> > relevant, would you mind explaining a little more elaborately?
>
> > In other news, I now see that my assumptions about ECLs usage of GMP
> > do not hold at all. They are depending on GMP claiming memory for them
> > almost everywhere.
> > However, a bignum in C is immutable, so after its creation it does not
> > change value anymore. So it might actually make sense to preallocate
> > bignums as
> > [mp_size, mp_d, <pointer to limb[0]>, mp_alloc, limb[0], limb
> > [1], ... , limb[mp_alloc-1]]
> > i.e., put the limbs straight after the mpz_t. That way, creating a
> > bignum only takes one alloc, instead of two.
>
> > We would have to ensure that enough limbs are allocated to upon
> > creation. One way to do that would be to let GMP create the result in
> > a temporary variable, copy over the limbs into the bignum and call
> > gmp_free on the temporary variable (or keep the temp around for the
> > next time). That would always incur an extra copy, but the current
> > implementation in ECL does something along those lines (but not
> > always).
>
> > Does GMP have routines somewhere that predict how many limbs the sum,
> > difference, product, exponential of an answer going to need? Naively,
> > I would think:
>
> > nlimbs(a+b) <= nlimbs(a)+nlimbs(b)+1
> > nlimbs(a*b) <= nlimbs(a)*nlimbs(b)
>
> > etc.
>
> > Is that correct? Or do certain optimizations/weird platforms mean that
> > these naive bounds can be wrong?
>
> > I think it should be possible to rewrite the bignums of ECL such that
> > the only "mpz_t"s that GMP allocates/reallocates are "registers",
> > i.e., temporary variables that do not need to be garbage collected,and
> > if we can predict the sizes beforehand, we may even be able to gain
> > some efficiency by eliminating some uses of "registers" in the current
> > code.
> > That might make the change a little more palatable to the ECL
> > maintainers. It would also mean that the "embeddability" of ECL would
> > increase a bit by not requiring that ECL administer the GMP's memory
> > allocation.
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
