linux-kernel - Re: [PATCH v2] fpga: altera-cvp: Truncated bitstream error support

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] [day] [month] [year] [list]

Message-ID: <20220627085255.GA2264502@yilunxu-OptiPlex-7050>
Date:   Mon, 27 Jun 2022 16:52:55 +0800
From:   Xu Yilun <yilun.xu@...el.com>
To:     tien.sung.ang@...el.com
Cc:     christophe.jaillet@...adoo.fr, hao.wu@...el.com,
        linux-fpga@...r.kernel.org, linux-kernel@...r.kernel.org,
        mdf@...nel.org, trix@...hat.com
Subject: Re: [PATCH v2] fpga: altera-cvp: Truncated bitstream error support

On Mon, Jun 27, 2022 at 03:45:53PM +0800, tien.sung.ang@...el.com wrote:
> > > Though without doubt, your solution is doable, I have a 
> > > discussion with the Intel architect and they insisted that
> > > the device driver must not make such a decision. The decision to 
> > > drop or accept a transfer is up to the firmware. The firmware
> 
> > Why dropping or accepting is forbidden, but padding is allowed? If the
> > decision is no operation to the data, then padding should also be
> > forbidden.
> 
> > > insisted that the buffer be padded with whatever value. They
> 
> > If I understand right, the 2 decisions are conflicted. On one hand,
> > the driver should not care about the data. On another hand, the
> > driver should still care about the data for some rule.
> 
> > So please firstly reach your agreement before making patches.
> 
> Had some delays in replying,from the perspective of the driver, 
> Intel architects want it to be just purely on the transfer of 
> data without inspecting the data. 
> If the size of a transfer is 4096bytes, we can padd it. 
> I can do that which I think it is not an issue.
> Let me create a reworked patch to pad the payload with Zeros.

No, it's not about padding with Zeros or other values. If we should
stick on no image touching, then please fix the firmware. If we need
a workaround in driver, then making a decent fix. Blindly copy the image
is just a bad idea, and it could actually be avoided.

Thanks,
Yilun

> Would this be OK for patch v3?
> 
> > > Yes, it could look confusing to other programmers. And, yes, the 
> > > padding doesn't matter. Let me relook into this. As the driver is 
> > > already re-tested by the silicon validatioin. 
> > > I want to avoid making any change as it
> > > would meant another couple of weeks of re-testing. 
> > > Can this be accepted as it is?
> 
> > Sorry, I can't. Some clarification is needed.
> 
> Reply as above, let us implement the padding in the
> next patch v3. Appreciate your inputs. Thanks