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]
Date:	Tue, 1 Dec 2015 11:41:53 +0100
From:	"Wilck, Martin" <martin.wilck@...fujitsu.com>
To:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tpmdd-devel@...ts.sourceforge.net" 
	<tpmdd-devel@...ts.sourceforge.net>
Subject: Re: [PATCH] base/platform: fix panic when probe function is NULL

Hello Uwe,

> This sounds like a separate issue though. Looking at init_tis there is:
> 
>         rc = platform_driver_register(&tis_drv);
>         if (rc < 0)
>                 return rc;
>         pdev = platform_device_register_simple("tpm_tis", -1, NULL, 0);
>         if (IS_ERR(pdev)) {
>                 rc = PTR_ERR(pdev);
>                 goto err_dev;
>         }
>         rc = tpm_tis_init(&pdev->dev, &tis_default_info, NULL);
> 
> tpm_tis_init calls tpmm_chip_alloc which barfs when pdev (i.e. the return value
> of platform_device_register_simple above) isn't bound. It is not allowed
> to assume that the device is bound after the above function calls.

Can you please explain again why you think that assumption is invalid? 
As far as I understand the code, the assumption would be correct in
4.3.0 and earlier:

platform_driver_register() registers a platform driver with name
"tpm_tis". platform_device_register_simple() registers a device with the
same name. This will call platform_device_add()/device_add() and start
probing for a platform device. Platform bus probing in platform_match()
falls back to a simple match between driver and device name if all else
fails. That match succeeds for the "tpm_tis" driver. Thus
driver_probe_device() will be called, and in the absence of a
driver-specific probe routine, will succeed. Thus after
platform_device_register_simple() returns, device and driver will be
bound. This matches also actual behavior of the pre-4.4 code. 

Please explain what I am overlooking. I am just trying to understand.
As far as tpm_tis is concerned, Jason's current patch set is going to
fix this for good anyway.

Regards
Martin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ