Re: Text relocations in kernel modules
kpneal at 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: 157k interrupts per second causing 60% CPU load on idle system
On 25 March 2012 22:26, Matt Thyer matt.th...@gmail.com wrote: Does anyone know if and when this driver was merged from current to 8-STABLE ? If I can work out what revision that occurred in I'll go back to just before then to confirm if the problem exists. In the -CURRENT list I've been told that the new driver was introduced into 8-STABLE at revision 230921. I reverted to that revision but the problem was still apparent. So I've now tried: - Previous BIOS - Updating the controller firmware from phase 7 to phase 11 - Going back to the old (pre LSI authored) mps driver But all to no avail. What has worked is to move the single SATA 3 (6 Gbps) drive (the other 7 drives are SATA 2) to the onboard SATA 2 Intel controller. So it seems that both the old and new mps driver have a problem with the Western Digital WD20EARX SATA 3 drive on a SuperMicro AOC-USAS2-L8i (SAS 6G) controller (flashed with -IT firmware). I'll continue this in the -CURRENT list in the thread about the new driver as that's where the main discussion has been. ___ 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: 157k interrupts per second causing 60% CPU load on idle system
-Original Message- From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd- sta...@freebsd.org] On Behalf Of Matt Thyer Sent: Wednesday, April 04, 2012 5:50 PM To: Mike Tancsa Cc: freebsd-stable@freebsd.org Subject: Re: 157k interrupts per second causing 60% CPU load on idle system On 25 March 2012 22:26, Matt Thyer matt.th...@gmail.com wrote: Does anyone know if and when this driver was merged from current to 8-STABLE ? If I can work out what revision that occurred in I'll go back to just before then to confirm if the problem exists. In the -CURRENT list I've been told that the new driver was introduced into 8-STABLE at revision 230921. I reverted to that revision but the problem was still apparent. So I've now tried: - Previous BIOS - Updating the controller firmware from phase 7 to phase 11 - Going back to the old (pre LSI authored) mps driver But all to no avail. What has worked is to move the single SATA 3 (6 Gbps) drive (the other 7 drives are SATA 2) to the onboard SATA 2 Intel controller. So it seems that both the old and new mps driver have a problem with the Western Digital WD20EARX SATA 3 drive on a SuperMicro AOC-USAS2-L8i (SAS 6G) controller (flashed with -IT firmware). I'll continue this in the -CURRENT list in the thread about the new driver as that's where the main discussion has been. Mike, Have your purchase LSI controller through Channel or OEM ? It would be a difficult for developers to help you without any support channel invovoled ? If possible can you contact LSI support channel ? ~ Kashyap ___ 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: 157k interrupts per second causing 60% CPU load on idle system
On 4 April 2012 21:55, Desai, Kashyap kashyap.de...@lsi.com wrote: Mike, Have your purchase LSI controller through Channel or OEM ? It would be a difficult for developers to help you without any support channel invovoled ? If possible can you contact LSI support channel ? Kashyap, It's me, Matt, not Mike reporting this problem. I purchased the Super Micro card off eBay through a seller with good reputation. I've bought a couple of said cards through him now. I'm not sure why you are thinking the lack of middle men would be a problem. I hope that Super Micro LSI would both be interested in a detailed report of a problem. ___ 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: 157k interrupts per second causing 60% CPU load on idle system
Matt, Sorry for addressing to wrong person.! I am working in Device Driver group and it difficult to track request coming through emails. We can solve those request through emails which are minor/medium in complexity. There are some group in LSI which has expertise to root cause issue and provide better support than developers. Sometimes issue can be non-driver issue (e.a Can be hw issue/fw issues etc.) and those issue need customer interaction and may be sometimes reproduction. So I request to contact LSI support channel ( at least for complex issues) to get better tracking and speed up resolution. ` Kashyap From: Matt Thyer [mailto:matt.th...@gmail.com] Sent: Wednesday, April 04, 2012 6:08 PM To: Desai, Kashyap Cc: Mike Tancsa; freebsd-stable@freebsd.org; McConnell, Stephen Subject: Re: 157k interrupts per second causing 60% CPU load on idle system On 4 April 2012 21:55, Desai, Kashyap kashyap.de...@lsi.commailto:kashyap.de...@lsi.com wrote: Mike, Have your purchase LSI controller through Channel or OEM ? It would be a difficult for developers to help you without any support channel invovoled ? If possible can you contact LSI support channel ? Kashyap, It's me, Matt, not Mike reporting this problem. I purchased the Super Micro card off eBay through a seller with good reputation. I've bought a couple of said cards through him now. I'm not sure why you are thinking the lack of middle men would be a problem. I hope that Super Micro LSI would both be interested in a detailed report of a problem. ___ 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: kpneal at 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
Ian Lepore freebsd at 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: 157k interrupts per second causing 60% CPU load on idle system
On Wed, Apr 4, 2012 at 5:19 AM, Matt Thyer matt.th...@gmail.com wrote: So it seems that both the old and new mps driver have a problem with the Western Digital WD20EARX SATA 3 drive on a SuperMicro AOC-USAS2-L8i (SAS 6G) controller (flashed with -IT firmware). I wouldn't say the driver has a problem with that specific drive. More that it might have a problem with a mixed SATA2/SATA3 setup. I have a 9-STABLE box with 24x WDC WD2002FAEX SATA3 (6 Gbps) drives attached to 3 SuperMicro AOC-USAS2-8Li controllers, using the new mps(4) driver without any issues. Was actually amazed yesterday when I say it doing writes just shy of 500 MBps to the ZFS pool, via zfs send/recv from another box. No issues with excessive interrupts. Using 10.0 firmware on the controllers. -- Freddie Cash fjwc...@gmail.com ___ 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
On Wed, 2012-04-04 at 15:05 +, jb wrote: Ian Lepore freebsd at 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
Compatibility with the new XEON Processors
Hello. Does anyone know if FreeBSD 8.2 and FreeBSD 9.1 are fully compatible with this processor: Intel XEON E3 1270 ?. Thank you. ___ 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 jb.1234a...@gmail.com wrote: kpneal at 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: [stable-ish 9] Dell R815 ipmi(4) attach failure
John Baldwin writes:
| On Tuesday, April 03, 2012 12:37:50 pm Doug Ambrisko wrote:
| John Baldwin writes:
| | On Monday, April 02, 2012 7:27:13 pm Doug Ambrisko wrote:
| | Doug Ambrisko writes:
| | | John Baldwin writes:
| | | | On Saturday, March 31, 2012 3:25:48 pm Doug Ambrisko wrote:
| | | | Sean Bruno writes:
| | | | | Noting a failure to attach to the onboard IPMI controller with
| this
| | dell
| | | | | R815. Not sure what to start poking at and thought I'd though
| this
| | over
| | | | | here for comment.
| | | | |
| | | | | -bash-4.2$ dmesg |grep ipmi
| | | | | ipmi0: KCS mode found at io 0xca8 on acpi
| | | | | ipmi1: IPMI System Interface on isa0
| | | | | device_attach: ipmi1 attach returned 16
| | | | | ipmi1: IPMI System Interface on isa0
| | | | | device_attach: ipmi1 attach returned 16
| | | | | ipmi0: Timed out waiting for GET_DEVICE_ID
| | | |
| | | | I've run into this recently. A quick hack to fix it is:
| | | |
| | | | Index: ipmi.c
| | | |
| ===
| | | | RCS file: /cvs/src/sys/dev/ipmi/ipmi.c,v
| | | | retrieving revision 1.14
| | | | diff -u -p -r1.14 ipmi.c
| | | | --- ipmi.c14 Apr 2011 07:14:22 - 1.14
| | | | +++ ipmi.c31 Mar 2012 19:18:35 -
| | | | @@ -695,7 +695,6 @@ ipmi_startup(void *arg)
| | | |if (error == EWOULDBLOCK) {
| | | |device_printf(dev, Timed out waiting for
| GET_DEVICE_ID\n);
| | | |ipmi_free_request(req);
| | | | - return;
| | | |} else if (error) {
| | | |device_printf(dev, Failed GET_DEVICE_ID: %d\n, error);
| | | |ipmi_free_request(req);
| | | |
| | | | The issue is that the wakeup doesn't actually wake up the msleep
| | | | in ipmi_submit_driver_request. The error being reported is that
| | | | the msleep timed out. This doesn't seem to be critical problem
| | | | since after this things seemed to work work. I saw this on 9.X.
| | | | Haven't seen it on 8.2. Not sure about -current.
| | | |
| | | | It doesn't happen on all machines.
| | | |
| | | | Hmm, are you seeing the KCS thread manage the request but the
| wakeup()
| | is
| | | | lost?
| | |
| | | It was a couple of weeks ago that I played with it. I put printf's
| | | around the msleep and wakeup. I saw the wakeup called but the sleep
| | | not get it. I can try the test again later today. Right now my main
| | | work machine is recovering from a power outage. This was with 9.0
| | | when I first saw it. This issue seems to only happen at boot time.
| | | If I kldload the module after the system is booted then it seems to
| work
| | | okay. The KCS part was working fine and got the data okay from the
| | | request. I haven't seen or heard any issues with 8.2.
| |
| | With -current I patched ipmi.c with:
| | Index: ipmi.c
| | ===
| | --- ipmi.c (revision 233806)
| | +++ ipmi.c (working copy)
| | @@ -523,7 +523,11 @@
| | * waiter that we awaken.
| | */
| | if (req-ir_owner == NULL)
| | +{
| | +device_printf(sc-ipmi_dev, DEBUG %s %d before wakeup
| | %d\n,__FUNCTION__,__LINE__,ticks);
| | wakeup(req);
| | +device_printf(sc-ipmi_dev, DEBUG %s %d after wakeup
| | %d\n,__FUNCTION__,__LINE__,ticks);
| | +}
| | else {
| | dev = req-ir_owner;
| | TAILQ_INSERT_TAIL(dev-ipmi_completed_requests, req,
| | ir_link);
| | @@ -543,7 +547,11 @@
| | IPMI_LOCK(sc);
| | error = sc-ipmi_enqueue_request(sc, req);
| | if (error == 0)
| | +{
| | +device_printf(sc-ipmi_dev, DEBUG %s %d before msleep
| | %d\n,__FUNCTION__,__LINE__,ticks);
| | error = msleep(req, sc-ipmi_lock, 0, ipmireq, timo);
| | +device_printf(sc-ipmi_dev, DEBUG %s %d after msleep
| | %d\n,__FUNCTION__,__LINE__,ticks);
| | +}
| | if (error == 0)
| | error = req-ir_error;
| | IPMI_UNLOCK(sc);
| | @@ -695,8 +703,11 @@
| | error = ipmi_submit_driver_request(sc, req, MAX_TIMEOUT);
| | if (error == EWOULDBLOCK) {
| | device_printf(dev, Timed out waiting for
| GET_DEVICE_ID\n);
| | + printf(DJA\n);
| | +/*
| | ipmi_free_request(req);
| | return;
| | +*/
| | } else if (error) {
| | device_printf(dev, Failed GET_DEVICE_ID: %d\n, error);
| | ipmi_free_request(req);
| |
| | and get
| |# dmesg | grep ipmi
| |ipmi0: KCS mode found at io 0xca8 on acpi
| |ipmi1: IPMI System Interface on isa0
| |device_attach: ipmi1 attach returned 16
| |ipmi1: IPMI System Interface on isa0
| |
Re: Text relocations in kernel modules
On Wed, Apr 4, 2012 at 8:58 AM, Ian Lepore free...@damnhippie.dyndns.org 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
Peter Wemm peter at 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
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 jb.1234a...@gmail.com wrote: Peter Wemm peter at 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
On Wed, Apr 4, 2012 at 10:34 AM, jb jb.1234a...@gmail.com wrote: Peter Wemm peter at 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
Peter Wemm peter at 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: [stable-ish 9] Dell R815 ipmi(4) attach failure
On Wednesday, April 04, 2012 12:24:33 pm Doug Ambrisko wrote:
John Baldwin writes:
| On Tuesday, April 03, 2012 12:37:50 pm Doug Ambrisko wrote:
| John Baldwin writes:
| | On Monday, April 02, 2012 7:27:13 pm Doug Ambrisko wrote:
| | Doug Ambrisko writes:
| | | John Baldwin writes:
| | | | On Saturday, March 31, 2012 3:25:48 pm Doug Ambrisko wrote:
| | | | Sean Bruno writes:
| | | | | Noting a failure to attach to the onboard IPMI controller
with
| this
| | dell
| | | | | R815. Not sure what to start poking at and thought I'd
though
| this
| | over
| | | | | here for comment.
| | | | |
| | | | | -bash-4.2$ dmesg |grep ipmi
| | | | | ipmi0: KCS mode found at io 0xca8 on acpi
| | | | | ipmi1: IPMI System Interface on isa0
| | | | | device_attach: ipmi1 attach returned 16
| | | | | ipmi1: IPMI System Interface on isa0
| | | | | device_attach: ipmi1 attach returned 16
| | | | | ipmi0: Timed out waiting for GET_DEVICE_ID
| | | |
| | | | I've run into this recently. A quick hack to fix it is:
| | | |
| | | | Index: ipmi.c
| | | |
| ===
| | | | RCS file: /cvs/src/sys/dev/ipmi/ipmi.c,v
| | | | retrieving revision 1.14
| | | | diff -u -p -r1.14 ipmi.c
| | | | --- ipmi.c 14 Apr 2011 07:14:22 - 1.14
| | | | +++ ipmi.c 31 Mar 2012 19:18:35 -
| | | | @@ -695,7 +695,6 @@ ipmi_startup(void *arg)
| | | | if (error == EWOULDBLOCK) {
| | | | device_printf(dev, Timed out waiting for
| GET_DEVICE_ID\n);
| | | | ipmi_free_request(req);
| | | | - return;
| | | | } else if (error) {
| | | | device_printf(dev, Failed GET_DEVICE_ID:
%d\n,
error);
| | | | ipmi_free_request(req);
| | | |
| | | | The issue is that the wakeup doesn't actually wake up the
msleep
| | | | in ipmi_submit_driver_request. The error being reported is
that
| | | | the msleep timed out. This doesn't seem to be critical
problem
| | | | since after this things seemed to work work. I saw this on
9.X.
| | | | Haven't seen it on 8.2. Not sure about -current.
| | | |
| | | | It doesn't happen on all machines.
| | | |
| | | | Hmm, are you seeing the KCS thread manage the request but the
| wakeup()
| | is
| | | | lost?
| | |
| | | It was a couple of weeks ago that I played with it. I put
printf's
| | | around the msleep and wakeup. I saw the wakeup called but the
sleep
| | | not get it. I can try the test again later today. Right now my
main
| | | work machine is recovering from a power outage. This was with 9.0
| | | when I first saw it. This issue seems to only happen at boot
time.
| | | If I kldload the module after the system is booted then it seems
to
| work
| | | okay. The KCS part was working fine and got the data okay from
the
| | | request. I haven't seen or heard any issues with 8.2.
| |
| | With -current I patched ipmi.c with:
| | Index: ipmi.c
| | ===
| | --- ipmi.c (revision 233806)
| | +++ ipmi.c (working copy)
| | @@ -523,7 +523,11 @@
| | * waiter that we awaken.
| | */
| | if (req-ir_owner == NULL)
| | +{
| | +device_printf(sc-ipmi_dev, DEBUG %s %d before wakeup
| | %d\n,__FUNCTION__,__LINE__,ticks);
| | wakeup(req);
| | +device_printf(sc-ipmi_dev, DEBUG %s %d after wakeup
| | %d\n,__FUNCTION__,__LINE__,ticks);
| | +}
| | else {
| | dev = req-ir_owner;
| | TAILQ_INSERT_TAIL(dev-ipmi_completed_requests,
req,
| | ir_link);
| | @@ -543,7 +547,11 @@
| | IPMI_LOCK(sc);
| | error = sc-ipmi_enqueue_request(sc, req);
| | if (error == 0)
| | +{
| | +device_printf(sc-ipmi_dev, DEBUG %s %d before msleep
| | %d\n,__FUNCTION__,__LINE__,ticks);
| | error = msleep(req, sc-ipmi_lock, 0, ipmireq,
timo);
| | +device_printf(sc-ipmi_dev, DEBUG %s %d after msleep
| | %d\n,__FUNCTION__,__LINE__,ticks);
| | +}
| | if (error == 0)
| | error = req-ir_error;
| | IPMI_UNLOCK(sc);
| | @@ -695,8 +703,11 @@
| | error = ipmi_submit_driver_request(sc, req, MAX_TIMEOUT);
| | if (error == EWOULDBLOCK) {
| | device_printf(dev, Timed out waiting for
| GET_DEVICE_ID\n);
| | + printf(DJA\n);
| | +/*
| | ipmi_free_request(req);
| | return;
| | +*/
| | } else if (error) {
| | device_printf(dev, Failed GET_DEVICE_ID: %d\n,
error);
| | ipmi_free_request(req);
| |
| |
