linux-kernel - Re: microcode driver newly spews warnings

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: <b647ffbd0904162358t465b97dtf3b41d045fd0d0a9@mail.gmail.com>
Date:	Fri, 17 Apr 2009 08:58:20 +0200
From:	Dmitry Adamushko <dmitry.adamushko@...il.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Jeff Garzik <jeff@...zik.org>, Ingo Molnar <mingo@...e.hu>,
	Peter Oruba <peter.oruba@....com>, amd64-microcode@...64.org,
	Andreas Herrmann <andreas.herrmann3@....com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: microcode driver newly spews warnings

2009/4/17 H. Peter Anvin <hpa@...or.com>:
> Jeff Garzik wrote:
>>>
>>> Jeff, did this do the trick for you?
>>
>> Yes -- but I worry about keeping sysfs files around too long?
>>
>>    Jeff
>
> OK, what isn't clear to me is what the proper return value is in this case.
>  In particular, how with the caller react to mc_sysdev_add() returning a
> nonzero value, but still have the sysdev devices created and retained?
>
> What I would expect happen would be that sysdev_register_driver() would
> return an error and we would unregister the notifier, which really isn't the
> right thing -- if the intent is to keep the sysdev devices around for a
> possible later update then we should presumably return zero there, i.e.
> ignore the return value from microcode_init_cpu(); completely?

sysdev_driver_register() doesn't seem to check return values of ->add
callbacks (mc_sysdev_add() in our case). That's why I also wondered
why in this case the microcode module gets unloaded shortly after
having been loaded (maybe the startup script actually checks the
availability of these sysdev files?)

My first impression is that we shouldn't treat the case when a proper
ucode is not found in the firmware as an error. Say, what is a user
upgrades manually via /dev/microcode later on?

>
>        -hpa
>

-- 
Best regards,
Dmitry Adamushko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/