Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Restrict capacity of plists to 2^28 resp. 2^60 (revision of #2039) #2064

Merged
merged 3 commits into from
Jan 8, 2018
Merged

Restrict capacity of plists to 2^28 resp. 2^60 (revision of #2039) #2064

merged 3 commits into from
Jan 8, 2018

Commits on Jan 4, 2018

  1. Fix SIZE_OBJ kernel func for large or immediate objects 

    That is, use ObjInt_UInt instead of INTOBJ_INT to convert the object size
into a GAP integer object, and handle T_INT and T_FFE inputs explicitly.

Also replace the kernel function SHALLOW_SIZE with a synonym pointing to
SIZE_OBJ. While the former name may be less misleading (a user might expect
SIZE_OBJ to include the sizes of subobjects), the latter name matches the
name of the kernel function, just like with TNUM_OBJ and TNAM_OBJ, which
simplifies life for kernel developers who want to use these UNDOCUMENTED,
INTERNAL and potentially DANGEROUS APIs. As such, clarity of names is not a
primary concern.
    @fingolfin
    fingolfin committed Jan 4, 2018
    Configuration menu
    Copy the full SHA
    ccd8c56 View commit details
    Browse the repository at this point in the history

  2. Add (INT_)INTOBJ_{MIN,MAX}; add bounds check to INTOBJ_INT 

    Also convert as much code as possible to use the new constants,
and tweak some additional places using NR_SMALL_INT_BITS:

* FindCommonField used it in a bounds check, but not quite right; use
  INT_INTOBJ_MAX instead
* FuncGASMAN_STATS was simplified by using ObjInt_Int
* ProdIntObj and PowObjInt needlessly used NR_SMALL_INT_BITS+1, changed
  to avoid the +1
* ModInt and RemInt included a check 'i <= (1L<<NR_SMALL_INT_BITS)' for
  an immediate value i, which of course was always true, so removed it
    @fingolfin
    fingolfin committed Jan 4, 2018
    Configuration menu
    Copy the full SHA
    ff3170a View commit details
    Browse the repository at this point in the history

  3. Restrict capacity of plists to 2^28 resp. 2^60 

    By adding bounds checks to GrowPlist and NEW_PLIST, we restrict the capacity
of plain lists to the maximum value of an immediate integer, i.e. 2^28 on a
32 bit system and 2^60 on a 64 bit system. The check in GrowPlist triggers
an error, as it can be triggered by the user. The check in NEW_PLIST is a
run-time assertion, and should never be triggered by user actions, only by
buggy kernel code.

This restriction fixes overflows and other problems, which can lead to
crashes, corrupt data or nonsense computations.

It poses no actual limitation in practice, for the following reasons:

First off, many other places already effectively limited the length of a
plist they can interact with to the maximum value of an immediate integer.
E.g. such limitations exist for sublist access via l{poss}, EmptyPlist(),
ASS_PLIST_DEFAULT, and more.

Secondly, with this change,  the effective size (in bytes) of a plist of this
maximal length would be 2^30 resp. 2^63. The latter certainly poses no actual
limitation. The former corresponds to 1 GB. While GAP in principle supports
slightly larger bags on 32 bit systems (the GASMAN heap can grow up to almost
4GB if the host system supports it),, there is not much you can do with GAP
if most of its heap is filled with a gigantic plist, so this restriction
seems acceptable.
    @fingolfin
    fingolfin committed Jan 4, 2018
    Configuration menu
    Copy the full SHA
    2e12aa4 View commit details
    Browse the repository at this point in the history