linux-kernel - Re: [PATCH net-next 0/2] GCPS Spec Compliance Patch Set

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: <93ac7481-43c0-4207-8965-2d793c90263c@gmail.com>
Date: Tue, 8 Apr 2025 16:23:43 -0700
From: Hari Kalavakunta <kalavakunta.hari.prasad@...il.com>
To: Paul Fertser <fercerpav@...il.com>
Cc: Sam Mendoza-Jonas <sam@...dozajonas.com>, davem@...emloft.net,
 edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, horms@...nel.org,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org, npeacock@...a.com,
 akozlov@...a.com
Subject: Re: [PATCH net-next 0/2] GCPS Spec Compliance Patch Set

On 4/8/2025 3:35 PM, Paul Fertser wrote:
> On Tue, Apr 08, 2025 at 03:02:14PM -0700, Hari Kalavakunta wrote:
>> On 4/8/2025 12:19 PM, Paul Fertser wrote:
>>
>>> In other words, you're testing your code only with simulated data so
>>> there's no way to guarantee it's going to work on any real life
>>> hardware (as we know hardware doesn't always exactly match the specs)?
>>> That's unsettling. Please do mention it in the commit log, it's an
>>> essential point. Better yet, consider going a bit off-centre after the
>>> regular verification and do a control run on real hardware.
>>>
>>> After all, that's what the code is for so if it all possible it's
>>> better to know if it does the actual job before merging (to avoid
>>> noise from follow-up patches like yours which fix something that never
>>> worked because it was never tested).
>>
>> I would like to request a week's time to integrate a real hardware
>> interface, which will enable me to test and demonstrate end-to-end results.
>> This will also allow me to identify and address any additional issues that
>> may arise during the testing process. Thank you for the feedback.
> 
> Thank you for doing the right thing! Looking forward to your updated
> patch (please do not forget to consider __be64 for the fields).

I had not previously considered using __be64 for the struct 
ncsi_rsp_gcps_pkt, as it is an interface structure. I would like to seek 
your input on whether it is a good idea to use __be64 for interface 
messages. In my experience, I haven't come across implementations that 
utilize __be64. I am unsure about the portability of this approach, 
particularly with regards to the Management Controller (MC).