netdev - Re: [PATCH v2] net: sched: Add support for packet bursting.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <B95D6635-02AE-4912-B521-2BECEE16927E@itu.dk>
Date:   Mon, 28 Jun 2021 13:24:08 +0000
From:   Niclas Hedam <nhed@....dk>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
CC:     "stephen@...workplumber.org" <stephen@...workplumber.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Dave Taht <dave.taht@...il.com>
Subject: Re: [PATCH v2] net: sched: Add support for packet bursting.

Thanks for the valuable thoughts, Toke.

The patch started with me being tasked to try and mitigate timing attacks caused by network latencies.
I scouted over the current network stack and didn't find anything that fully matched my use-case.
While I now understand that you can actually leverage the slots functionality for this, I would still opt for a new interface and implementation.

I have not done any CPU benchmarks on the slots system, so I'm not approaching this from the practical performance side per se.
Instead, I argue for seperation with reference to the Seperation of Concern design principle. The slots functionality is not built/designed to cater security guarantees, and my patch is not built to cater duty cycles, etc.
If we opt to merge these two functionalities or discard mine, we have to implement some guarantee that the slots functionality won't become significantly slower or complex, which in my opinion is less maintainable than two similar systems. Also, this patch is very limited in lines of code, so maintaining it is pretty trivial.

I do agree, however, that we should define what would happen if you enable both systems at the same time.

@Dave: Any thoughts on this?

> On 28 Jun 2021, at 14:21, Toke Høiland-Jørgensen <toke@...hat.com> wrote:
> 
> Niclas Hedam <nhed@....dk> writes:
> 
>>>> From 71843907bdb9cdc4e24358f0c16a8778f2762dc7 Mon Sep 17 00:00:00 2001
>>>> From: Niclas Hedam <nhed@....dk>
>>>> Date: Fri, 25 Jun 2021 13:37:18 +0200
>>>> Subject: [PATCH] net: sched: Add support for packet bursting.
>>> 
>>> Something went wrong with the formatting here.
>> 
>> I'll resubmit with fixed formatting. My bad.
>> 
>>>> 
>>>> This commit implements packet bursting in the NetEm scheduler.
>>>> This allows system administrators to hold back outgoing
>>>> packets and release them at a multiple of a time quantum.
>>>> This feature can be used to prevent timing attacks caused
>>>> by network latency.
>>> 
>>> How is this bursting feature different from the existing slot-based
>>> mechanism?
>> 
>> It is similar, but the reason for separating it is the audience that they are catering.
>> The slots seems to be focused on networking constraints and duty cycles.
>> My contribution and mechanism is mitigating timing attacks. The
>> complexity of slots are mostly unwanted in this context as we want as
>> few CPU cycles as possible.
> 
> (Adding Dave who wrote the slots code)
> 
> But you're still duplicating functionality, then? This has a cost in
> terms of maintainability and interactions (what happens if someone turns
> on both slots and bursting, for instance)?
> 
> If the concern is CPU cost (got benchmarks to back that up?), why not
> improve the existing mechanism so it can be used for your use case as
> well?
> 
> -Toke