I just ran kexec-tools-1.101-69.fc7.x86_64 and the error is:
#/sbin/kexec --args-linux -p --command-line="ro root=LABEL=/ irqpoll
maxcpus=1" --initrd=/boot/initrd-2.6.20-1.2948.fc6kdumpkdump.img
/boot/vmlinux-2.6.20-1.2948.fc6kdump
Cannot open /proc/kcore: Operation not permitted
Cannot read /proc/kcore: Operation not permitted
Cannot load /boot/vmlinux-2.6.20-1.2948.fc6kdump
Actually, I can open a new bug starting with this version of kexec-tools if you
want to scrap this one. thanks.

Created attachment 156105[details]
patch to re-enable kcore access in the kernel
Heres the patch to re-enable access to /proc/kcore. I've spoken with the
selinux guys and we're are all in agreement that the best way forward here is
to re-enable kernel access and protect the file with selinux policy.

Created attachment 156119[details]
new version of patch to enable kcore access
New version of the patch. After discussing with davej, consensus was that
since its clear no one else needs kcore access anyway (evident by the fact it
is inaccessible), we decided to only make it accessible if the crashkernel
parameter is on the kernel command line. This patch does that, on only does it
for x86_64 systems since kexec only needs access on that arch.

Arjan rewrote the diff to be a lot less invasive, and hopefully more palatable
for upstream. I switched over to using his patch a while back.
The odd thing is that the new patch doesn't do as much as the old one. It only
disables /dev/kmem, so why /proc/kcore isn't working is odd.
hmm, it seems to work for me..
$ sudo hexdump /proc/kcore | head
0000000 457f 464c 0102 0001 0000 0000 0000 0000
0000010 0004 003e 0001 0000 0000 0000 0000 0000
0000020 0040 0000 0000 0000 0000 0000 0000 0000
0000030 0000 0000 0040 0038 0006 0000 0000 0000
0000040 0004 0000 0000 0000 0190 0000 0000 0000
....

Thanks frank. One more question. Its probably silly of me to ask, but you do
have a creashkernel= command line parameter specified on the production kernel
command line right? The patch that grants access to /proc/kcore only enables
read-permissions in the event that you specify that parameter. Without it the
file is unreadable.
can you check /proc/cmdline and verify your crashkernel parameter please? Thanks!

Certainly:
% cat /proc/cmdline
ro root=/dev/VolGroup00/LogVol00 crashkernel=64m@64m printk.time=1
... and confirmed by /proc/iomem.
The kernel code could log the reason for its EPERM return, in case there is more
than one possibility, to help debugging.

Created attachment 304681[details]
patch to enable kcore on x86_64
hmm, ok.
wait a sec....I see the problem.
There was a screw up with the 32/64 bit x86 merge. The bits that enabled kcore
access when passing the crashkernel parameter were applied to the 32 bit setup
code, but not the 64 bit setup code. This patch should fix it. Could you test
& confirm please? Thanks frank!
apologies for my blidness :)

Dave, I'm looking at the rawhide tree, and we don't include any of these
allow_kcore_access bits at all (which means everything should just work). Is
the answer here to just strip it all out of F-8 as well, or shall we forward
port the lot to rawhide?

well, thats rather the ironic thing about all this. Upstream kernels work fine,
since to open /proc/kcore all you need is privs on CAP_RAW_IO. Somewhere along
the line Fedora/RHEL (at least in RHEL5 & F-8) we decided to carry a security
patch to disable all access to /proc/kcore (it always returns 0). That
necessitated the addition of the allow_kcore_access bits, so that the always
deny policy could bee overridden if you were using kexec. Its all rather
hackish. Ijust tested and my patch works fine, so if you'd like to add it in ,
that would be great. That being said, I've always felt its rather a hack, so if
instead, you'd just like to revert the allow_kcore_access bits and mirror the
open_kcore function from upstream, that would be ideal in my mind.