Am 27.04.2020 um 17:28 schrieb Yann Ylavic:
On Mon, Apr 27, 2020 at 5:18 PM Rainer Jung <[email protected]> wrote:
Hi Yann,
Am 27.04.2020 um 16:40 schrieb Yann Ylavic:
Hi Rainer,
On Mon, Apr 27, 2020 at 3:17 PM Rainer Jung <[email protected]> wrote:
Thanks for this.
Could you please create this as a PR on github as well? This ensures that all
the Travis tests are run for your patch.
Thanks Rüdiger. Done and indeed Travis found one not that I fixed but we
need to discuss.
Thanks Rainer, looks very nice.
Could we avoid the "ap_sload_t *sload" pointer in ap_mon_snap_t somehow?
I'm asking because snap0 and snap1 in global_score (SHM) end up
containing a pointer now.
My initial version had the fields of ap_sload_t directly inside
ap_mon_snap_t instead of the pointer.
I changed it, because
- it allowed to more safely copy the whole ap_sload_t without relying on
keeping two struct definitions in sync
- it allowed to extend ap_sload_t and ap_mon_snap_t at their respective
ends and stay compatible.
You have a problem with the pointers because of possible alignment
issues or what kind of trouble might we run into? Or is it just hard to
understand (and more comments in the code will help)?
My concern is more about security, e.g. CVE-2019-0211 kind of things,
with an unprivileged user (child) playing with this pointer and making
the main process (monitor?) at best crash, at worst do anything they
want (root privilege escalation).
I see. Although I don't see a way how we would execute code at the
derefenced address, as a safety guard for future code changes we can
easily avoid using the pointers in the scoreboard and instead use sload0
/ snap0 and sload1 / snap1 when doing the calculations. Since the
pointers (after init) would have been constant, we can hard code it into
trivial logic instead.
One could then use a separate type for snap0 and snap1 in the
scoreboard, but I would find it better to stay with the ap_mon_snap_t
type, even if we do not use the pointer there.
For the struct passed in from the consumer, I would still use the
pointer as-is.
Will provide a change on top of the PR for further discussion.
Thanks for the heads up. Didn't think about using the scoreboard and the
monitor hook running in the parent havig security implications. One
really needs to be careful about assumptions for the scoreboard data!
Regards,
Rainer
