linux-kernel - Re: Nvidia cable detection problems & ACPI (beware, slight off-top)

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: <20070205224235.GB28048@flower.upol.cz>
Date:	Mon, 5 Feb 2007 23:42:35 +0100
From:	Oleg Verych <olecom@...wer.upol.cz>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Alan <alan@...rguk.ukuu.org.uk>, Allen Martin <AMartin@...dia.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Subject: Re: Nvidia cable detection problems & ACPI (beware, slight off-top)

(i don't know a single bit of details of what i'm writing, so... ;)

Jeff Garzik wrote:
> Alan wrote:
> >>I'm very upset, that hardware nvidia-lego forces system software (and
> >>programmers) to know "unfortunately no standard" ways of desinging
> >>things... One read-only-for-os, hardware set bit in kind of control
> >
> >The hardware doesn't. The BIOS authors do by not setting the cable flags.
> >We actually need to use the STM and GTM methods for PC suspend/resume so
> >it makes sense to see if they will work out in this case too.

Before that. I mean, to let Vendor to choose (and software operate) GPIO
and then to have headache, you've described. Also, here i'm not going
wider, than hardware cabel detection/max speed test (IMHO it must be
pretty easy).

> We also need ACPI, where available, because that's the only way to 
> obtain a BIOS-set hard drive password.

Plain-text passwords -- i don't actually know, if they are useful at all.
What if BIOS has admin/user passwords set?
(kernel: if you have BIOS password, press RESET; if you don't press POWER ;)

> And BIOS vendors often deliver hard drive-specific errata this way, if
> the problem is serious enough (though certainly we would prefer that
> the OS knows about drive errata, when a runtime patch is necessary)

I thought versions, revisions, stepping are indicators of that, and
OS have workarounds, fixes, optimizations, based on that kind of
information. "BIOS vendors", as i read here, are IMHO -bug-in-the-middle-
attack (:

Kind regards, guys.

--
-o--=O`C
 #oo'L O
<___=E M
-
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/