Re: Recent IPSEC changes

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Mon, Oct 16, 2017 at 6:43 PM, Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
> On Sat, Oct 14, 2017 at 2:19 AM, Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
>> On Fri, Oct 13, 2017 at 9:28 PM, Robert Swindells <rjs%fdy2.co.uk@localhost> wrote:
>>>
>>> Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
>>>>On Fri, Oct 13, 2017 at 4:41 PM, Robert Swindells <rjs%fdy2.co.uk@localhost> wrote:
>>>>
>>>> Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
>>>>>On Fri, Oct 13, 2017 at 5:49 AM, Robert Swindells <rjs%fdy2.co.uk@localhost> wrote:
>>>>>>
>>>>>> I think something in the recent IPSEC changes is setting the ipsec_used
>>>>>> flag to be always true.
>>>>>
>>>>>Not really on my machine. I guess it depends on environments.
>>>>
>>>> My environment is INET, INET6 & IPSEC in the kernel config, no modules.
>>>>
>>>> I have taken out any other protocols.
>>>
>>> My config is similar to GENERIC in in terms of network protocols.
>>>
>>>>
>>>>>>There is a change that affects the ipsec_used flag:
>>>>>>  http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netipsec/key.c#rev1.199
>>>>>
>>>>> Ok.
>>>>>
>>>>>>It turns on the flag when a socket is enabled the IP_IPSEC_POLICY option.
>>>>>>There was a bug that having such a socket didn't turn on the flag; the
>>>>>>above commit fixed the bug.
>>>>>
>>>>> The flag is on at boot for me.
>>>>
>>>>Heh. ipsec_used is initially 0. And only key_update_used() changes the
>>>>value. Could you add KASSERT(0) to at the beginning of key_update_used,
>>>>rebuild a kernel and try to boot it? Then, we can know who changes it
>>>>(or it's initialized with 1 unexpectedly).
>>>
>>> I added a printf in key_socksplist_add(), it gets called multiple times
>>> at startup.
>>>
>>> Replacing it with KASSERT(0) suggests that the first one is from inetd.
>>>
>>>>>
>>>>>>Do you have any processes having a socket with IP_IPSEC_POLICY on your
>>>>>>machine in mind?
>>>>>
>>>>> No.
>>>>
>>>>Hmm.
>>>
>>> I wrote "no", but inetd(8) does seem to be creating some.
>>>
>>> I have not put a policy specifier into /etc/inetd.conf, just uncommented
>>> some services.
>>
>> It seems that inetd tries to set a dummy policy ("in entrust; out entrust")
>> to each socket of daemons even if there is no policy specifier in the config.
>> The code looks purposefully setting the dummy policy but at least its
>> behavior conflicts with the manual.
>>
>> Anyway there seems to be another bug that the ipsec_used flag isn't cleared;
>> if I stopped inetd, the flag wasn't changed. I'll investigate the issues
>> next week.
>
> It seems that the behavior is expected; the ipsec_used flag never back to 0
> intentionally to avoid a race condition once it's set to 1. We should
> eventually fix the issue in the future though, what we should do now is to
> stop inetd setting SPs meaninglessly, I think.

Fixed in -current (some days ago). If the issue remains, please let me know.

Thanks,
  ozaki-r