linux-kernel - Re: CONFIG_BREAK_MY

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:	Thu, 17 May 2007 10:32:02 +0200
From:	Hans de Goede <j.w.r.degoede@....nl>
To:	Jean Delvare <khali@...ux-fr.org>
CC:	Pavel Machek <pavel@....cz>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: CONFIG_BREAK_MY_MACHINE

Jean Delvare wrote:
> On Tue, 15 May 2007 20:31:00 +0000, Pavel Machek wrote:
>> Hi!
>>
>>>> Hardware Monitoring support  --->
>>>>   <*> Hardware Monitoring support
>>>>   <*> Abit uGuru
>>>>   <M> VIA686A
>>>>   <*> IBM Hard Drive Active Protection System (hdaps)
>>>>
>>>> But I'm quite sure that the only module used is VIA686A (I'm
>>>> rebuilding to confirm).
>>> This is a rather bad idea to build the abituguru and hdaps drivers into
>>> your kernel if you don't have these devices. Especially abituguru, as
>>> it does arbitrary port probing.
>> hdaps should be safe (DMI based whitelist, no?)
> 
> Correct.
> 
>> If abitguru breaks random machines, we probably should DMI whitelist,
>> too.
> 
> I never said it was breaking machines, just that it was accessing
> arbitrary I/O ports.
> 
> This was already discussed with the driver's author (Hans de Goede,
> Cc'd) and I think we agreed on the principle, but it didn't happen yet.
> This device only exists on Abit motherboards so it would be easy enough
> to check the DMI vendor. A more detailed white list is also possible,
> but I'm not insisting on it.
> 
> The driver could also be made to depend on X86, as this is the only
> architecture where it is useful.
> 
> Hans, can you please submit a patch doing this?
> 

As you can see from the CC I've send you, I've just mailed my private army of 
testers / known uguru users, requesting them to send me the output of dmidecode 
on their uguru mobo's. Once I have this info, I'll see if there is some 
consistency in the manufacturer DMI field.

I've mailed them, since the DMI info is needed anyways to put uguru detection 
in sensors-detect, but I'm not sure I want to add this to the driver too. Many 
other ISA drivers do io probe's too, if a users decides to start loading random 
drivers, he is asking for problems, should we really even try to protect 
against this?

Regards,

Hans

-
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/