From: Nazarov Sergey
Date: Fri, 22 Feb 2019 19:35:29 +0300
> I tried to analyze the cases of using icmp_send in kernel. It
> indirectly used by many protocols: ARP, IP, UDP, Netfilter, IPVS,
> IPIP, GRE over IP, CLIP, XFRM, CIPSOv4. Different IP tunnels and
> XFRM operating directly over IP laye
I tried to analyze the cases of using icmp_send in kernel. It indirectly used
by many protocols:
ARP, IP, UDP, Netfilter, IPVS, IPIP, GRE over IP, CLIP, XFRM, CIPSOv4.
Different IP tunnels and XFRM operating directly over IP layer and if using own
skb->cb data,
having IP header data in front of i
From: Nazarov Sergey
Date: Mon, 18 Feb 2019 16:39:11 +0300
> I think, it would not be a good solution, if I will analyze all
> subsystems using icmp_send, because I do not have enough knowledge
> for this. I propose to add a new function, for example,
> ismp_send_safe, something like that:
Plea
I think, it would not be a good solution, if I will analyze all subsystems
using icmp_send, because I do not have enough knowledge for this.
I propose to add a new function, for example, ismp_send_safe, something like
that:
void icmp_send_safe(struct sk_buff *skb_in, int type, int code, __be32 i
On Fri, Feb 15, 2019 at 3:00 PM David Miller wrote:
> From: Paul Moore
> Date: Fri, 15 Feb 2019 14:02:31 -0500
>
> > On Thu, Feb 14, 2019 at 11:43 AM David Miller wrote:
> >> From: Nazarov Sergey
> >> Date: Tue, 12 Feb 2019 18:10:03 +0300
> >>
> >> > Since cipso_v4_error might be called from di
From: Paul Moore
Date: Fri, 15 Feb 2019 14:02:31 -0500
> On Thu, Feb 14, 2019 at 11:43 AM David Miller wrote:
>> From: Nazarov Sergey
>> Date: Tue, 12 Feb 2019 18:10:03 +0300
>>
>> > Since cipso_v4_error might be called from different network stack layers,
>> > we can't safely use icmp_send th
On Thu, Feb 14, 2019 at 11:43 AM David Miller wrote:
> From: Nazarov Sergey
> Date: Tue, 12 Feb 2019 18:10:03 +0300
>
> > Since cipso_v4_error might be called from different network stack layers,
> > we can't safely use icmp_send there.
> > icmp_send copies IP options with ip_option_echo, which
On 2/14/19 1:00 PM, Nazarov Sergey wrote:
Hi, Paul!
I've found the problem and testing it with some very specific custom lsm
module. The test case was simple:
standard TCP/IP client-server application, where server opens CIPSO labeled TCP
socket, and client connecting
to this socket with forbid
Now the problem comes from TCP layer only. Is the IP over ATM operates over IP
layer?
14.02.2019, 19:43, "David Miller" :
> From: Nazarov Sergey
> Date: Tue, 12 Feb 2019 18:10:03 +0300
>
>> Since cipso_v4_error might be called from different network stack layers,
>> we can't safely use icmp_se
Hi, Paul!
I've found the problem and testing it with some very specific custom lsm
module. The test case was simple:
standard TCP/IP client-server application, where server opens CIPSO labeled TCP
socket, and client connecting
to this socket with forbidden labels. After several connections kernel
From: Nazarov Sergey
Date: Tue, 12 Feb 2019 18:10:03 +0300
> Since cipso_v4_error might be called from different network stack layers, we
> can't safely use icmp_send there.
> icmp_send copies IP options with ip_option_echo, which uses IPCB to take
> access to IP header compiled data.
> But aft
On Tue, Feb 12, 2019 at 10:10 AM Nazarov Sergey wrote:
> Since cipso_v4_error might be called from different network stack layers, we
> can't safely use icmp_send there.
> icmp_send copies IP options with ip_option_echo, which uses IPCB to take
> access to IP header compiled data.
> But after co
Since cipso_v4_error might be called from different network stack layers, we
can't safely use icmp_send there.
icmp_send copies IP options with ip_option_echo, which uses IPCB to take access
to IP header compiled data.
But after commit 971f10ec ("tcp: better TCP_SKB_CB layout to reduce cache line
13 matches
Mail list logo
