Re: Text relocations in kernel modules
Peter Wemm wemm.org> writes: > ... > 5) If you own the machine's kernel, you can hide anything you wish. > Relocations are not a factor in this. > OK. Thanks a lot guys for sharing your answers and time. It was quite interesting. jb ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
On Wed, Apr 4, 2012 at 10:34 AM, jb wrote: > Peter Wemm wemm.org> writes: > >> ... >> There is no way to interfere because it is done outside of user space >> entirely, **after** the file has been copied out of the file system. >> You can do whatever you like to the file, but it has no effect because >> all the relocation is done in a private kernel copy. >> ... > > What if attack code (broadly understood) is part of module code, and is based > on either or both of: > - hidden (as to meaning and reloc targets) arrangement of relocations needed > - has an ability of (self) activation during load/link and *relocations* > process > already under the privilege of the kernel ? > > Is that possible at all ? > Would there be any protection against it (except giving up relocations as > an enabling vehicle) ? 1) If you can convince the superuser directly or indirectly to load a .ko file of your creation or under your control, it doesn't matter what the relocation state is. You already own the machine. 2) If you can write to kernel memory, you already own the machine, regardless of relocations. 3) There is no difference in any way between a text relocation and a non-text relocation inside kernel mode. 4) The user doesn't have any influence over the relocation process in any way except by #1 and #2, in which case relocations don't matter, because you already own the machine. 5) If you own the machine's kernel, you can hide anything you wish. Relocations are not a factor in this. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
If there is malicious code in a kernel module, then discussions of relocations become moot. Sent from my Android 4.0 device. Please forgive any spelling or grammatical errors. On Apr 4, 2012 11:35 AM, "jb" wrote: > Peter Wemm wemm.org> writes: > > > ... > > There is no way to interfere because it is done outside of user space > > entirely, **after** the file has been copied out of the file system. > > You can do whatever you like to the file, but it has no effect because > > all the relocation is done in a private kernel copy. > > ... > > What if attack code (broadly understood) is part of module code, and is > based > on either or both of: > - hidden (as to meaning and reloc targets) arrangement of relocations > needed > - has an ability of (self) activation during load/link and *relocations* > process > already under the privilege of the kernel ? > > Is that possible at all ? > Would there be any protection against it (except giving up relocations as > an enabling vehicle) ? > > jb > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
Peter Wemm wemm.org> writes: > ... > There is no way to interfere because it is done outside of user space > entirely, **after** the file has been copied out of the file system. > You can do whatever you like to the file, but it has no effect because > all the relocation is done in a private kernel copy. > ... What if attack code (broadly understood) is part of module code, and is based on either or both of: - hidden (as to meaning and reloc targets) arrangement of relocations needed - has an ability of (self) activation during load/link and *relocations* process already under the privilege of the kernel ? Is that possible at all ? Would there be any protection against it (except giving up relocations as an enabling vehicle) ? jb ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
On Wed, Apr 4, 2012 at 8:58 AM, Ian Lepore
wrote:
[..]
> This whole relocation question is just a big red herring. The kernel
> loader relocating a kernel module at load time does not open any
> opportunity for userland code to launch an attack on the memory pages
> into which the module gets loaded.
It is even more of a red herring because the basic assumption of why
the relocation is a problem is invalid.
In userland, a text relocation happens like this:
mprotect(addr, PROT_READ|PROT_WRITE|PROT_EXEC, PAGE_SIZE);
fixup_text_relocation()
mprotect(addr, PROT_READ|PROT_EXEC)
It's easy to see why this is something that you'd want to avoid. It
causes a write fault, dirties an entire page, and leaves userland text
writeable for a moment. Reducing these is worthwhile as a goal of
hardening. The PaX hardening patches explicitly disable this
mark/unmark phase in userland ld.so.
In userland, a -fPIC cross-file relocation happens like this:
fixup_readwrite_PLT_relocation()
Note that the PLT is always read/write. If you look at certain tools
that manage code injection you'll see that they intercept the PLT and
can get away with it quite nicely. Having -fPIC relocations makes it
a little easier because there's a single address to intercept.
In the kernel, there is no distinction between text and data at all.
It is read/write always, there is no write bit flipping, ever.
A kernel text relocation on i386 looks like this:
fixup_relocation();
A kernel text relocation with -fPIC on i386 looks like this:
panic("reloc type not implemented")
A kernel text relocation on amd64 looks like this:
fixup_relocation().
Neither i386 or amd64 do -fPIC modules. There is no brief window that
text is writeable, because it is always writeable by the kernel, as it
comes from the kernel malloc pool().
--
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
On Wed, Apr 4, 2012 at 8:05 AM, jb wrote: > Ian Lepore damnhippie.dyndns.org> writes: > >> ... >> > But of interest to me is this: >> > "... >> > Text relocations are a way in which references in the executable code to >> > addresses not known at link time are solved. Basically they just write >> > the appropriate address at runtime marking the code segment writable in >> > order to change the address then unmarking it. This can be a problem as >> > an attacker could try to exploit a bug when the text relocation happens >> > in order to be able to write arbitrary code in the text segment which >> > would be executed. >> > ..." >> ... >> A kernel module is loaded and linked >> ONCE, at load time, into the kernel's address space. >> ... > > >From the point of view of an attacker it does not matter whether kernel > >module > is loaded and linked once only. That's enough to create a window of > opportunity > for interfering with relocation process and modifying text (code). There is no way to interfere because it is done outside of user space entirely, **after** the file has been copied out of the file system. You can do whatever you like to the file, but it has no effect because all the relocation is done in a private kernel copy. In linux, the module tools do the linking and hand the resulting block of memory to the kernel. In freebsd, the module tools are third parties in the process. The copy is done while the vnode is locked. Any attempt to write to the file, or page fault via a mmap(MAP_SHARED) will sleep till the lock is released and the kernel has completed the copy of the contents. Once the lock is released, it doesn't matter what you do because the kernel is operating on a private, non-shared copy that you can't get anywhere near. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
On Wed, Apr 4, 2012 at 1:38 AM, jb wrote: > pobox.com> writes: > >> ... >> You can appeal to authority by saying the Gentoo Hardened developers said >> such-and-such all you want, but it would be more useful for you to be able >> to make specific technical arguments yourself. Saying "it could be a >> problem" or "in the wild there may be" isn't useful. A valid technical >> argument giving a mechanism for relocations to be exploited is all that >> is needed for you to prove your point. >> ... > > I have a question regarding security of FreeBSD kernel module loading and > relocation. > > According to KLDLOAD(8): > "...The kldload utility loads file.ko into the kernel using the kernel > linker. ..." > > So, kernel module is loaded: > # kldload /boot/kernel/foo.ko > > Here is my question: is foo.ko modified at this time ? Due to relocations ? > > The reason I ask about it is this Gentoo Hardened FAQ item: > > http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#paxnoelf > > "I keep getting the message: "error while loading shared libraries: cannot > make > segment writable for relocation: Permission denied." What does this mean?" > > I understand this is about .so and does not apply directly to .ko . > > But of interest to me is this: > "... > Text relocations are a way in which references in the executable code to > addresses not known at link time are solved. Basically they just write > the appropriate address at runtime marking the code segment writable in order > to change the address then unmarking it. This can be a problem as an attacker > could try to exploit a bug when the text relocation happens in order to be > able > to write arbitrary code in the text segment which would be executed. > ..." > > Now, let me apply the above quoted paragraph to .ko and ask my question again, > this time being more specific: > > are you doing any "marking" and "unmarking" of it at relocations and load > time, > thus creating an attack window opportunity ? In this particular case, no, there is no marking or unmarking. What happens is: kldload(2) syscall is performed with a pathname, in this case "/boot/kernel/foo.ko". The kernel locks the file. The kernel allocates a chunk of private, kernel-only data at a non deterministic address. The kernel *copies* the file from the file system into this allocated kernel-only memory. This isn't a mmap, its a read/memcpy type operation. The kernel unlocks the file. After the kernel has a private, non-shared copy of the file, it resolves outstanding symbols and relocations in its private, non-shared, non-user-accessible space. The kernel finally tells the user if the kldload() syscall was successful or not. ld.so is not involved, which is where those errors would come from. Nothing is shared, nothing is marked or unmarked. All of these operations happen outside of user visibility. We don't even have a way to report specific errors to the user, they're reported on the console. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
On Wed, 2012-04-04 at 15:05 +, jb wrote: > Ian Lepore damnhippie.dyndns.org> writes: > > > ... > > > But of interest to me is this: > > > "... > > > Text relocations are a way in which references in the executable code to > > > addresses not known at link time are solved. Basically they just write > > > the appropriate address at runtime marking the code segment writable in > > > order to change the address then unmarking it. This can be a problem as > > > an attacker could try to exploit a bug when the text relocation happens > > > in order to be able to write arbitrary code in the text segment which > > > would be executed. > > > ..." > > ... > > A kernel module is loaded and linked > > ONCE, at load time, into the kernel's address space. > > ... > > >From the point of view of an attacker it does not matter whether kernel > >module > is loaded and linked once only. That's enough to create a window of > opportunity > for interfering with relocation process and modifying text (code). > > jb Read again what I said. The same relocations would happen whether scattered through the text segment or gathered together in a single page. So the same window exists either way. But even more to the point: the memory has to be writable to initially populate it. The fact that it has to be changed as it is loaded doesn't in any way create an opportunity that doesn't already exist due to the pages being writable so that they can be loaded from disk. If there is some malicious in-kernel code (and it MUST be in-kernel code, because this is kernel memory, not mapped into any userland address space) it can already write to those pages because they're writable so that IO can happen. The pages are only visible to kernel code, and thus this hypothetical attack is being carried out by kernel code; if the pages weren't marked writable it would just make them writable, then write to them. If there is malicious in-kernel code that wants to do bad things, it doesn't have to wait for a .ko to get loaded to do the bad things. It's kernel code, it can do whatever it wants whenever it wants. This whole relocation question is just a big red herring. The kernel loader relocating a kernel module at load time does not open any opportunity for userland code to launch an attack on the memory pages into which the module gets loaded. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
jb wrote: From the point of view of an attacker it does not matter whether kernel module is loaded and linked once only. That's enough to create a window of opportunity for interfering with relocation process and modifying text (code). Well yes but said attacker has to be able to modify KERNEL memory to do it. If they can do that worrying about module relocations is pointless as they already own the machine. Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
Ian Lepore damnhippie.dyndns.org> writes: > ... > > But of interest to me is this: > > "... > > Text relocations are a way in which references in the executable code to > > addresses not known at link time are solved. Basically they just write > > the appropriate address at runtime marking the code segment writable in > > order to change the address then unmarking it. This can be a problem as > > an attacker could try to exploit a bug when the text relocation happens > > in order to be able to write arbitrary code in the text segment which > > would be executed. > > ..." > ... > A kernel module is loaded and linked > ONCE, at load time, into the kernel's address space. > ... >From the point of view of an attacker it does not matter whether kernel module is loaded and linked once only. That's enough to create a window of opportunity for interfering with relocation process and modifying text (code). jb ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
On Wed, 2012-04-04 at 08:38 +, jb wrote: > pobox.com> writes: > > > ... > > You can appeal to authority by saying the Gentoo Hardened developers said > > such-and-such all you want, but it would be more useful for you to be able > > to make specific technical arguments yourself. Saying "it could be a > > problem" or "in the wild there may be" isn't useful. A valid technical > > argument giving a mechanism for relocations to be exploited is all that > > is needed for you to prove your point. > > ... > > I have a question regarding security of FreeBSD kernel module loading and > relocation. > > According to KLDLOAD(8): > "...The kldload utility loads file.ko into the kernel using the kernel > linker. ..." > > So, kernel module is loaded: > # kldload /boot/kernel/foo.ko > > Here is my question: is foo.ko modified at this time ? Due to relocations ? > > The reason I ask about it is this Gentoo Hardened FAQ item: > > http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#paxnoelf > > "I keep getting the message: "error while loading shared libraries: cannot > make > segment writable for relocation: Permission denied." What does this mean?" > > I understand this is about .so and does not apply directly to .ko . > > But of interest to me is this: > "... > Text relocations are a way in which references in the executable code to > addresses not known at link time are solved. Basically they just write > the appropriate address at runtime marking the code segment writable in order > to change the address then unmarking it. This can be a problem as an attacker > could try to exploit a bug when the text relocation happens in order to be > able > to write arbitrary code in the text segment which would be executed. > ..." > > Now, let me apply the above quoted paragraph to .ko and ask my question again, > this time being more specific: > > are you doing any "marking" and "unmarking" of it at relocations and load > time, > thus creating an attack window opportunity ? > > jb Even though you acknowledge it, your question seems to contradict an understanding of the concept that a .ko is not a shared library. The "marking and unmarking" you refer to would apply to pages that are shared among multiple processes and have to be relocated repeatedly into each process's address space. A kernel module is loaded and linked ONCE, at load time, into the kernel's address space. It is not shared and never needs to be relocated again into another address space. In other words, the paragraph you cite doesn't have any meaning in the context of a .ko, because a .ko isn't a userland shared library. It's also interesting to me to note that even in a userland shared library, whether there are text relocations scattered throughout the text segment or they're all gathered into one table the way PIC code works, the same number of relocations have to happen to link the library into a new address space. The only difference is whether many pages get touched because the relocations are scattered, or only a few pages because they're all clumped together. The PIC scheme is designed to maximize code sharing by eliminating the need to copy-on-write many modified pages. I wonder how it became associated with increased security? I don't see the increase. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
pobox.com> writes: > ... > You can appeal to authority by saying the Gentoo Hardened developers said > such-and-such all you want, but it would be more useful for you to be able > to make specific technical arguments yourself. Saying "it could be a > problem" or "in the wild there may be" isn't useful. A valid technical > argument giving a mechanism for relocations to be exploited is all that > is needed for you to prove your point. > ... I have a question regarding security of FreeBSD kernel module loading and relocation. According to KLDLOAD(8): "...The kldload utility loads file.ko into the kernel using the kernel linker. ..." So, kernel module is loaded: # kldload /boot/kernel/foo.ko Here is my question: is foo.ko modified at this time ? Due to relocations ? The reason I ask about it is this Gentoo Hardened FAQ item: http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#paxnoelf "I keep getting the message: "error while loading shared libraries: cannot make segment writable for relocation: Permission denied." What does this mean?" I understand this is about .so and does not apply directly to .ko . But of interest to me is this: "... Text relocations are a way in which references in the executable code to addresses not known at link time are solved. Basically they just write the appropriate address at runtime marking the code segment writable in order to change the address then unmarking it. This can be a problem as an attacker could try to exploit a bug when the text relocation happens in order to be able to write arbitrary code in the text segment which would be executed. ..." Now, let me apply the above quoted paragraph to .ko and ask my question again, this time being more specific: are you doing any "marking" and "unmarking" of it at relocations and load time, thus creating an attack window opportunity ? jb ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
On Mon, Apr 2, 2012 at 1:02 PM, Richard Yao wrote: > On 04/02/12 15:37, Peter Wemm wrote: >> On Mon, Apr 2, 2012 at 12:23 PM, Richard Yao wrote: >>> On 04/02/12 14:46, Peter Wemm wrote: Remember.. ASLR is a userland thing. .ko files, which is what this thread is about, already use random address layout. When you do a "kldload virtio.ko", you have no way to predict what address it will be loaded at. And you don't even have access to the addresses. Of course if you want to talk about ASLR and userland .so files then that's an entirely different thing. But this thread is about your tools finding DT_TEXTREL in a .ko kernel file, not userland .so files. >>> >>> The PaX project's patches to the Linux kernel include kernel stack >>> randomization. The Gentoo Hardened project makes use of this in their >>> fork of the Linux kernel. >>> >> >> I looked at their code, and their description here: >> http://pax.grsecurity.net/docs/randkstack.txt >> >> Of note: >> "pax_randomize_kstack() gathers entropy from the rdtsc instruction >> (read time stamp counter) and applies it to bits 2-6 of the kernel >> stack pointer. This means that 5 bits are randomized providing a >> maximum shift of 128 bytes - this was deemed safe enough to not cause >> kernel stack overflows yet give enough randomness to deter >> guessing/brute forcing attempts." >> >> This has nothing to do with the DT_TEXTREL in .ko that this thread is >> about and has no bearing on ASLR in any way. > > There are plenty of techniques employed to do ASLR by both the upstream > Linux kernel and the PaX patches to it. I only needed to state one to > prove that you were wrong about ASLR being exclusive to userland. ASLR is a generic term for a worthwhile goal - to raise the difficulty bar for an attacker to do something meaningful when they find a vulnerability that leads to the ability to inject code. There's people actively working on this in FreeBSD, but it has nothing to do with the DT_TEXTREL in an i386 .ko file. I wasn't the one who brought up ASLR, you keep bringing it up without a single DETAIL about why it's relevant. And then dismissing all of the details we provide to explain, in detail, why DT_TEXTREL on a .ko file has nothing to do with ASLR. > If the QA checks had been triggered for an out-of-tree Linux kernel > module, the Gentoo developers would consider it to be a bug. I have > verified this with the Gentoo Hardened developers. Furthermore, they > confirmed that text relocations in out-of-tree kernel modules would > negatively affect ASLR. I don't believe you. The way I see it, either: 1) you asked the wrong people who are as misguided as you are, or 2) you told them what they'd need to hear in order to arrive at the conclusion you want, or 3) you're making it up. I find it hard to believe that seasoned folks who wrote the excellently detailed 'how to fix' page for USERLAND libraries at http://www.gentoo.org/proj/en/hardened/pic-fix-guide.xml would make such a colossal mistake. If such an opinion was actually expressed to you, I think its far more likely it was based on a lack of working knowledge of what a freebsd .ko file is and how its used, or based on misinformation from you. Or you asked the wrong people. A http url link to the mailing list archives would be greatly appreciated, so I can find out exactly what the source of this insanity is. > My original email to the list asked if this was an issue in FreeBSD. > That question had been answered. Yes, it has been answered. No, not a bug, not a security issue, and not even the slightest cause for concern in any way, and does not in any way interfere with ASLR type goals. > However, people went ballistic upon the > mere presence of my question, so I assured them that if I ever found > time to write exploit code, I would do full disclosure to ensure that > this issue was fixed. That's akin to saying: "I'm going to drown your neighbor's cousin's daugher's pet kitten if you don't put a better muffler on your car." Nobody's disputing that ASLR is a worthwhile thing. What we're disputing is your unfounded, unsupported assertion that a DT_TEXTREL is a cause for concern in a kernel module. What people reacted to was your stubborn unwillingness to accept that you were wrong when you were told you were wrong by something approaching six different people now, with explicit details about how you were wrong. "Because I said so" isn't a valid rebuttal. > However, there could be unknown exploits in the wild that would be > killed by ASLR in the wild. Ah, here we go again. You bring up ASLR again. I find it hard to believe your "I might write an exploit" threat to be credible when you can't provide any details and don't seem to be able to demonstrate understanding of any of the basic concepts. Repeat: ASLR is good. But your DT_TEXTREL bug report in a .ko file is not a bug and has nothing to do with ASLR in any way, shape, form, variant or
Re: Text relocations in kernel modules
On 04/02/12 15:37, Peter Wemm wrote: > On Mon, Apr 2, 2012 at 12:23 PM, Richard Yao wrote: >> On 04/02/12 14:46, Peter Wemm wrote: >>> Remember.. ASLR is a userland thing. .ko files, which is what this >>> thread is about, already use random address layout. When you do a >>> "kldload virtio.ko", you have no way to predict what address it will >>> be loaded at. And you don't even have access to the addresses. >>> >>> Of course if you want to talk about ASLR and userland .so files then >>> that's an entirely different thing. But this thread is about your >>> tools finding DT_TEXTREL in a .ko kernel file, not userland .so files. >>> >> >> The PaX project's patches to the Linux kernel include kernel stack >> randomization. The Gentoo Hardened project makes use of this in their >> fork of the Linux kernel. >> > > I looked at their code, and their description here: > http://pax.grsecurity.net/docs/randkstack.txt > > Of note: > "pax_randomize_kstack() gathers entropy from the rdtsc instruction > (read time stamp counter) and applies it to bits 2-6 of the kernel > stack pointer. This means that 5 bits are randomized providing a > maximum shift of 128 bytes - this was deemed safe enough to not cause > kernel stack overflows yet give enough randomness to deter > guessing/brute forcing attempts." > > This has nothing to do with the DT_TEXTREL in .ko that this thread is > about and has no bearing on ASLR in any way. There are plenty of techniques employed to do ASLR by both the upstream Linux kernel and the PaX patches to it. I only needed to state one to prove that you were wrong about ASLR being exclusive to userland. If the QA checks had been triggered for an out-of-tree Linux kernel module, the Gentoo developers would consider it to be a bug. I have verified this with the Gentoo Hardened developers. Furthermore, they confirmed that text relocations in out-of-tree kernel modules would negatively affect ASLR. My original email to the list asked if this was an issue in FreeBSD. That question had been answered. However, people went ballistic upon the mere presence of my question, so I assured them that if I ever found time to write exploit code, I would do full disclosure to ensure that this issue was fixed. I stumbled across this issue when setting up an environment in which I could port gptzfsloader to Linux, so I have no reason to implement ASLR in the FreeBSD kernel. Also, the abuse I received over this has lead me to conclude that doing anything for upstream would be deterimental to my mental health, so I am not inclined to try. However, there could be unknown exploits in the wild that would be killed by ASLR in the wild. It would be best for someone, who considers securing FreeBSD to be worth suffering from abuse, to implement it. That person is not me. signature.asc Description: OpenPGP digital signature
Re: Text relocations in kernel modules
On Mon, Apr 2, 2012 at 12:23 PM, Richard Yao wrote: > On 04/02/12 14:46, Peter Wemm wrote: >> Remember.. ASLR is a userland thing. .ko files, which is what this >> thread is about, already use random address layout. When you do a >> "kldload virtio.ko", you have no way to predict what address it will >> be loaded at. And you don't even have access to the addresses. >> >> Of course if you want to talk about ASLR and userland .so files then >> that's an entirely different thing. But this thread is about your >> tools finding DT_TEXTREL in a .ko kernel file, not userland .so files. >> > > The PaX project's patches to the Linux kernel include kernel stack > randomization. The Gentoo Hardened project makes use of this in their > fork of the Linux kernel. > I looked at their code, and their description here: http://pax.grsecurity.net/docs/randkstack.txt Of note: "pax_randomize_kstack() gathers entropy from the rdtsc instruction (read time stamp counter) and applies it to bits 2-6 of the kernel stack pointer. This means that 5 bits are randomized providing a maximum shift of 128 bytes - this was deemed safe enough to not cause kernel stack overflows yet give enough randomness to deter guessing/brute forcing attempts." This has nothing to do with the DT_TEXTREL in .ko that this thread is about and has no bearing on ASLR in any way. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
On 04/02/12 14:46, Peter Wemm wrote: > Remember.. ASLR is a userland thing. .ko files, which is what this > thread is about, already use random address layout. When you do a > "kldload virtio.ko", you have no way to predict what address it will > be loaded at. And you don't even have access to the addresses. > > Of course if you want to talk about ASLR and userland .so files then > that's an entirely different thing. But this thread is about your > tools finding DT_TEXTREL in a .ko kernel file, not userland .so files. > The PaX project's patches to the Linux kernel include kernel stack randomization. The Gentoo Hardened project makes use of this in their fork of the Linux kernel. signature.asc Description: OpenPGP digital signature
Re: Text relocations in kernel modules
On Mon, Apr 2, 2012 at 10:31 AM, Richard Yao wrote: > On 04/02/12 13:13, Tom Evans wrote: >> On Mon, Apr 2, 2012 at 5:49 PM, Richard Yao wrote: >>> On 04/02/12 05:56, Tom Evans wrote: On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao wrote: >> There are no security implications, no system resources to be wasted. >> >> And if you think there are security implications, then lets see a >> proof-of-concept. > > If I find time to write a proof-of-concept, I promise to publish it > publicly. Your security team will find out when everyone else does. Richard, I'm not sure what you are trying to accomplish here. You have had a clear explanation of why certain things are done in a certain way in the FreeBSD codebase, and a confirmation that they do not think it causes any security issues in FreeBSD. Your response is to threaten to write an exploit against FreeBSD, and distribute it publicly before disclosing to security@. >>> >>> Some people believe that projects that do not take proper >>> countermeasures against security vulnerabilities do not deserve to have >>> special notification of issues. I happen to be one of them. >> >> This is a straw man argument - FreeBSD does take proper >> countermeasures against security vulnerabilities - and so your >> conclusion that you can blithely fully disclose vulnerabilities with >> no moral concerns is a logical fallacy. > > My opinion is that any OS that lacks ALSR lacks proper countermeasures > against vunerabilities that ASLR would kill. Furthermore, I believe that > trying to minimize the impact of bugs that would be addressed by ASLR is > ultimately harmful to users' security. Logically, full disclosure would > only apply to attacks that ASLR would kill. Remember.. ASLR is a userland thing. .ko files, which is what this thread is about, already use random address layout. When you do a "kldload virtio.ko", you have no way to predict what address it will be loaded at. And you don't even have access to the addresses. Of course if you want to talk about ASLR and userland .so files then that's an entirely different thing. But this thread is about your tools finding DT_TEXTREL in a .ko kernel file, not userland .so files. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
On Fri, Mar 30, 2012 at 7:42 PM, Richard Yao wrote: > On 03/30/12 22:15, Peter Wemm wrote: >> On Fri, Mar 30, 2012 at 3:47 PM, Richard Yao wrote: >>> On 03/30/12 18:46, Konstantin Belousov wrote: Reread what I wrote to you. Also, it pays off learning how ELF works before making conclusion from the absence of the output of readelf -d. Amd64 modules _are not_ shared objects. >>> >>> Whether or not they are shared objects is irrelevant. The fact is that >>> they have text relocations, which interfere with ASLR. Do I need to >>> produce exploit code before you take me seriously? >>> >> >> I am the person who wrote it and deliberately chose to cause text >> relocations to be generated on i386. It is by design, not a bug. >> >> All of your concerns are perfectly valid if they were for userland. >> >> For the record, our amd64 modules ALSO do this, but your tools simply >> do not detect it. >> >> Here is what happens, and here is why it is not a problem: >> >> When you compile with -fpic on an architecture that doesn't support >> PC-relative addressing adequately, the compiler generates code to do >> indirect memory references via the global offset table. This is so >> that all the relocations can be collected into a single location in >> order to not dirty the MAP_PRIVATE data pages. >> >> example: >> if there is an function at 0x12345, and another function in a >> different .so file that wants to call it at 0x22345, then the call >> instruction would have to be relocated. The asm instructions would >> look like: >> 0xE8FFEF (offset is -0x1) >> >> If the same .so file was loaded in another user process at 0x32345, >> then the relocation would be different. An entire page would be >> dirtied by the dynamic linker so that the second instance of the .so >> file had 0xE8FFDF (-0x2). This is a waste of memory and >> causes a storm of VM faults at startup. >> >> Instead, the code is compiled with -fPIC, which causes an extra memory >> reference via the global offset table. Instead of the relocations >> being spread over the text segment, the relocations are in a single >> page. The dynamic linker has to dirty one page only in order to set >> up a whole host of relocations. >> >> The cost is i386 doesn't have native pc-relative mode, so it has to >> waste an entire register. We dedicate one of the 6 general purpose >> registers which costs a hefty performance hit. This is why crypto >> code tends to be compiled without -fpic, for example. >> >> For KERNEL modules, all this changes. >> >> In userland, there is a dynamic linker. In the kernel, there is none. >> In userland, the .so files are mapped with mmap(MAP_PRIVATE), the >> kernel does not use mmap and always uses a private copy. >> In userland, the .so files are shared, the kernel NEVER shares them. >> In userland, doing a relocation causes a copy on write fault, this >> never happens to the kernel because its using private, exclusive >> malloc() pages. >> In userland, we make the performance tradeoff from -fpic in order to >> share memory pages, the kernel never shares pages so -fpic is a waste. >> In userland, ASLR has security benefits. The kernel already does >> this.. if you load a module on one machine it'll ALWAYS be at >> different address space compared to another. >> >> In FreeBSD/i386, we use 'ld -shared -o foo.ko *.o', to wrap the non >> pic .o files into a container that was more convenient at the time to >> parse. There is no global-offset-table. >> In FreeBSD/amd64, we use 'ld -r -o foo.ko *.o' to wrap the same >> non-pic code into a less convenient form that we can feed back into >> the linker if we wish. There is no global offset table. >> >> Both i386 and amd64 use raw relocations, regardless of where the came >> from. Text, data, anywhere. >> >> This has nothing to do with ASLR, because they are kernel objects, not >> shared libraries. > > Most people seem to think that I am unaware of these things, but I > already knew most of it. Note that this mostly applies to remarks people > are sending me privately. > > With that said, thank you for the detailed explanation. It filled in a > few blanks that I had, specifically in how FreeBSD does things. > >> You posted: >> * QA Notice: The following files contain runtime text relocations >> * Text relocations force the dynamic linker to perform extra >> * work at startup, waste system resources, and may pose a security >> * risk. On some architectures, the code may not even function >> * properly, if at all. >> The key here is "dynamic linker". There is no dynamic linker to >> process this stuff. > >> This is simply a tools problem on your end. It's not a bug. > > My tools are doing what they were supposed to do. However, people on the > list seem to think that the idea that they are checking for a problem to > be a matter of opinion. No, your tools are checking for, and reporting a USERLAND performance problem. A kernel .ko file is NOT used by
Re: Text relocations in kernel modules
On 04/02/12 13:13, Tom Evans wrote: > On Mon, Apr 2, 2012 at 5:49 PM, Richard Yao wrote: >> On 04/02/12 05:56, Tom Evans wrote: >>> On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao wrote: > There are no security implications, no system resources to be wasted. > > And if you think there are security implications, then lets see a > proof-of-concept. If I find time to write a proof-of-concept, I promise to publish it publicly. Your security team will find out when everyone else does. >>> >>> Richard, I'm not sure what you are trying to accomplish here. You have >>> had a clear explanation of why certain things are done in a certain >>> way in the FreeBSD codebase, and a confirmation that they do not think >>> it causes any security issues in FreeBSD. >>> >>> Your response is to threaten to write an exploit against FreeBSD, and >>> distribute it publicly before disclosing to security@. >> >> Some people believe that projects that do not take proper >> countermeasures against security vulnerabilities do not deserve to have >> special notification of issues. I happen to be one of them. > > This is a straw man argument - FreeBSD does take proper > countermeasures against security vulnerabilities - and so your > conclusion that you can blithely fully disclose vulnerabilities with > no moral concerns is a logical fallacy. My opinion is that any OS that lacks ALSR lacks proper countermeasures against vunerabilities that ASLR would kill. Furthermore, I believe that trying to minimize the impact of bugs that would be addressed by ASLR is ultimately harmful to users' security. Logically, full disclosure would only apply to attacks that ASLR would kill. With that said, I should remind you of the FreeBSD project's license, which disclaims the possibility of "moral concerns": THIS SOFTWARE IS PROVIDED BY THE FREEBSD PROJECT ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FREEBSD PROJECT OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. It is highly unlikely that anyone who opts for full disclosure of vulnerabilities that ASLR would kill would also be the person who wrote the vulnerable code in the first place. However, should he be the same person, it would seem that you have already accepted a license freeing him of responsibility. there are many people who have commit access. Any of them could intentionally commit vulnerabilities that ASLR would kill. If you do not like this situation, I suggest that you consider alternative operating systems, such as AIX, Mac OS X or Solaris. Their licenses might be more permissive in your ability to hold their makers responsible for flaws. signature.asc Description: OpenPGP digital signature
Re: Text relocations in kernel modules
On Mon, Apr 2, 2012 at 5:49 PM, Richard Yao wrote: > On 04/02/12 05:56, Tom Evans wrote: >> On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao wrote: There are no security implications, no system resources to be wasted. And if you think there are security implications, then lets see a proof-of-concept. >>> >>> If I find time to write a proof-of-concept, I promise to publish it >>> publicly. Your security team will find out when everyone else does. >> >> Richard, I'm not sure what you are trying to accomplish here. You have >> had a clear explanation of why certain things are done in a certain >> way in the FreeBSD codebase, and a confirmation that they do not think >> it causes any security issues in FreeBSD. >> >> Your response is to threaten to write an exploit against FreeBSD, and >> distribute it publicly before disclosing to security@. > > Some people believe that projects that do not take proper > countermeasures against security vulnerabilities do not deserve to have > special notification of issues. I happen to be one of them. This is a straw man argument - FreeBSD does take proper countermeasures against security vulnerabilities - and so your conclusion that you can blithely fully disclose vulnerabilities with no moral concerns is a logical fallacy. You have posited that this is a vulnerability to FreeBSD (based upon checks put in place for a Linux project) whilst many FreeBSD committers have said that you are mistaken, and it does not do so. If you disagree with them, then show them by example or argument that they are wrong. If you think they are wrong and that it is a vulnerability to FreeBSD, you should be discussing this off list in detail with the sec team - security-offi...@freebsd.org Threatening to jeopardise FreeBSD's security by public disclosure, with no discussion with the FreeBSD security team is a puerile way of acting, and does neither you, your university nor Gentoo any favours. > I suggest that you look at things from my perspective. I asked a simple > question on your mailing list. I then received several private emails > from various FreeBSD developers insulting my intelligence for the act of > asking a question. Who is the "ass" here? > I can't comment as to what people said to you off-list, I'm not party to that. What you said on-list: > If I find time to write a proof-of-concept, I promise to publish it > publicly. Your security team will find out when everyone else does. that is "ass" territory. Cheers Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
Let's all calm down here. No need to make this personal. Let's please try to keep this conversation professional and respectful to all parties involved. Richard, I suggest that if you think the current implementation is less secure than other implementations, you could write a patch and submit it upstream. I'm sure that the FreeBSD security team would love any patches that enhance security. Granted, you might have to present a strong case for a patch of this nature to be accepted upstream, but I'm sure you will learn a lot about FreeBSD and others (like me) who maintain modified FreeBSD codebases would benefit from such a patch. I might be interested to help you develop this patch if you decide to take it on. Thanks, Shawn Sent from my Android 4.0 device. Please forgive any spelling or grammatical errors. On Apr 2, 2012 10:53 AM, "Richard Yao" wrote: > On 04/02/12 05:56, Tom Evans wrote: > > On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao > wrote: > >>> There are no security implications, no system resources to be wasted. > >>> > >>> And if you think there are security implications, then lets see a > >>> proof-of-concept. > >> > >> If I find time to write a proof-of-concept, I promise to publish it > >> publicly. Your security team will find out when everyone else does. > > > > Richard, I'm not sure what you are trying to accomplish here. You have > > had a clear explanation of why certain things are done in a certain > > way in the FreeBSD codebase, and a confirmation that they do not think > > it causes any security issues in FreeBSD. > > > > Your response is to threaten to write an exploit against FreeBSD, and > > distribute it publicly before disclosing to security@. > > Some people believe that projects that do not take proper > countermeasures against security vulnerabilities do not deserve to have > special notification of issues. I happen to be one of them. > > > Are you trying to be an ass? Someone disagrees with you on the > > internet, so you throw all the toys out the pram? > > I suggest that you look at things from my perspective. I asked a simple > question on your mailing list. I then received several private emails > from various FreeBSD developers insulting my intelligence for the act of > asking a question. Who is the "ass" here? > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
On 4/2/12 12:49 PM, Richard Yao wrote: > On 04/02/12 05:56, Tom Evans wrote: >> On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao wrote: There are no security implications, no system resources to be wasted. And if you think there are security implications, then lets see a proof-of-concept. >>> >>> If I find time to write a proof-of-concept, I promise to publish it >>> publicly. Your security team will find out when everyone else does. >> >> Richard, I'm not sure what you are trying to accomplish here. You have >> had a clear explanation of why certain things are done in a certain >> way in the FreeBSD codebase, and a confirmation that they do not think >> it causes any security issues in FreeBSD. >> >> Your response is to threaten to write an exploit against FreeBSD, and >> distribute it publicly before disclosing to security@. > > Some people believe that projects that do not take proper > countermeasures against security vulnerabilities do not deserve to have > special notification of issues. I happen to be one of them. Wow. You're not only an ass, you're a pompous ass. > >> Are you trying to be an ass? Someone disagrees with you on the >> internet, so you throw all the toys out the pram? > > I suggest that you look at things from my perspective. I asked a simple > question on your mailing list. I then received several private emails > from various FreeBSD developers insulting my intelligence for the act of > asking a question. Who is the "ass" here? > See above. Or... look in the mirror. -- Jim Ohlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
On 04/02/12 05:56, Tom Evans wrote: > On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao wrote: >>> There are no security implications, no system resources to be wasted. >>> >>> And if you think there are security implications, then lets see a >>> proof-of-concept. >> >> If I find time to write a proof-of-concept, I promise to publish it >> publicly. Your security team will find out when everyone else does. > > Richard, I'm not sure what you are trying to accomplish here. You have > had a clear explanation of why certain things are done in a certain > way in the FreeBSD codebase, and a confirmation that they do not think > it causes any security issues in FreeBSD. > > Your response is to threaten to write an exploit against FreeBSD, and > distribute it publicly before disclosing to security@. Some people believe that projects that do not take proper countermeasures against security vulnerabilities do not deserve to have special notification of issues. I happen to be one of them. > Are you trying to be an ass? Someone disagrees with you on the > internet, so you throw all the toys out the pram? I suggest that you look at things from my perspective. I asked a simple question on your mailing list. I then received several private emails from various FreeBSD developers insulting my intelligence for the act of asking a question. Who is the "ass" here? signature.asc Description: OpenPGP digital signature
Re: Text relocations in kernel modules
On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao wrote: >> There are no security implications, no system resources to be wasted. >> >> And if you think there are security implications, then lets see a >> proof-of-concept. > > If I find time to write a proof-of-concept, I promise to publish it > publicly. Your security team will find out when everyone else does. Richard, I'm not sure what you are trying to accomplish here. You have had a clear explanation of why certain things are done in a certain way in the FreeBSD codebase, and a confirmation that they do not think it causes any security issues in FreeBSD. Your response is to threaten to write an exploit against FreeBSD, and distribute it publicly before disclosing to security@. Are you trying to be an ass? Someone disagrees with you on the internet, so you throw all the toys out the pram? Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
On 03/30/12 22:15, Peter Wemm wrote: > On Fri, Mar 30, 2012 at 3:47 PM, Richard Yao wrote: >> On 03/30/12 18:46, Konstantin Belousov wrote: >>> Reread what I wrote to you. Also, it pays off learning how ELF works >>> before making conclusion from the absence of the output of readelf -d. >>> Amd64 modules _are not_ shared objects. >> >> Whether or not they are shared objects is irrelevant. The fact is that >> they have text relocations, which interfere with ASLR. Do I need to >> produce exploit code before you take me seriously? >> > > I am the person who wrote it and deliberately chose to cause text > relocations to be generated on i386. It is by design, not a bug. > > All of your concerns are perfectly valid if they were for userland. > > For the record, our amd64 modules ALSO do this, but your tools simply > do not detect it. > > Here is what happens, and here is why it is not a problem: > > When you compile with -fpic on an architecture that doesn't support > PC-relative addressing adequately, the compiler generates code to do > indirect memory references via the global offset table. This is so > that all the relocations can be collected into a single location in > order to not dirty the MAP_PRIVATE data pages. > > example: > if there is an function at 0x12345, and another function in a > different .so file that wants to call it at 0x22345, then the call > instruction would have to be relocated. The asm instructions would > look like: > 0xE8FFEF (offset is -0x1) > > If the same .so file was loaded in another user process at 0x32345, > then the relocation would be different. An entire page would be > dirtied by the dynamic linker so that the second instance of the .so > file had 0xE8FFDF (-0x2). This is a waste of memory and > causes a storm of VM faults at startup. > > Instead, the code is compiled with -fPIC, which causes an extra memory > reference via the global offset table. Instead of the relocations > being spread over the text segment, the relocations are in a single > page. The dynamic linker has to dirty one page only in order to set > up a whole host of relocations. > > The cost is i386 doesn't have native pc-relative mode, so it has to > waste an entire register. We dedicate one of the 6 general purpose > registers which costs a hefty performance hit. This is why crypto > code tends to be compiled without -fpic, for example. > > For KERNEL modules, all this changes. > > In userland, there is a dynamic linker. In the kernel, there is none. > In userland, the .so files are mapped with mmap(MAP_PRIVATE), the > kernel does not use mmap and always uses a private copy. > In userland, the .so files are shared, the kernel NEVER shares them. > In userland, doing a relocation causes a copy on write fault, this > never happens to the kernel because its using private, exclusive > malloc() pages. > In userland, we make the performance tradeoff from -fpic in order to > share memory pages, the kernel never shares pages so -fpic is a waste. > In userland, ASLR has security benefits. The kernel already does > this.. if you load a module on one machine it'll ALWAYS be at > different address space compared to another. > > In FreeBSD/i386, we use 'ld -shared -o foo.ko *.o', to wrap the non > pic .o files into a container that was more convenient at the time to > parse. There is no global-offset-table. > In FreeBSD/amd64, we use 'ld -r -o foo.ko *.o' to wrap the same > non-pic code into a less convenient form that we can feed back into > the linker if we wish. There is no global offset table. > > Both i386 and amd64 use raw relocations, regardless of where the came > from. Text, data, anywhere. > > This has nothing to do with ASLR, because they are kernel objects, not > shared libraries. Most people seem to think that I am unaware of these things, but I already knew most of it. Note that this mostly applies to remarks people are sending me privately. With that said, thank you for the detailed explanation. It filled in a few blanks that I had, specifically in how FreeBSD does things. > You posted: > * QA Notice: The following files contain runtime text relocations > * Text relocations force the dynamic linker to perform extra > * work at startup, waste system resources, and may pose a security > * risk. On some architectures, the code may not even function > * properly, if at all. > The key here is "dynamic linker". There is no dynamic linker to > process this stuff. > This is simply a tools problem on your end. It's not a bug. My tools are doing what they were supposed to do. However, people on the list seem to think that the idea that they are checking for a problem to be a matter of opinion. > There are no security implications, no system resources to be wasted. > > And if you think there are security implications, then lets see a > proof-of-concept. If I find time to write a proof-of-concept, I promise to publish it publicly. Your security team w
Re: Text relocations in kernel modules
On Fri, Mar 30, 2012 at 6:51 PM, wrote: > On Fri, Mar 30, 2012 at 06:47:15PM -0400, Richard Yao wrote: >> On 03/30/12 18:46, Konstantin Belousov wrote: >> > Reread what I wrote to you. Also, it pays off learning how ELF works >> > before making conclusion from the absence of the output of readelf -d. >> > Amd64 modules _are not_ shared objects. >> >> Whether or not they are shared objects is irrelevant. The fact is that >> they have text relocations, which interfere with ASLR. Do I need to >> produce exploit code before you take me seriously? > > Any time you have any reference from a single compilation's object module > to any code or data in a different compilation you need some way for one > object to find that code/data. > > Think about it: if a function call is going to branch to another function > it needs to know the address of the target function. How can it get this > target address? Relocations. > > Now, move up a bit to kernel objects which typically consist of multiple > compilations all linked together. If a function in a kernel object wants > to call a function in the main part of the kernel it needs the address. > How can it get this target address? Relocations. > > When code is linked together into a single file it is possible to have > compilations have patched into them the offsets to functions or data from > other compilations. But this only works when the relative locations are > fixed. > > If you want different kernel objects to get random addresses when loaded > at run time then you _must_ have some way for the kernel object to call > back into the main kernel. It is possible to, at the C language level, > pass around structs holding pointers to functions and pointers to data. > But this does the same thing as relocations and it does it less efficiently. When a chunk of code is compiled with -fpic, function calls are produced with a special relocation type. When it is linked, all these calls are gathered into an indirect PLT (procedure linkage table). In userland, the PLT is dirtied at startup and varies depending on the random load address. But all the indirect calls are PC-relative to the PLT. eg: if the kernel bzero is at 0xc0201230, and we load a .ko file at 0xc10 which has three "call bzero" references, then: -fpic case: all three calls to bzero will pc-relative "call" a slot in the PLT, which is resolved and created at "ld -shared" time, which will be run time relocated to "jmp 0xc0201230". ie: "call bzero@PLT" -> "jmp bzero" -> bzero() non-fpic case: each instance of the three "call bzero" will be relocated without making an indirect bounce through the PLT, which we don't need. ie: "call bzero" -> bzero() there would be three symbol lookups at .ko load time instead of one. The big difference (besides the loss of the %ebx register) is those extra memory hits to do a bzero(), that are paid for every single time. Meanwhile the non-pic case has an up-front cost of invoking some extremely unoptimized code at load time and never has the runtime overhead. Linux doesn't use 'ld -shared' format. They used something vaguely like what we did with the old LKM system, ie: running ld incrementally and loading the results. That was a long time ago, but they sure don't take the overhead of PLT/GOT/-fpic mode either. There's just no need. We provoke a warning on the gentoo tools on i386 because we simply used 'ld -shared' output as a container or transport. We use a different format by default on amd64, but the code is generated exactly the same way as on i386 and has exactly the same relocations in the same places. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
On Fri, Mar 30, 2012 at 3:47 PM, Richard Yao wrote: > On 03/30/12 18:46, Konstantin Belousov wrote: >> Reread what I wrote to you. Also, it pays off learning how ELF works >> before making conclusion from the absence of the output of readelf -d. >> Amd64 modules _are not_ shared objects. > > Whether or not they are shared objects is irrelevant. The fact is that > they have text relocations, which interfere with ASLR. Do I need to > produce exploit code before you take me seriously? > I am the person who wrote it and deliberately chose to cause text relocations to be generated on i386. It is by design, not a bug. All of your concerns are perfectly valid if they were for userland. For the record, our amd64 modules ALSO do this, but your tools simply do not detect it. Here is what happens, and here is why it is not a problem: When you compile with -fpic on an architecture that doesn't support PC-relative addressing adequately, the compiler generates code to do indirect memory references via the global offset table. This is so that all the relocations can be collected into a single location in order to not dirty the MAP_PRIVATE data pages. example: if there is an function at 0x12345, and another function in a different .so file that wants to call it at 0x22345, then the call instruction would have to be relocated. The asm instructions would look like: 0xE8FFEF (offset is -0x1) If the same .so file was loaded in another user process at 0x32345, then the relocation would be different. An entire page would be dirtied by the dynamic linker so that the second instance of the .so file had 0xE8FFDF (-0x2). This is a waste of memory and causes a storm of VM faults at startup. Instead, the code is compiled with -fPIC, which causes an extra memory reference via the global offset table. Instead of the relocations being spread over the text segment, the relocations are in a single page. The dynamic linker has to dirty one page only in order to set up a whole host of relocations. The cost is i386 doesn't have native pc-relative mode, so it has to waste an entire register. We dedicate one of the 6 general purpose registers which costs a hefty performance hit. This is why crypto code tends to be compiled without -fpic, for example. For KERNEL modules, all this changes. In userland, there is a dynamic linker. In the kernel, there is none. In userland, the .so files are mapped with mmap(MAP_PRIVATE), the kernel does not use mmap and always uses a private copy. In userland, the .so files are shared, the kernel NEVER shares them. In userland, doing a relocation causes a copy on write fault, this never happens to the kernel because its using private, exclusive malloc() pages. In userland, we make the performance tradeoff from -fpic in order to share memory pages, the kernel never shares pages so -fpic is a waste. In userland, ASLR has security benefits. The kernel already does this.. if you load a module on one machine it'll ALWAYS be at different address space compared to another. In FreeBSD/i386, we use 'ld -shared -o foo.ko *.o', to wrap the non pic .o files into a container that was more convenient at the time to parse. There is no global-offset-table. In FreeBSD/amd64, we use 'ld -r -o foo.ko *.o' to wrap the same non-pic code into a less convenient form that we can feed back into the linker if we wish. There is no global offset table. Both i386 and amd64 use raw relocations, regardless of where the came from. Text, data, anywhere. This has nothing to do with ASLR, because they are kernel objects, not shared libraries. You posted: * QA Notice: The following files contain runtime text relocations * Text relocations force the dynamic linker to perform extra * work at startup, waste system resources, and may pose a security * risk. On some architectures, the code may not even function * properly, if at all. The key here is "dynamic linker". There is no dynamic linker to process this stuff. This is simply a tools problem on your end. It's not a bug. There are no security implications, no system resources to be wasted. And if you think there are security implications, then lets see a proof-of-concept. I have given you a detailed explanation of why it's not a problem. If you want to continue, then reply with details, not hearsay or theories. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Text relocations in kernel modules
On 03/30/12 18:46, Konstantin Belousov wrote: > Reread what I wrote to you. Also, it pays off learning how ELF works > before making conclusion from the absence of the output of readelf -d. > Amd64 modules _are not_ shared objects. Whether or not they are shared objects is irrelevant. The fact is that they have text relocations, which interfere with ASLR. Do I need to produce exploit code before you take me seriously? signature.asc Description: OpenPGP digital signature
Re: Text relocations in kernel modules
On Fri, Mar 30, 2012 at 06:34:55PM -0400, Richard Yao wrote: > On 03/30/12 16:36, Konstantin Belousov wrote: > > First, there _are_ relocations against text in the amd64 modules, but I > > suspect that your scripts do not detect this. Most likely, scripts look > > for DT_TEXTREL dynamic tag, and tags are only present in the executables > > or shared objects, not in the object files. The amd64 modules are object > > files, so you just mis-interpret the situation. > > readelf is a part of binutils. It is not a script. Here is the version > that Gentoo/FreeBSD uses: So you completely missed what I told you. > > # readelf --version > GNU readelf (GNU Binutils) 2.20.1.20100303 > Copyright 2009 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or (at your option) any later > version. > This program has absolutely no warranty. > > In addition, this is what it says when I ask it to look at virtio_blk.ko: > > # readelf -d /boot/modules/virtio_blk.ko > > Dynamic section at offset 0x2f6c contains 13 entries: > TagType Name/Value > 0x0004 (HASH) 0xd4 > 0x6ef5 (GNU_HASH) 0x480 > 0x0005 (STRTAB) 0x9d0 > 0x0006 (SYMTAB) 0x4e0 > 0x000a (STRSZ) 1295 (bytes) > 0x000b (SYMENT) 16 (bytes) > 0x0011 (REL)0xee0 > 0x0012 (RELSZ) 1664 (bytes) > 0x0013 (RELENT) 8 (bytes) > 0x0016 (TEXTREL)0x0 > 0x001e (FLAGS) TEXTREL > 0x6ffa (RELCOUNT) 87 > 0x (NULL) 0x0 > > Running the same command on amd64 FreeBSD's version returns nothing. I > have attached the result of `readelf -a ...` on both the i386 version > and the amd64 version. Reread what I wrote to you. Also, it pays off learning how ELF works before making conclusion from the absence of the output of readelf -d. Amd64 modules _are not_ shared objects. > > > Second, from what you wrote, I see the issue in either wrong policy > > being established in your project, or (another) mis-interpretation of > > the policy. Indeed, having text relocations in the shared objects is > > bad, because said relocations hinder text pages sharing. Relocated page > > is modified, so COW mechanism causes it to become private to process. > > I believe that relocations also cause the linker to work harder when the > modules themselves are loaded the first time. They can also cause bugs > when code is ported to another architecture. I can only answer that this is your fantasy, however ample. I see that conversation is going nowhere, I will not reply further. > > > On the other hand, there is only one instance of the loaded kernel module, > > its text segment (or section, for amd64) is not shared, so modifications > > to the text pages do not cause increased memory use. More, not compiling > > modules with -fPIC (absence of -fPIC is what makes the text relocations to > > appear in the final link result) makes the code faster, esp. on i386. > > Compiling with -fPIC breaks the build. > > > So, there is nothing to report, and fix is outside the FreeBSD domain: > > either fix your policy by not stating that text relocation in kernel > > module is banned, or just find that policy only applicable to usermode > > objects. > > Linux has no such text relocations in its modules. I have checked on > both i386 and amd64. I have difficulty believing that FreeBSD needs text > relocations when Linux does not. > > I am fairly certain that this is going to interfere with ASLR in the > kernel, which is a security issue. It is definitely something to report. pgphVz6PK3bYZ.pgp Description: PGP signature
Re: Text relocations in kernel modules
On Fri, Mar 30, 2012 at 04:11:29PM -0400, Richard Yao wrote: > On 03/30/12 15:46, Konstantin Belousov wrote: > > On Fri, Mar 30, 2012 at 03:42:22PM -0400, Richard Yao wrote: > >> On 03/30/12 15:07, Konstantin Belousov wrote: > Is this a bug? > >>> No. This is by design. > >>> > >>> Why do you consider this a bug ? > >> > >> It occurs on i386, but not amd64. It could be that something is wrong > >> with how things are being compiled i386, or it could be that i386 > >> requires things to be compiled this way. I do not know which. > >> > > Again, let me repeat my question. Why do you consider the presence > > of relocations against text section a problem ? > > The linker emits warnings: > i686-gentoo-freebsd9.0-ld: warning: creating a DT_TEXTREL in object. > > Furthermore, this triggers a QA check in Gentoo/FreeBSD's package manager. > > * QA Notice: The following files contain runtime text relocations > * Text relocations force the dynamic linker to perform extra > * work at startup, waste system resources, and may pose a security > * risk. On some architectures, the code may not even function > * properly, if at all. > * For more information, see http://hardened.gentoo.org/pic-fix-guide.xml > * Please include the following list of files in your report: > * TEXTREL boot/modules/if_vtnet.ko > * TEXTREL boot/modules/virtio_blk.ko > * TEXTREL boot/modules/virtio.ko > * TEXTREL boot/modules/virtio_balloon.ko > * TEXTREL boot/modules/virtio_pci.ko > > I wrote that ebuild as part of something entirely unrelated. If it is a > feature, I can disable the QA check, but I should at least know why the > text relocations are needed. > > Gentoo maintainers are expected to patch text relocations and send > patches upstream. The only exception is in the case of binary packages, > which they cannot patch. > > Investigating the text relocations in my port of emulators/virtio-kmod > revealed that all kernel modules on i386 Gentoo/FreeBSD have text > relocations, yet none have them on amd64 FreeBSD, so I do not know > whether this is a bug or a feature. > First, there _are_ relocations against text in the amd64 modules, but I suspect that your scripts do not detect this. Most likely, scripts look for DT_TEXTREL dynamic tag, and tags are only present in the executables or shared objects, not in the object files. The amd64 modules are object files, so you just mis-interpret the situation. Second, from what you wrote, I see the issue in either wrong policy being established in your project, or (another) mis-interpretation of the policy. Indeed, having text relocations in the shared objects is bad, because said relocations hinder text pages sharing. Relocated page is modified, so COW mechanism causes it to become private to process. On the other hand, there is only one instance of the loaded kernel module, its text segment (or section, for amd64) is not shared, so modifications to the text pages do not cause increased memory use. More, not compiling modules with -fPIC (absence of -fPIC is what makes the text relocations to appear in the final link result) makes the code faster, esp. on i386. So, there is nothing to report, and fix is outside the FreeBSD domain: either fix your policy by not stating that text relocation in kernel module is banned, or just find that policy only applicable to usermode objects. pgpc8leWKmOO5.pgp Description: PGP signature
Re: Text relocations in kernel modules
On 03/30/12 15:46, Konstantin Belousov wrote: > On Fri, Mar 30, 2012 at 03:42:22PM -0400, Richard Yao wrote: >> On 03/30/12 15:07, Konstantin Belousov wrote: Is this a bug? >>> No. This is by design. >>> >>> Why do you consider this a bug ? >> >> It occurs on i386, but not amd64. It could be that something is wrong >> with how things are being compiled i386, or it could be that i386 >> requires things to be compiled this way. I do not know which. >> > Again, let me repeat my question. Why do you consider the presence > of relocations against text section a problem ? The linker emits warnings: i686-gentoo-freebsd9.0-ld: warning: creating a DT_TEXTREL in object. Furthermore, this triggers a QA check in Gentoo/FreeBSD's package manager. * QA Notice: The following files contain runtime text relocations * Text relocations force the dynamic linker to perform extra * work at startup, waste system resources, and may pose a security * risk. On some architectures, the code may not even function * properly, if at all. * For more information, see http://hardened.gentoo.org/pic-fix-guide.xml * Please include the following list of files in your report: * TEXTREL boot/modules/if_vtnet.ko * TEXTREL boot/modules/virtio_blk.ko * TEXTREL boot/modules/virtio.ko * TEXTREL boot/modules/virtio_balloon.ko * TEXTREL boot/modules/virtio_pci.ko I wrote that ebuild as part of something entirely unrelated. If it is a feature, I can disable the QA check, but I should at least know why the text relocations are needed. Gentoo maintainers are expected to patch text relocations and send patches upstream. The only exception is in the case of binary packages, which they cannot patch. Investigating the text relocations in my port of emulators/virtio-kmod revealed that all kernel modules on i386 Gentoo/FreeBSD have text relocations, yet none have them on amd64 FreeBSD, so I do not know whether this is a bug or a feature. signature.asc Description: OpenPGP digital signature
Re: Text relocations in kernel modules
On 03/30/12 15:07, Konstantin Belousov wrote: >> Is this a bug? > No. This is by design. > > Why do you consider this a bug ? It occurs on i386, but not amd64. It could be that something is wrong with how things are being compiled i386, or it could be that i386 requires things to be compiled this way. I do not know which. signature.asc Description: OpenPGP digital signature
Re: Text relocations in kernel modules
On Fri, Mar 30, 2012 at 01:38:14PM -0400, Richard Yao wrote: > As a disclaimer, I would like to clarify that Gentoo/FreeBSD uses a > FreeBSD userland and that Gentoo/FreeBSD has nothing to do with Debian > GNU/kFreeBSD. People seem to think Gentoo/FreeBSD is related to Debian > GNU/kFreeBSD, which has made collaboration difficult. > > With that said, Gentoo Portage is warning about text relocations in > kernel modules. This is in a Gentoo/FreeBSD port of > emulators/freebsd-kmod that I wrote. For instance, I see: > > # readelf -d /boot/modules/virtio.ko > > Dynamic section at offset 0x2f6c contains 13 entries: > TagType Name/Value > 0x0004 (HASH) 0xd4 > 0x6ef5 (GNU_HASH) 0x238 > 0x0005 (STRTAB) 0x4a8 > 0x0006 (SYMTAB) 0x298 > 0x000a (STRSZ) 397 (bytes) > 0x000b (SYMENT) 16 (bytes) > 0x0011 (REL)0x638 > 0x0012 (RELSZ) 1568 (bytes) > 0x0013 (RELENT) 8 (bytes) > 0x0016 (TEXTREL)0x0 > 0x001e (FLAGS) TEXTREL > 0x6ffa (RELCOUNT) 108 > 0x (NULL) 0x0 > > Checking /boot/kernel, it seems that all modules have text relocations. > My Gentoo/FreeBSD install is a 32-bit chroot on a ZFS Guru install of > amd64 FreeBSD. amd64 FreeBSD does not appear to have any text relocations. > > I don't have a reference i386 install, but according to frogs in > ##freebsd on freenode, his i386 FreeBSD also has text relocations. > > Is this a bug? No. This is by design. Why do you consider this a bug ? > > Yours truly, > Richard Yao > > On 03/30/12 12:49, Richard Yao wrote: > > Dear Ports Maintainers and kuriyama, > > > > emulators/freebsd-kmod has a typo in pkg-descr, where it says "lodable" > > instead of "loadable". > > > > In addition, I have done the work necessary to port > > emulators/freebsd-kmod to Gentoo/FreeBSD. > > > > https://bugs.gentoo.org/show_bug.cgi?id=410199 > > > > The ebuild contains a few improvements on the original FreeBSD port > > where we copy only the parts of SYSDIR that we need to build the module. > > We also do hardlinks instead of copies when Gentoo Portage builds with > > user privileges. > > > > The NEEDSUBDIRS part of the ebuild was written by naota AT gentoo.org as > > part of Gentoo's review process. I have permission from him to upstream > > the improvements we made on the port. Feel free to adopt any > > improvements in the attachments in that bug report. > > > > Lastly, I have sent an email to gentoo-dev AT lists.gentoo.org and > > gentoo-bsd AT lists.gentoo.org requesting that the FreeBSD specific > > parts of the portage tree be relicensed under terms of the BSD-2 > > license. With a little luck, it will be possible to upstream > > improvements made in Gentoo/FreeBSD without any hassle in the future. > > > > Yours truly, > > Richard Yao > > > > pgpl5RLyaPw25.pgp Description: PGP signature
Text relocations in kernel modules
As a disclaimer, I would like to clarify that Gentoo/FreeBSD uses a FreeBSD userland and that Gentoo/FreeBSD has nothing to do with Debian GNU/kFreeBSD. People seem to think Gentoo/FreeBSD is related to Debian GNU/kFreeBSD, which has made collaboration difficult. With that said, Gentoo Portage is warning about text relocations in kernel modules. This is in a Gentoo/FreeBSD port of emulators/freebsd-kmod that I wrote. For instance, I see: # readelf -d /boot/modules/virtio.ko Dynamic section at offset 0x2f6c contains 13 entries: TagType Name/Value 0x0004 (HASH) 0xd4 0x6ef5 (GNU_HASH) 0x238 0x0005 (STRTAB) 0x4a8 0x0006 (SYMTAB) 0x298 0x000a (STRSZ) 397 (bytes) 0x000b (SYMENT) 16 (bytes) 0x0011 (REL)0x638 0x0012 (RELSZ) 1568 (bytes) 0x0013 (RELENT) 8 (bytes) 0x0016 (TEXTREL)0x0 0x001e (FLAGS) TEXTREL 0x6ffa (RELCOUNT) 108 0x (NULL) 0x0 Checking /boot/kernel, it seems that all modules have text relocations. My Gentoo/FreeBSD install is a 32-bit chroot on a ZFS Guru install of amd64 FreeBSD. amd64 FreeBSD does not appear to have any text relocations. I don't have a reference i386 install, but according to frogs in ##freebsd on freenode, his i386 FreeBSD also has text relocations. Is this a bug? Yours truly, Richard Yao On 03/30/12 12:49, Richard Yao wrote: > Dear Ports Maintainers and kuriyama, > > emulators/freebsd-kmod has a typo in pkg-descr, where it says "lodable" > instead of "loadable". > > In addition, I have done the work necessary to port > emulators/freebsd-kmod to Gentoo/FreeBSD. > > https://bugs.gentoo.org/show_bug.cgi?id=410199 > > The ebuild contains a few improvements on the original FreeBSD port > where we copy only the parts of SYSDIR that we need to build the module. > We also do hardlinks instead of copies when Gentoo Portage builds with > user privileges. > > The NEEDSUBDIRS part of the ebuild was written by naota AT gentoo.org as > part of Gentoo's review process. I have permission from him to upstream > the improvements we made on the port. Feel free to adopt any > improvements in the attachments in that bug report. > > Lastly, I have sent an email to gentoo-dev AT lists.gentoo.org and > gentoo-bsd AT lists.gentoo.org requesting that the FreeBSD specific > parts of the portage tree be relicensed under terms of the BSD-2 > license. With a little luck, it will be possible to upstream > improvements made in Gentoo/FreeBSD without any hassle in the future. > > Yours truly, > Richard Yao > signature.asc Description: OpenPGP digital signature
