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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 5 Oct 2022 12:09:07 +0200
From:   Petr Machata <>
To:     <>
CC:     <>, <>,
        <>, <>,
        <>, <>,
        <>, <>,
        <>, <>,
        <>, <>,
        <>, <>,
        <>, <>,
Subject: Re: [PATCH net-next v2 1/6] net: dcb: add new pcp selector to app

<> writes:

> Den Mon, Oct 03, 2022 at 10:22:48AM +0200 skrev Petr Machata:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>> <> writes:
>> > Right, I see your point. But. First thought; this starts to look a little
>> > hackish.
>> So it is. That's what poking backward compatible holes in an existing
>> API gets you. Look at modern C++ syntax for an extreme example :)
>> But read Jakub's email. It looks like we don't actually need to worry
>> about this.
>> > Looking through the 802.1Q-2018 std again, sel bits 0, 6 and 7 are
>> > reserved (implicit for future standard implementation?). Do we know of
>> > any cases, where a new standard version would introduce new values beyond
>> > what was reserved in the first place for future use? I dont know myself.
>> >
>> > I am just trying to raise a question of whether using the std APP attr
>> > with a new high (255) selector, really could be preferred over this new
>> > non-std APP attr with new packed payload.
>> Yeah. We'll need to patch lldpad anyway. We can basically choose which
>> way we patch it. And BTW, using the too-short attribute payload of
>> course breaks it _as well_, because they don't do any payload size
>> validation.
> Right, unless we reconstruct std app entry payload from the "too-short"
> attribute payload, before adding it the the app list or passing it to the 
> driver.

The issue is not in drivers, but in lldpad itself. They just iterate the
attribute stream, assume that everything is an APP, and treat is as
such, not even validating the length (I mean, why would they, it's
supposed to be an APP after all...).

So we trip lldpad however we set the API up.

So let's trip it in a way that makes for a reasonable API.

> Anyway. Considering Jakub's mail. I think this patch version with a non-std
> attribute to do non-std app table contributions separates non-std from std
> stuff nicely and is preffered over just adding the new selector. So if we can 
> agree on this, I will prepare a new v. with the other changes suggested.
> Wrt. lldpad we can then patch it to react on attrs or selectors > 7.

Yep, agreed.

Powered by blists - more mailing lists