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]
Date:   Fri, 12 Apr 2019 12:07:41 -0400
From:   Lucas Bates <lucasb@...atatu.com>
To:     Nicolas Dichtel <nicolas.dichtel@...nd.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Marcelo Ricardo Leitner <mleitner@...hat.com>,
        Vlad Buslov <vladbu@...lanox.com>,
        Davide Caratti <dcaratti@...hat.com>, kernel@...atatu.com
Subject: Re: [RFC net-next 1/1] tdc.py: Introduce required plugins

On Fri, Apr 12, 2019 at 11:42 AM Nicolas Dichtel
<nicolas.dichtel@...nd.com> wrote:
>
> Le 12/04/2019 à 17:21, Lucas Bates a écrit :
> > On Fri, Apr 12, 2019 at 4:31 AM Nicolas Dichtel
> > <nicolas.dichtel@...nd.com> wrote:
> >>> in our tri-weekly tc test meeting and the general consensus to address
> >>> what you brought up is leaning towards the following:
> >>>
> >>> - adding a symlink to nsPlugin
> >> I don't understand why a symlink is needed. Just load it by default and use it
> >> when needed. A property can be added to each test to tell which plugin (in fact,
> >> which topology) is needed to run it.
> >> Thus, if a new complex test is added, it can define another topology.
> >
> > I'm loathe to hard-code it into the script, but we can avoid the
> > symlink if we specify some default plugins to load in the
> > tdc_config.py file.
> Why is it a problem to specify the plugin in the test description? The fw tests
> depend on a specific topology, thus it's better explicitly state that.

So something like this?  Note the usage of the keyword "requires",

    {
        "id": "901f",
        "name": "Add fw filter with prio at 32-bit maxixum",
        "category": [
            "filter",
            "fw"
        ],
        "requires": ["nsPlugin"],
        "setup": [
            "$TC qdisc add dev $DEV1 ingress"
        ],
        "cmdUnderTest": "$TC filter add dev $DEV1 parent ffff: handle
1 prio 65535 fw action ok",
        "expExitCode": "0",
        "verifyCmd": "$TC filter get dev $DEV1 parent ffff: handle 1
prio 65535 protocol all fw",
        "matchPattern": "pref 65535 fw.*handle 0x1.*gact action pass",
        "matchCount": "1",
        "teardown": [
            "$TC qdisc del dev $DEV1 ingress"
        ]
    },


> >
> >>> - Changing default behaviour so that unless an option is explicitly
> >>> specified, all the tests will be run under a namespace with automatic
> >>> creation of the ports
> >> Yes.
> >>
> >>> - If the user chooses /not/ to use namespaces, it will still create
> >>> the veth pair to use.
> >> In fact, I would say an option so that the user can choose another topology.
> >
> > Quite possibly, but for traffic generation (upcoming using scapy)
> > we're just reusing the simple topology right now.
> I was thinking you were arguing for this option. If nobody need it, let's just
> remove it.
>
> >
> >>>> After your patch, I got the following error:
> >>>> $ ./tdc.py
> >>>> Traceback (most recent call last):
> >>>>   File "./tdc.py", line 740, in <module>
> >>>>     main()
> >>>>   File "./tdc.py", line 734, in main
> >>>>     set_operation_mode(pm, args)
> >>>>   File "./tdc.py", line 692, in set_operation_mode
> >>>>     check_required_plugins(pm, alltests)
> >>>>   File "./tdc.py", line 583, in check_required_plugins
> >>>>     os.chown('plugins/{}'.format(fname), uid=int(os.getenv('SUDO_UID')),
> >>>> TypeError: int() argument must be a string or a number, not 'NoneType'
> >>>
> >>> That would be expected if you aren't running tdc with sudo or as root
> >>> or as a user with network admin capability.
> >> I was root for the test.
> >
> > Ah. That environment variable is probably not present on your system.
> > Out of curiosity, what shell/distribution are you using?
> >
> It was on a debian 8.11 / bash.
>

Thanks. I'll look into it later.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ