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: <f03958f4-de73-ec43-fa13-02727b6018c3@huawei.com>
Date:   Thu, 27 Jul 2023 15:00:06 +0800
From:   liulongfang <liulongfang@...wei.com>
To:     Oliver Neukum <oneukum@...e.com>,
        Greg KH <gregkh@...uxfoundation.org>
CC:     <linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] USB:bugfix a controller halt error

On 2023/7/26 19:16, Oliver Neukum wrote:
> On 26.07.23 09:18, Greg KH wrote:
>> On Wed, Jul 26, 2023 at 02:44:01PM +0800, liulongfang wrote:
> 
>>> This is a test conducted under a special test scenario.
>>> ECC memory errors are caused by some test tools.
> 
> So we are looking at a corner case here.
> 
> I think we need to step back, get an overview. And I would
> like to apologize for not being entirely helpful.
> 
> I see a theoretical possibility here of what is going wrong
> and an extremely theoretical bug, but it would be very good
> if you could describe your test setup.
> 
> So. You are inducing simulated memory errors.
> For this scenario to make any sense your failure must be
> 
> 1. temporary - that is you have detected memory corruption but the RAM cell is not broken
> 2. unrecoverable - that is we have lost data
> 3. locateable - that is you know it hit the buffer of this operation and only it
> 
> Am I correct so far?
>
You are right about the testing process.
But this problem can exist in the real environment, just the probability of
occurrence is very low.
Use a test tool just to make it easier to trigger it.

> Furthermore your system reports the error to the HC, so that in last
> consequence the transfer fails. Right?
> 
>> What memory is failing, and why does just this single check matter in
>> the whole kernel?
> 
> The difference here is that we are deliberately ignoring errors.
>  
>> If hardware is broken, and failing, it's not the job of the kernel to
>> protect against that, is it?  Shouldn't the ECC memory controller have
>> properly notified the kernel of the fault
> 
> Definitely it should. But this whole discussion makes only sense
> if exactly that happens.
>
Our test tool only simulates that external interference destroys this part
of the data in the buffer on the ECC memory. Even without this testing tool.
This problem may also occur on real business hardware devices.

>> and reset the machine because
>> it is now in an undetermined state?
> 
> No. It is not in an undetermined state if your detection logic is good enough.
> 
>     Regards
>         Oliver
> .
> 
Thanks,
Longfang.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ