On Mon, Jan 30, 2017 at 8:41 AM, David Miller wrote:
> From: Sowmini Varadhan
> Date: Mon, 30 Jan 2017 11:26:03 -0500
>
>> On (01/27/17 19:19), Willem de Bruijn wrote:
>>> > other than ax25, are there variable length header protocols out there
>>> > without ->validate, and which need the CAP_RAW_
From: Sowmini Varadhan
Date: Mon, 30 Jan 2017 11:26:03 -0500
> On (01/27/17 19:19), Willem de Bruijn wrote:
>> > other than ax25, are there variable length header protocols out there
>> > without ->validate, and which need the CAP_RAW_SYSIO branch?
>>
>> I don't know. An exhaustive search of pro
On (01/27/17 19:19), Willem de Bruijn wrote:
> > other than ax25, are there variable length header protocols out there
> > without ->validate, and which need the CAP_RAW_SYSIO branch?
>
> I don't know. An exhaustive search of protocols (by header_ops) may be
> needed to say for sure.
>
> If there
On Fri, Jan 27, 2017 at 4:58 PM, Sowmini Varadhan
wrote:
> On (01/27/17 15:51), Willem de Bruijn wrote:
> :
>> - limit capable() check to drivers with with .validate callback
> (aka second option below)
> :
>> - let privileged applications shoot themselves in the foot (change nothing).
>
>
On (01/27/17 15:51), Willem de Bruijn wrote:
:
> - limit capable() check to drivers with with .validate callback
(aka second option below)
:
> - let privileged applications shoot themselves in the foot (change nothing).
> The second will break variable length header protocols unless
> yo
On Fri, Jan 27, 2017 at 3:06 PM, Sowmini Varadhan
wrote:
> On (01/27/17 14:29), Willem de Bruijn wrote:
>>
>> As your patch state, the contract is that any packet delivered to a
>> driver has the entire L2 in its linear section. Drivers are not required
>> to be robust against shorter packets, so
On (01/27/17 14:29), Willem de Bruijn wrote:
>
> As your patch state, the contract is that any packet delivered to a
> driver has the entire L2 in its linear section. Drivers are not required
> to be robust against shorter packets, so there is no reason to test
> those.
>
> One option is to limit
> On (01/27/17 10:28), Willem de Bruijn wrote:
>> > Would it make sense to only do the CAP_SYS_RAWIO branch if the
>> > driver declares itself to have variable length L2 headers, via, e.g.,
>> > some priv flag?
>>
>> At the time, the comments were not specific to AX25. Again, we should
>> probably
On (01/27/17 10:28), Willem de Bruijn wrote:
> > Would it make sense to only do the CAP_SYS_RAWIO branch if the
> > driver declares itself to have variable length L2 headers, via, e.g.,
> > some priv flag?
>
> At the time, the comments were not specific to AX25. Again, we should
> probably put tha
> " The AX.25 device level drivers are simply written to be robust if
> thrown partial frames.
>:
> The other thing that concerns me about this added logic in general is
> that you are also breaking test tools that want to deliberately send
> corrupt frames to certain classes of interfa
On (01/27/17 09:37), Willem de Bruijn wrote:
> The immediate problem you were facing is that dev_validate_header
> accepts values smaller than hard_header_len even for protocols with
> fixed header lengths.
Yes!
> This is a consequence of that CAP_SYS_RAWIO branch. Without it,
> dev_validate_head
On Thu, Jan 26, 2017 at 9:08 PM, Sowmini Varadhan
wrote:
> On (01/26/17 19:08), Willem de Bruijn wrote:
>>
>> Thanks for the context. ax25_addr_parse doesn't adjust length, it only
>> verifies that the contents of the variable length header matches
>> protocol spec. I don't think that it or the .v
On (01/26/17 19:08), Willem de Bruijn wrote:
>
> Thanks for the context. ax25_addr_parse doesn't adjust length, it only
> verifies that the contents of the variable length header matches
> protocol spec. I don't think that it or the .validate callback have to
> be modified to return length.
Yes,
On Thu, Jan 26, 2017 at 4:37 PM, Sowmini Varadhan
wrote:
> On (01/26/17 15:21), Willem de Bruijn wrote:
>> > If the application has provided fewer than hard_header_len bytes,
>> > dev_validate_header() will zero out the skb->data as needed. This is
>> > acceptable for SOCK_DGRAM/PF_PACKET sockets
On (01/26/17 15:21), Willem de Bruijn wrote:
> > If the application has provided fewer than hard_header_len bytes,
> > dev_validate_header() will zero out the skb->data as needed. This is
> > acceptable for SOCK_DGRAM/PF_PACKET sockets but in all other cases,
>
> This was added not for datagram so
> If the application has provided fewer than hard_header_len bytes,
> dev_validate_header() will zero out the skb->data as needed. This is
> acceptable for SOCK_DGRAM/PF_PACKET sockets but in all other cases,
This was added not for datagram sockets, but to be able to bypass
validation. See the mes
From: Sowmini Varadhan
Date: Tue, 24 Jan 2017 08:11:49 -0800
> @@ -2685,21 +2685,22 @@ static inline int dev_parse_header(const struct
> sk_buff *skb,
> }
>
> /* ll_header must have at least hard_header_len allocated */
> -static inline bool dev_validate_header(const struct net_device *dev,
The contract between the socket layer and the device is that there
will be at least enough bytes in the non-paged part of the skb to
cover a link layer header, and this is ensured by copying any
application provided L2 header into the skb->data and then invoking
dev_validate_header().
If the appli
18 matches
Mail list logo
