mapping 0 is required for vm86 mode, which we don't use. Given that we're running under x86emu we could presumably copy the low memory to somewhere arbitrary and then provide an offset - I have a vague recollection that x86emu even supports that already.
As for right now, though, the effect of denying that is that vbetool stops working.

vbetool itself is okay in this regard, it only maps the VROM, and while it does do so at a fixed address, it's not the zero page. libx86, however, maps at 0.
You'd kind of like some new LRMI API to tell the library about maps you've set up:
void *LRMI_add_map(void *map, uint32_t base, uint32_t size);
and then have x_outl() and friends in thunk.c walk the list of maps. Which is more or less what X does internally. (The return value is really only for if you want to delete maps at runtime, which... might be overdesigning it.)

is this a regression of BUG435935?, I am getting this reported every time at boot in a F12 system with using an Nvidia GeForce 6150SE nForce 43 card with KMS enabled :
Nov 16 23:01:35 inspiron kernel: type=1400 audit(1258441289.509:4): avc: denied { mmap_zero } for pid=408 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect

libx86-1.1-9.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update libx86'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-11717