On Mon, Aug 7, 2017 at 6:03 PM, Tyler Hicks wrote:
>> -static u32 seccomp_run_filters(const struct seccomp_data *sd)
>> +static u32 seccomp_run_filters(const struct seccomp_data *sd,
>> +struct seccomp_filter **match)
>> {
>> struct seccomp_data sd_local;
>>
On 08/07/2017 08:03 PM, Tyler Hicks wrote:
> On 08/02/2017 10:19 PM, Kees Cook wrote:
>> Both the upcoming logging improvements and changes to RET_KILL will need
>> to know which filter a given seccomp return value originated from. In
>> order to delay logic processing of result until after the sec
On 08/02/2017 10:19 PM, Kees Cook wrote:
> Both the upcoming logging improvements and changes to RET_KILL will need
> to know which filter a given seccomp return value originated from. In
> order to delay logic processing of result until after the seccomp loop,
> this adds a single pointer assignme
Both the upcoming logging improvements and changes to RET_KILL will need
to know which filter a given seccomp return value originated from. In
order to delay logic processing of result until after the seccomp loop,
this adds a single pointer assignment on matches. This will allow both
log and RET_K
4 matches
Mail list logo
