Is it possible to write a kernel module which, when loaded, will blow the PC
speaker?
On Jun 12 2007 08:45, R.F. Burns wrote:
>
> Is it possible to write a kernel module which, when loaded, will blow the PC
> speaker?
Define blow.
(As in "damage"?)
Jan
--
On 6/12/07, Jan Engelhardt <[email protected]> wrote:
>
> On Jun 12 2007 08:45, R.F. Burns wrote:
> >
> > Is it possible to write a kernel module which, when loaded, will blow the PC
> > speaker?
>
> Define blow.
> (As in "damage"?)
Yes. As in, blow it out/damage it so that it is no longer usable.
On Jun 12 2007 09:54, R.F. Burns wrote:
> On 6/12/07, Jan Engelhardt <[email protected]> wrote:
>> On Jun 12 2007 08:45, R.F. Burns wrote:
>> > Is it possible to write a kernel module which, when loaded, will blow the
>> > PC
>> > speaker?
>>
>> Define blow.
>> (As in "damage"?)
>
> Yes. As in, blow it out/damage it so that it is no longer usable.
I'd say impossible. Just disconnect it from the motherboard.
Jan
--
On 6/12/07, R.F. Burns <[email protected]> wrote:
> Is it possible to write a kernel module which, when loaded, will blow the PC
> speaker?
LOL. May I ask what your use case is?
Lee
On Jun 12 2007 15:57, Jan Engelhardt wrote:
>On Jun 12 2007 09:54, R.F. Burns wrote:
>> On 6/12/07, Jan Engelhardt <[email protected]> wrote:
>>> On Jun 12 2007 08:45, R.F. Burns wrote:
>
>>> > Is it possible to write a kernel module which, when loaded, will blow the
>>> > PC
>>> > speaker?
>>>
>>> Define blow.
>>> (As in "damage"?)
>>
>> Yes. As in, blow it out/damage it so that it is no longer usable.
>
>I'd say impossible. Just disconnect it from the motherboard.
The days when hardware *relied* on software (hence, where software
could damage hardware) are over.
Jan
--
> >I'd say impossible. Just disconnect it from the motherboard.
>
> The days when hardware *relied* on software (hence, where software
> could damage hardware) are over.
Nice theory but you can destroy or render useless a fair amount of PC
hardware via software, usually because the thing is *DESIGNED* that way
for convenience. (Flash update interfaces without jumpers, locking
interfaces for drives etc)
On Jun 12 2007 16:19, Alan Cox wrote:
>
>> >I'd say impossible. Just disconnect it from the motherboard.
>>
>> The days when hardware *relied* on software (hence, where software
>> could damage hardware) are over.
>
>Nice theory but you can destroy or render useless a fair amount of PC
>hardware via software, usually because the thing is *DESIGNED* that way
>for convenience. (Flash update interfaces without jumpers, locking
>interfaces for drives etc)
Let's just say the PC speaker was not designed to be proactively be destroyed.
Jan
--
Lee Revell wrote:
> On 6/12/07, R.F. Burns <[email protected]> wrote:
>> Is it possible to write a kernel module which, when loaded, will blow
>> the PC
>> speaker?
>
> LOL. May I ask what your use case is?
>
or isn't it mis-use case :)
> Lee
-jb
--
Tact is the art of making a point without making an enemy.
> > >I'd say impossible. Just disconnect it from the motherboard.
> >
> > The days when hardware *relied* on software (hence, where software
> > could damage hardware) are over.
> Nice theory but you can destroy or render useless a fair amount of PC
> hardware via software, usually because the thing is *DESIGNED* that way
> for convenience. (Flash update interfaces without jumpers, locking
> interfaces for drives etc)
Other great examples are hardware that allows you to control voltages, fan
speeds, and operating frequencies. Sometimes you can overvoltage it directly
and blow it immediately. Other times, you can increase the voltage and
operating frequency and decrease the fan speed to the point where it stops
spinning. This is possible on many modern graphics cards and CPUs.
As far as burning out a speaker goes, if you can drop the frequency to zero
(DC) and get continuous current through the speaker, that could burn it out.
This makes several assumptions, many of which may not be true on modern PCs:
1) It assumes the speaker is a conventional coil speaker, not a piezo
element. (This is certainly true on some PCs, although it's increasingly
false on newer PCs.)
2) It assumes the speaker is DC driven. (I'm pretty sure this was true on
the original IBM PC. Not sure about newer computers.)
3) It assumes you can configure the circuitry that drives the speaker such
that it will stay on. (No idea.)
4) It assumes the current will be sufficient to burn out the speaker. (I
know it will get very hot on older machines, whether it will burn out --
might even depend on the exact speaker model.)
On at least some older computers, you could burn out the hardware that drove
the speaker this way. I think it was either the Pet or the Apple ][ (didn't
work on all machines, depended on how much current the speaker drew and
other odd factors). I witnessed an Apple ][e blow out an I/O chip when it
crashed with an output (that was supposed to be pulsed) left in the on
position.
DS
On 6/12/07, Lee Revell <[email protected]> wrote:
> On 6/12/07, R.F. Burns <[email protected]> wrote:
> > Is it possible to write a kernel module which, when loaded, will blow the PC
> > speaker?
>
> LOL. May I ask what your use case is?
I am helping a small school system with a number of Linux
workstations. Previously, the students (middle and high schools)
abused the sound cards in the systems. This was remedied by changing
the permissions on sound devices so that non-root users would be
denied access (something easily done remotely, and on an automated
basis.)
At that point, the students started finding creative ways to abuse the
PC speaker, which became rather distracting. We unloaded and disabled
the PC speaker kernel module, which remedied the situation for a
while.
However, over the past several weeks, the students have found more
creative ways to abuse the PC speaker (outside of the OS.) The Powers
that Be are asking that the PC speakers be disabled completely. With
the small number of techs we have, it would be very impractical to go
around to all systems and remove the PC speaker from each and every
computer case.
So, the idea was raised about seeing if there was a way to blow the PC
speaker by loading a kernel module. If so, a mass-deployment of a
kernel module overnight would take care of the PC speaker problem once
and for all.
On Jun 12 2007 13:08, David Schwartz wrote:
>
>As far as burning out a speaker goes, if you can drop the frequency to zero
>(DC) and get continuous current through the speaker, that could burn it out.
>This makes several assumptions, many of which may not be true on modern PCs:
>
>1) It assumes the speaker is a conventional coil speaker, not a piezo
>element. (This is certainly true on some PCs, although it's increasingly
>false on newer PCs.)
>
>2) It assumes the speaker is DC driven. (I'm pretty sure this was true on
>the original IBM PC. Not sure about newer computers.)
Most likely. AC is hardly any good inside a computer :)
>3) It assumes you can configure the circuitry that drives the speaker such
>that it will stay on. (No idea.)
A crystal will drive the frequency, which can be set with outb(0x42).
Whether the crystal's oscillating signal is connected to the speaker
can be controlled with outb(0x61) IIRC [or just see
drivers/input/misc/pcspkr.c].
>4) It assumes the current will be sufficient to burn out the speaker. (I
>know it will get very hot on older machines, whether it will burn out --
>might even depend on the exact speaker model.)
Since you can set the x86's crystals frequency from 1193182 to 18 Hz
(PIT_TICK_RATE / 1 to PIT_TICK_RATE / 65535) [*], you can never really
bust it. But even then, what would a speaker do it was constanly given
+5V? (I _suppose_ the other level is 0V, not -5V -- makes for easy
design.) That's IMO just like a sound file with volume(x) = 1, nothing
spectacular if you ask me.
[*] The line "if (value > 20 && value < 32767) in pcspkr.c looks a bit bogus.
>On at least some older computers, you could burn out the hardware that
>drove the speaker this way. I think it was either the Pet or the Apple
>][ (didn't work on all machines, depended on how much current the
>speaker drew and other odd factors). I witnessed an Apple ][e blow out
>an I/O chip when it crashed with an output (that was supposed to be
>pulsed) left in the on position.
Jan
--
On Jun 12 2007 16:25, R.F. Burns wrote:
>
> However, over the past several weeks, the students have found more
> creative ways to abuse the PC speaker (outside of the OS.) The Powers
> that Be are asking that the PC speakers be disabled completely. With
> the small number of techs we have, it would be very impractical to go
> around to all systems and remove the PC speaker from each and every
> computer case.
But you only have to do it once anyway.
> So, the idea was raised about seeing if there was a way to blow the PC
> speaker by loading a kernel module. If so, a mass-deployment of a
> kernel module overnight would take care of the PC speaker problem once
> and for all.
And once you need a speaker (BIOS beep codes come to mind), you don't have any.
Jan
--
R.F. Burns schrieb:
> On 6/12/07, Lee Revell <[email protected]> wrote:
>> On 6/12/07, R.F. Burns <[email protected]> wrote:
>> > Is it possible to write a kernel module which, when loaded, will
>> blow the PC
>> > speaker?
>>
>> LOL. May I ask what your use case is?
>
> I am helping a small school system with a number of Linux
> workstations. Previously, the students (middle and high schools)
> abused the sound cards in the systems. This was remedied by changing
> the permissions on sound devices so that non-root users would be
> denied access (something easily done remotely, and on an automated
> basis.)
> [...]
*smile*
What about denying students permissions to change all unwanted
<foo> on the system? They propably don't need to be root.
> At that point, the students started finding creative ways to abuse the
> PC speaker, which became rather distracting. We unloaded and disabled
> the PC speaker kernel module, which remedied the situation for a
> while.
Disable kernel modules at all. Compile in what you need, and kick
out all unwanted stuff. Disable booting from anything else than
harddisk or network...
[OT on]
> So, the idea was raised about seeing if there was a way to blow the PC
> speaker by loading a kernel module. If so, a mass-deployment of a
> kernel module overnight would take care of the PC speaker problem once
> and for all.
A speaker is basically an inductor. Together with the driving circuit,
it may form a resonant circuit. If you drive it exactly with the resonant
frequency[1], you might be able to overheat it. But take care, not to
burn your CPU too, when you reach microwave frequencies and get electromagnetic
waves reflected in the computer's case. Cross-check with Maxwell's
equations! ;-)
OTOH the students propably learn more in hacking a linux system than in any
other lesson. Tell them that the first one gets an A who can get real speech
output working on the PC speaker.
[1] http://en.wikipedia.org/wiki/Resonant_frequency
[OT off]
Good luck,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Stra?e 45/1
Linhof Werksgel?nde
D-81379 M?nchen
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
> So, the idea was raised about seeing if there was a way to blow the PC
> speaker by loading a kernel module. If so, a mass-deployment of a
> kernel module overnight would take care of the PC speaker problem once
> and for all.
No way. None of the conceivable ways of burning out hardware are
sufficiently safe to intentionally mass employ them like this. If you could
overload the coil, the only imaginable way to burn out a speaker, it could
start a fire. This risk is at least significant enough that it's easier to
open the case than take it.
DS
Jan Engelhardt wrote:
> Since you can set the x86's crystals frequency from 1193182 to 18 Hz
> (PIT_TICK_RATE / 1 to PIT_TICK_RATE / 65535) [*], you can never really
> bust it. But even then, what would a speaker do it was constanly given
> +5V? (I _suppose_ the other level is 0V, not -5V -- makes for easy
> design.) That's IMO just like a sound file with volume(x) = 1, nothing
> spectacular if you ask me.
>
I guess a motherboard don't provide enough current to
burn out that speaker.
But generally, speakers that handle some maximum
alternating current *will* burn out if you give them
the same amount DC. This becasue speakers
are designed to handle AC - some of the energy is dissipated
as sound waves, some as an alternating magnetic field,
some has heat. And the speaker moves, so moving
air helps cooling it.
A speaker getting DC converts all that current into heat only,
and it stands still so no extra cooling. So it burns out.
Helge Hafting
On Tue, 12 Jun 2007, Jan Engelhardt wrote:
> >4) It assumes the current will be sufficient to burn out the speaker. (I
> >know it will get very hot on older machines, whether it will burn out --
> >might even depend on the exact speaker model.)
>
> Since you can set the x86's crystals frequency from 1193182 to 18 Hz
> (PIT_TICK_RATE / 1 to PIT_TICK_RATE / 65535) [*], you can never really
> bust it. But even then, what would a speaker do it was constanly given
I am fairly sure you have a choice between a steady low and a steady high
level on the speaker output available if you switch the 8254 to the right
single-shot mode. In case you have not been into such details -- the 8254
offers six modes of operation, selected for each channel separately, of
which only two are periodic.
Maciej
Maciej W. Rozycki wrote:
> On Tue, 12 Jun 2007, Jan Engelhardt wrote:
>
>>> 4) It assumes the current will be sufficient to burn out the speaker. (I
>>> know it will get very hot on older machines, whether it will burn out --
>>> might even depend on the exact speaker model.)
>> Since you can set the x86's crystals frequency from 1193182 to 18 Hz
>> (PIT_TICK_RATE / 1 to PIT_TICK_RATE / 65535) [*], you can never really
>> bust it. But even then, what would a speaker do it was constanly given
>
> I am fairly sure you have a choice between a steady low and a steady high
> level on the speaker output available if you switch the 8254 to the right
> single-shot mode. In case you have not been into such details -- the 8254
> offers six modes of operation, selected for each channel separately, of
> which only two are periodic.
Can we please stop this non-sense thread? Anyone designing the speaker
circuit would certainly place a small capacitor in series with the
speaker to kill the DC component of the signal.
Since the speaker itself wouldn't be able to play very low frequencies
anyway, the capacitor wouldn't have to be that big.
So I'm pretty sure that on any half-way decent piece of hardware, you
won't be able to kill the speaker with software...
--
Paulo Marques - http://www.grupopie.com
"Don't hit a man when he's down -- kick him; it's easier."
> So, the idea was raised about seeing if there was a way to blow the PC
> speaker by loading a kernel module. If so, a mass-deployment of a
> kernel module overnight would take care of the PC speaker problem once
> and for all.
Sounds as though the problem has more to do with the students than the
hardware. The Powers That Be are chasing symptoms, as opposed to the
disease.
The real questions center around how to point the creativity on
display away from abusing speakers and towards something useful.
--
Christopher Smith
Pursuer of knowledge
Hi!
> > > >I'd say impossible. Just disconnect it from the motherboard.
> > >
> > > The days when hardware *relied* on software (hence, where software
> > > could damage hardware) are over.
>
> > Nice theory but you can destroy or render useless a fair amount of PC
> > hardware via software, usually because the thing is *DESIGNED* that way
> > for convenience. (Flash update interfaces without jumpers, locking
> > interfaces for drives etc)
>
> Other great examples are hardware that allows you to control voltages, fan
> speeds, and operating frequencies. Sometimes you can overvoltage it directly
> and blow it immediately. Other times, you can increase the voltage and
> operating frequency and decrease the fan speed to the point where it stops
> spinning. This is possible on many modern graphics cards and CPUs.
Not true for cpus; try it before spreading FUD. Thermal protection
will kill the machine when cpu goes over 95C or so.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Jun 13, 2007, at 15:53:30, Pavel Machek wrote:
>> Other great examples are hardware that allows you to control
>> voltages, fan speeds, and operating frequencies. Sometimes you can
>> overvoltage it directly and blow it immediately. Other times, you
>> can increase the voltage and operating frequency and decrease the
>> fan speed to the point where it stops spinning. This is possible
>> on many modern graphics cards and CPUs.
>
> Not true for cpus; try it before spreading FUD. Thermal protection
> will kill the machine when cpu goes over 95C or so.
Well, sorta. Things tend to die early heat deaths if you repeatedly
spike the temperature (different rates of thermal expansion and all
that jazz). If you alternated repeatedly between max-CPU/no-fan and
no-CPU/max-fan, staying just within the thermal kill limits and
spending 3/4 of the time at near max temp, you'd probably have a 30%
chance to kill an average CPU within a couple weeks.
I know when designing the G5 CPU, IBM had to be _really_ careful
about the variably high operating temperature. Their first few
designs ended up having BGA breakdown well before the desired
lifetime due to thermal creep (long-duration at high temp) and
fatigue shear failure (alternation between high and low temp).
There's a paper somewhere on the web about the whole deal.
Cheers,
Kyle Moffett
R.F. Burns wrote:
> However, over the past several weeks, the students have found more
> creative ways to abuse the PC speaker (outside of the OS.) The Powers
> that Be are asking that the PC speakers be disabled completely. With
> the small number of techs we have, it would be very impractical to go
> around to all systems and remove the PC speaker from each and every
> computer case.
Now I am curious; how are they getting the pc speaker to make any sound
with the kernel module disabled?
Also there is a very simple solution to your problem. When a student
abuses the computer, take a yardstick ( there should be one in any
classroom ), approach said student from behind, and break said yardstick
over their ass. Or you could just ban them from using the computers
again.
On Jun 15 2007 13:07, Phillip Susi wrote:
> R.F. Burns wrote:
>> However, over the past several weeks, the students have found more
>> creative ways to abuse the PC speaker (outside of the OS.) The Powers
>> that Be are asking that the PC speakers be disabled completely. With
>> the small number of techs we have, it would be very impractical to go
>> around to all systems and remove the PC speaker from each and every
>> computer case.
>
> Now I am curious; how are they getting the pc speaker to make any sound with
> the kernel module disabled?
ioperm(), inb(), and outb() from userspace. Needs root, though. Or
/dev/port, with write. Which comes to the question how they gained root.
Perhaps live cd? In which case, the OP should, as recommended in this
thread already, deactivate choosing boot devices, if that's possible.
(Unfortunately, newer BIOSes with 'integrated bootmenu' with F8 or so,
but I have not seen a way to deactivate _that_ menu.)
Jan
--
Jan Engelhardt wrote:
> On Jun 15 2007 13:07, Phillip Susi wrote:
>> R.F. Burns wrote:
>>> However, over the past several weeks, the students have found more
>>> creative ways to abuse the PC speaker (outside of the OS.) The Powers
>>> that Be are asking that the PC speakers be disabled completely. With
>>> the small number of techs we have, it would be very impractical to go
>>> around to all systems and remove the PC speaker from each and every
>>> computer case.
>> Now I am curious; how are they getting the pc speaker to make any sound with
>> the kernel module disabled?
>
> ioperm(), inb(), and outb() from userspace. Needs root, though. Or
> /dev/port, with write. Which comes to the question how they gained root.
> Perhaps live cd? In which case, the OP should, as recommended in this
> thread already, deactivate choosing boot devices, if that's possible.
>
> (Unfortunately, newer BIOSes with 'integrated bootmenu' with F8 or so,
> but I have not seen a way to deactivate _that_ menu.)
He already said they don't have root access and that allowed him to stop
them from accessing the sound card by setting appropriate permissions.
On Jun 15, 2007, at 15:34:52, Jan Engelhardt wrote:
> Perhaps live cd? In which case, the OP should, as recommended in
> this thread already, deactivate choosing boot devices, if that's
> possible.
>
> (Unfortunately, newer BIOSes with 'integrated bootmenu' with F8 or
> so, but I have not seen a way to deactivate _that_ menu.)
Heh, with virtually every PC BIOS I've seen, the procedure is
something like this:
1) Reboot into BIOS
2) Set a BIOS "Supervisor Password" (as opposed to "User" or "Boot"
password)
3) Go to the "Boot Devices" list and uncheck everything except "Hard
Disk"
4) Go to the "USB Stick Hard Disk Emulation" feature and turn that off
5) Save settings to BIOS and reboot (Usually "F10" or "ESC-Y" )
The "Integrated BootMenu (F8)" stuff only lists boot devices that are
enabled in the BIOS. If everything but the hard disk is disabled
then pressing (F8) is _really_useful_ :-)
1) Boot from Hard Disk
2) Enter BIOS Setup
Of course, choosing option 2 is also quite an entertaining thing for
the student:
,--------------------------.
| Enter Password: ******** |
`--------------------------'
And since they don't actually know the password, it's followed by the
inevitable:
,--------------------------.
| Invalid Password |
`--------------------------'
Admittedly there are more things to turn off than with older BIOSen,
but there are also more features too. Of course, with OpenFirmware-
based systems (like the PowerPC macs) it's scriptable and doesn't
require rebooting.
1) Install the "nvsetenv" utility via your distro
2) Encode your password by xoring each character's ascii value
with 0xAA and printing the result in hex. This perl oneliner will do
it easily (Change 'my-password' to your plain-text password).
perl -ne 'map { printf "%%%02x", 0xaa ^ ord($_) } split //, $1;
print "\n"' my-password
For example, the password "linux" is encoded as "%c6%c3%c4%df%d2"
3) Run "nvsetenv security-password %c6%c3%c4%df%d2", where the
hex stuff is your encoded password
4) Run "nvsetenv security-mode command"
Then it auto-locks all possible ways of modifying the open-firmware
boot device or specifying alternative boot options. The only way to
get around it on most systems is with the firmware-reset button on
the inside of the case or moving RAM around and rebooting with some
magic key combo held down (Cmd-Opt-P-R on mac systems). Typically if
your students can do that there's exactly nothing you can do to
prevent them from doing whatever they want. They could always just
stick in a different hard-drive, after all.
Cheers,
Kyle Moffett