> Then you fix the specific case and the game continues.
If they intercept netdev->hard_start_xmit there is nothing
to fix. Or inode->i_ops or any other virtual method pointer
that is called often..
Putting i_ops into const memory doesn't help either -- they
can just copy them and use their own and replace the pointer
in any accessed inode.
It's also not that doing this is rocket science. Anybody
barely skilled in computer architecture should be able
to figure this out.
Ok the only thing that could help is IA64/PPC64 style smart pointer
checking that could prevent foreign code from being
executed, but you won't get that on x86 or most other
architectures any time soon.
And that would also only work if you disable module loading
or implement a likely impractical/incompatible
with free software code signing scheme
(and Vista has just shown that these don't work anyways)
> > In general the .data protection is only considered a debugging
> > feature. I don't know why Fedora enables it in their production
> > kernels.
>
> That would be because we think you are wrong 8)
Well, it might at best buy you a few weeks/months in
terms of the exploit arms race, but thrash your user's TLBs
forever.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
