Is /dev/nvram dangerous to write to?

I'm curious as to exactly why you'd want to run such a command if you think it might damage your computer...

/dev/nvram provides access to the non-volatile memory in the real-time clock on PCs and Ataris. On PCs this is usually known as CMOS memory and stores the BIOS configuration options; you can see the information stored there by looking at /proc/driver/nvram:

Checksum status: valid
# floppies     : 4
Floppy 0 type  : none
Floppy 1 type  : none
HD 0 type      : ff
HD 1 type      : ff
HD type 48 data: 65471/255/255 C/H/S, precomp 65535, lz 65279
HD type 49 data: 3198/255/0 C/H/S, precomp 0, lz 0
DOS base memory: 630 kB
Extended memory: 65535 kB (configured), 65535 kB (tested)
Gfx adapter    : monochrome
FPU            : installed

All this is handled by the nvram kernel module, which takes care of checksums etc. Most of the information here is only present for historical reasons, and reflects the limitations of old operating systems: the computer I ran this on doesn't have four floppy drives, the hard drive information is incorrect, as is the memory information and display adapter information.

I haven't tried writing random values to the device, but I suspect it wouldn't brick your system: at worst, you should be able to recover by clearing the CMOS (there's usually a button or jumper to do that on your motherboard). But I wouldn't try it!

The only useful features in the CMOS memory nowadays are RTC-related. In particular, nvram-wakeup can program the CMOS alarm to switch your computer on at a specific time. (So that would be one reason to write to /dev/nvram.)

It probably could but it depends on your BIOS. See this related problem with EFI configuration where a laptop was bricked by clearing EFI variables. If some BIOS can't handle cleared variables, it's likely that some might not handle random garbage in nvram any better.

At the very least, before you try this, see if there's a nvram reset procedure for your specific hardware. Usually something like removing the backup battery from the motherboard for a while.

It would probably be fixable either because the firmware will notice it fails checksum and reset it (on the next boot), or alternatively by pulling the CMOS battery and/or using a CMOS clear jumper. Of course, buggy firmware may decide otherwise.

I personally would not recommend trying it. Just as I'd not recommend you test a GFI outlet by sticking a fork in it.