Re: Features for the facilitation of sandbox construction
- From: Philipp Kutin <philipp.kutin@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Thu, 17 Jan 2013 13:20:39 +0100
Hi,
sorry for digging out such an old thread, but after some thinking,
there still seem to be a couple of open questions left.
To recap, my problem was that of making FFI struct ctype data be
accessible for both internal, trusted code as well as "untrusted"
users. In the absence of array or pointer members in the struct, I
believe such accesses to be safe (not inducing undefined behavior)
because the memory is allocated once on the C side and never released.
The solution I came up with the help of the hint given by Erik earlier
is that I have a "template" for a C struct, like
local ACTOR_STRUCT = [[{
const int32_t t_data[10];
int32_t flags;
const int16_t picnum;
}]]
which undergoes treatment twice to procude the actual C types:
For internal use, we strip all "const" qualifiers:
(...) typedef struct]].. strip_const(ACTOR_STRUCT).. [[actor_u_t;
// _u for "unrestricted"
and for the users, we substitute arrays by a sequence of (randomly
named :-)) scalar fields:
(...) typedef struct]].. mangle_arrays(ACTOR_STRUCT) ..[[actor_t;
Then, in the metatable for the exposed ctype "actor_t", we have
accessor functions for the restricted members, like
get_t_data = function(a, idx)
if (idx >= 10ULL) then error("Invalid t_data index "..idx, 2) end
return ffi.cast(actor_ptr_ct, a).t_data[idx]
end
.
This is all fine, but what I'm worried about now is whether mixed
accesses to one and the same member don't violate the strict aliasing
rules? It's only the const scalars like "picnum" in my example I'm
concerned about here, because we'd be able to access the array members
only with the unrestricted type. (If the compiler concludes that they
must not alias other data, it'd be right).
My suspicion is somewhat substantiated by the comments in
lj_opt_mem.c, which read:
/* This implements (very) strict aliasing rules.
** Different types do NOT alias, except for differences in
signedness. (...) */
and further:
/* NYI: structural disambiguation. */
about which I'm unsure whether it relates to my problem. Am I on the
right track?
Greetings,
Philipp
Other related posts:
