On Mon, Feb 11, 2019 at 4:21 PM Nazarov Sergey wrote:
> Hi, Paul!
> What I need to do for this?
If you haven't already done so, go read
Documentation/process/submitting-patches.rst, that should guide you
through the process. I would also suggest looking at both the git log
and the mailing list a
Hi, Paul!
What I need to do for this?
11.02.2019, 23:37, "Paul Moore" :
> On Thu, Jan 31, 2019 at 8:20 AM Nazarov Sergey wrote:
>> 31.01.2019, 05:10, "Paul Moore" :
>> > This isn't how the rest of the stack works, look at
>> > ip_local_deliver_finish() for one example. Perhaps the behavior you
On Thu, Jan 31, 2019 at 8:20 AM Nazarov Sergey wrote:
> 31.01.2019, 05:10, "Paul Moore" :
> > This isn't how the rest of the stack works, look at
> > ip_local_deliver_finish() for one example. Perhaps the behavior you
> > are proposing is correct, but please show me where in the various RFC
> > sp
31.01.2019, 05:10, "Paul Moore" :
> This isn't how the rest of the stack works, look at
> ip_local_deliver_finish() for one example. Perhaps the behavior you
> are proposing is correct, but please show me where in the various RFC
> specs it is defined so that I can better understand why it should w
On Wed, Jan 30, 2019 at 8:11 AM Nazarov Sergey wrote:
> 30.01.2019, 01:42, "Paul Moore" :
> > There are several cases where the stack ends up calling icmp_send()
> > after the skb has been through ip_options_compile(), that should be
> > okay.
> >
> > --
> > paul moore
> > www.paul-moore.com
>
> I
30.01.2019, 01:42, "Paul Moore" :
> There are several cases where the stack ends up calling icmp_send()
> after the skb has been through ip_options_compile(), that should be
> okay.
>
> --
> paul moore
> www.paul-moore.com
In those cases precompiled ip_options struct used, without the need to reus
On Tue, Jan 29, 2019 at 2:23 AM Nazarov Sergey wrote:
> 29.01.2019, 01:18, "Paul Moore" :
> > If we don't pass a skb into ip_options_compile(), meaning both "skb"
> > and "rt" will be NULL, then I don't believe the option data will
> > change. Am I missing something?
>
> I mean, in cipso_v4_error
29.01.2019, 01:18, "Paul Moore" :
> If we don't pass a skb into ip_options_compile(), meaning both "skb"
> and "rt" will be NULL, then I don't believe the option data will
> change. Am I missing something?
>
> --
> paul moore
> www.paul-moore.com
I mean, in cipso_v4_error we copy option data from
On Mon, Jan 28, 2019 at 8:10 AM Nazarov Sergey wrote:
> 25.01.2019, 19:46, "Paul Moore" :
> > Hmm, I think the above calculation should take into account the actual
> > length of the IP options, and not just the max size (calculate it
> > based on iphdr->ihl).
> >
> > Beyond that fix, I think it's
25.01.2019, 19:46, "Paul Moore" :
> Hmm, I think the above calculation should take into account the actual
> length of the IP options, and not just the max size (calculate it
> based on iphdr->ihl).
>
> Beyond that fix, I think it's time to put together a proper patchset
> and post it to the lists
On Thu, Jan 24, 2019 at 9:46 AM Nazarov Sergey wrote:
> 22.01.2019, 20:48, "Paul Moore" :
> >
> > Yes, exactly. If you don't pass the skb it shouldn't attempt to call
> > icmp_send() in case of error.
> >
> > --
> > paul moore
> > www.paul-moore.com
>
> You are right, sorry. We can do that without
22.01.2019, 20:48, "Paul Moore" :
>
> Yes, exactly. If you don't pass the skb it shouldn't attempt to call
> icmp_send() in case of error.
>
> --
> paul moore
> www.paul-moore.com
You are right, sorry. We can do that without ip_options_compile modification.
Simplified patch 2:
---
net/ipv4/cipso_
On Tue, Jan 22, 2019 at 12:35 PM Nazarov Sergey wrote:
> 22.01.2019, 19:49, "Paul Moore" :
> >
> > Granted I'm looking at this rather quickly, so I may be missing
> > something, but why the changes to ip_options_compile()? Couldn't you
> > simply set opt->data manually (set the ptr) in cipso_v4_er
22.01.2019, 19:49, "Paul Moore" :
>
> Granted I'm looking at this rather quickly, so I may be missing
> something, but why the changes to ip_options_compile()? Couldn't you
> simply set opt->data manually (set the ptr) in cipso_v4_error() before
> calling ip_options_compile() and arrive at the same
On Mon, Jan 21, 2019 at 12:11 PM Nazarov Sergey wrote:
> 18.01.2019, 20:17, "Paul Moore" :
> > Yes, this is extra overhead, but it is in an error path so I'm not
> > overly concerned about the performance impact on the given connection.
> >
> > I will admit that it isn't an ideal solution from a L
18.01.2019, 20:17, "Paul Moore" :
> Yes, this is extra overhead, but it is in an error path so I'm not
> overly concerned about the performance impact on the given connection.
>
> I will admit that it isn't an ideal solution from a LSM/NetLabel
> perspective, but historically the netdev folks have
On Fri, Jan 18, 2019 at 11:34 AM Nazarov Sergey wrote:
> Hi, Paul!
> I don't like this. As you said, fix any calls to icmp_send is a trivial.
> But in cipso_v4_optptr, we repeating the work already done, and in
> cipso_v4_error
> we will need to do even more again.
Yes, this is extra overhead, b
Hi, Paul!
I don't like this. As you said, fix any calls to icmp_send is a trivial.
But in cipso_v4_optptr, we repeating the work already done, and in
cipso_v4_error
we will need to do even more again. Any code, working with IP header data on
several
levels of TCP/IP stack need to do this again an
On Tue, Jan 15, 2019 at 2:52 PM Paul Moore wrote:
> On Tue, Jan 15, 2019 at 12:55 PM Casey Schaufler
> wrote:
> > On 1/15/2019 9:06 AM, Nazarov Sergey wrote:
> > > Hello!
> > > Security modules (selinux, smack) use icmp_send for discarded incorrectly
> > > labeled network packets.
> > > This co
On Tue, Jan 15, 2019 at 12:55 PM Casey Schaufler wrote:
> On 1/15/2019 9:06 AM, Nazarov Sergey wrote:
> > Hello!
> > Security modules (selinux, smack) use icmp_send for discarded incorrectly
> > labeled network packets.
> > This could be on TCP level too (security_sock_rcv_skb -> cipso_v4_error f
20 matches
Mail list logo
