Message-ID: <893a2e55bef04d5dbb9ffa99efdbb023@MAIL-MBX-cwP12.dji.com>
Date:   Thu, 30 Dec 2021 04:41:47 +0000
From:   wigin zeng <wigin.zeng@....com>
To:     Greg KH <gregkh@...uxfoundation.org>
CC:     "jirislaby@...nel.org" <jirislaby@...nel.org>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        First Light <xiaoguang.chen@....com>
Subject: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] serial: 8250: add lock for dma rx

>> On our platform, UART connected to a MCU which will send data of variable length from time to time. There is no definition of a maximum transmission length.
> >We configured DMA block size is 4096bytes, however, there are more 
> >than 4100 bytes input, DMA just handled 4096bytes and left bytes in FIFO cannot trigger next DMA Transfer done interrupt(left bytes number < DMA block size ), so these data should be processed by UART IRQ.

>That is a broken hardware design and will not work with any operating system.

Do you mean the data size of UART input must be smaller than DMA configured RX block size? If not, there is risk to cause panic with current driver.
We cannot limit the length of data sent by an external device at a time. No matter how much data input externally, we should ensure system not crash, this patch achieves this goal.

BRs
Weijun
-----邮件原件-----
发件人: Greg KH [mailto:gregkh@...uxfoundation.org] 
发送时间: 2021年12月20日 18:41
收件人: wigin zeng <wigin.zeng@....com>
抄送: jirislaby@...nel.org; linux-serial@...r.kernel.org; linux-kernel@...r.kernel.org; First Light <xiaoguang.chen@....com>
主题: Re: 答复: 答复: 答复: 答复: 答复: [PATCH] serial: 8250: add lock for dma rx

【EXTERNAL EMAIL】 DO NOT CLICK any links or attachments unless you can make sure both the sender and the content are trustworthy.


【外部邮件提醒】以下邮件来源于公司外部，请勿点击链接或附件，除非您确认邮件发件人和内容可信。



On Mon, Dec 20, 2021 at 10:25:51AM +0000, wigin zeng wrote:
> On Mon, Dec 20, 2021 at 09:44:04AM +0000, wigin zeng wrote:
> > > >That makes no sense, as what orders the data coming in?  The 2 bytes could be added to the tty buffer before the 512 bytes, or the other way around.
> >
> > > >What hardware are you using that is mixing dma and irq data like this?
> > > >That feels very wrong.
> >
> > >It is not normal case, normally, the input size should smaller than DMA block size and DMA complete the whole copy.
> > >However, there are some abnormal situations. The external input is unexpectedly larger than the data length of the DMA configuration. This situation in my example will appear, and it may cause the kernel to panic.
>
> >You did not answer my question about hardware type :(
>
> >And again, how is this happening?  If you use DMA, all data should be coming through DMA and not the irq.  Otherwise crazy stuff like this will happen in any type of driver, your hardware can not mix this type of stuff up.
>
> On our platform, UART connected to a MCU which will send data of variable length from time to time. There is no definition of a maximum transmission length.
> We configured DMA block size is 4096bytes, however, there are more 
> than 4100 bytes input, DMA just handled 4096bytes and left bytes in FIFO cannot trigger next DMA Transfer done interrupt(left bytes number < DMA block size ), so these data should be processed by UART IRQ.

That is a broken hardware design and will not work with any operating system.

> In other word, if the external use UART "vulnerability" to attack the system, we need to ensure that the system not crash at least, right?

So you are saying that Linux now treat all hardware that has DMA functionality as a potential threat?  That is not a model that Linux, or any other operating system, has ever had to support before, please do not make up new rules here and expect Linux to automatically support them without a lot of redesign and work.

If you wish to protect Linux from this type of untrusted hardware, please do the work to do so.  This patch is not that work.

> >How can flow control handle this at all?  Flow control is at the serial data stream level.  This is confusing the PCI data stream order.
>
> I just think more logic is needed to control the order of data processing by DMA and UART IRQ to keep the integrity of serial data.
> But the specific design, I haven't considered yet, the first goal is the keep the system alive.

Again, this is a broken hardware design, please fix that first.

thanks,

greg k-h
This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

此电子邮件及附件所包含内容具有机密性，且仅限于接收人使用。未经允许，禁止第三人阅读、复制或传播该电子邮件中的任何信息。如果您不属于以上电子邮件的目标接收者，请您立即通知发送人并删除原电子邮件及其相关的附件。

Powered by blists - more mailing lists