[Rpm-maint] [rpm-software-management/rpm] RPM with Copy on Write (#1470)

[chantra]

> That is definitely a step forward, especially if the hashing is performed in the parent process. I imagine `SECCOMP_SET_MODE_STRICT` would be pretty hard to break out of, and would dramatically reduce my worries about this patch. Is setting up `SECCOMP_SET_MODE_STRICT` before decompression a viable option?

@DemiMarie so I looked a bit more into `seccomp`. Unfortunately strict mode is.... too strict with only read/write/_exit, nd sigreturn.
With a bit of fiddling with `SECCOMP_RET_TRAP`, this is the list I came up with in order to get the decompression to work:
https://gist.github.com/chantra/0fd33c338ba7465d87222b68bab76e70

As much as portability, AFAIK, not all architectures are covered, but I may be wrong. There is likely some corner cases here. For one, the FD_t layer adds stats computation to the read/write operations and within that lays calls to [`gettimeofday`](https://github.com/rpm-software-management/rpm/blob/07f1d3132f0c7b7ecb69a47a9930edb534a9250e/rpmio/rpmsw.c#L21), which may or may not be a vsdo, so probably another one to add to the list.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1470#issuecomment-1036459705
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/pull/1470/c1036459705 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20220211/3415b259/attachment.html>