Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
I had a few minutes today to try an experiment, and I'm afraid the idea of having ld always generate a PT_SUNWSTACK is a non-starter. The problem is that it overrides the behavior of 'set noexec_user_stack=1' in /etc/system, and can therefore quietly allow programs that would not previously been able to execute on the stack do so. Thanks for this investigation. There is another issue we haven't explored is the use a system call; there's a sysconf(_SC_STACK_PROT) but there's no way to set in on the fly. If we create a function to change it on the fly, we could make a LD_PRELOAD object which enforce it. The current mapped pages would not be protected but threadstacks and additional pages would be rw-. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] multibyte support for FTP in Solaris
Hello, I need to know if FTP has support for multibyte languages. Meaning, if the locale is set to be multibyte languages like Japanese/ Chinese, does FTP/FTPD in solaris support it? With Regards, Shilpa. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] USB pen drive not detected
In short, the Oracle executives said that the open source, community-driven OpenSolaris project as conceived and built by Sun Microsystems five years ago is dead. A quote from http://www.theregister.co.uk/2010/08/13/opensolaris_is_dead/ If the pen drive isn't detected, then perhaps another OS will detect it. I had problems with OpenSolaris not detecting hardware, but that h/w is detected with other operating systems. Oracle has closed development, so if it doesn't see the pen drive, then I suppose your going to write a driver for the OP? If not, then (s)he just sits on an old version of OpenSolaris and not utilizing their h/w they obviously want to get to work? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
I had a few minutes today to try an experiment, and I'm afraid the idea of having ld always generate a PT_SUNWSTACK is a non-starter. The problem is that it overrides the behavior of 'set noexec_user_stack=1' in /etc/system, and can therefore quietly allow programs that would not previously been able to execute on the stack do so. Thanks for this investigation. There is another issue we haven't explored is the use a system call; there's a sysconf(_SC_STACK_PROT) but there's no way to set in on the fly. If we create a function to change it on the fly, we could make a LD_PRELOAD object which enforce it. The current mapped pages would not be protected but threadstacks and additional pages would be rw-. Casper I picture this somehow as being just a bit more functionality added to mprotect(2): /* following magic to identify operating on that segment, rather than * a particular address */ #define ADDR_STACK (void *) (-1) #define ADDR_HEAP (void *) (-2) mprotect(ADDR_STACK, 0, (PROT_READ|PROT_WRITE|PROT_EXEC)); where a length of 0 implies something similar to what (MCL_CURRENT|MCL_FUTURE) implies with memcntl(2), namely to apply that behavior to both the present and future pages of the segment; that would combine applying mprotect() to the existing pages as well as setting p_stkprot or p_datprot in the proc structure. Such an interface would be ideal for runtime control either by the developer or after-the-fact with an LD_PRELOAD'ed shared object. Adding this functionality to mprotect() would be more understandable than a new function, and would avoid adding an additional system call. I don't imagine that any existing software (except _maybe_ an emulator?) would call mprotect() so often that the addition of a couple of if's or a switch() applied to the addr arg would present a performance problem. I haven't thought of a good way to search for what (if any) precedent there is for how other OSs handle this. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
I picture this somehow as being just a bit more functionality added to mprotect(2): /* following magic to identify operating on that segment, rather than * a particular address */ #define ADDR_STACK (void *) (-1) #define ADDR_HEAP (void *) (-2) mprotect(ADDR_STACK, 0, (PROT_READ|PROT_WRITE|PROT_EXEC)); It's a bit harder to bolt on the current implementation of the stack protection. And what is the ADDR_STACK *all* current thread stacks, the stack of main or the current stack? where a length of 0 implies something similar to what (MCL_CURRENT|MCL_FUTURE) implies with memcntl(2), namely to apply that behavior to both the present and future pages of the segment; that would combine applying mprotect() to the existing pages as well as setting p_stkprot or p_datprot in the proc structure. Such an interface would be ideal for runtime control either by the developer or after-the-fact with an LD_PRELOAD'ed shared object. Adding this functionality to mprotect() would be more understandable than a new function, and would avoid adding an additional system call. I don't imagine that any existing software (except _maybe_ an emulator?) would call mprotect() so often that the addition of a couple of if's or a switch() applied to the addr arg would present a performance problem. There is one particular issue where gcc uses a trampoline created on the stack when you are passing a nested function as a function argument. (A nested function requires an additional argument) Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
How does the trampoline work on architectures which have noexec bit
for stack by default, like sparcv9?
Olga
On Wed, Oct 20, 2010 at 2:26 PM, casper@sun.com wrote:
I picture this somehow as being just a bit more functionality added to
mprotect(2):
/* following magic to identify operating on that segment, rather than
* a particular address
*/
#define ADDR_STACK (void *) (-1)
#define ADDR_HEAP (void *) (-2)
mprotect(ADDR_STACK, 0, (PROT_READ|PROT_WRITE|PROT_EXEC));
It's a bit harder to bolt on the current implementation of the
stack protection. And what is the ADDR_STACK *all* current
thread stacks, the stack of main or the current stack?
where a length of 0 implies something similar to what (MCL_CURRENT|MCL_FUTURE)
implies with memcntl(2), namely to apply that behavior to both the present and
future pages of the segment; that would combine applying mprotect() to the
existing pages as well as setting p_stkprot or p_datprot in the proc
structure.
Such an interface would be ideal for runtime control either by
the developer or after-the-fact with an LD_PRELOAD'ed shared object.
Adding this functionality to mprotect() would be more understandable than
a new function, and would avoid adding an additional system call. I don't
imagine that any existing software (except _maybe_ an emulator?) would
call mprotect() so often that the addition of a couple of if's or a switch()
applied to the addr arg would present a performance problem.
There is one particular issue where gcc uses a trampoline created on the
stack when you are passing a nested function as a function argument.
(A nested function requires an additional argument)
Casper
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
--
, __ ,
{ \/`o;-Olga Kryzhanovska -;o`\/ }
.'-/`-/ olga.kryzhanov...@gmail.com \-`\-'.
`'-..-| / http://twitter.com/fleyta \ |-..-'`
/\/\ Solaris/BSD//C/C++ programmer /\/\
`--` `--`
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
How does the trampoline work on architectures which have noexec bit for stack by default, like sparcv9? A long time ago, I made some changes to gcc; I'm not sure if the changes are still in current gcc, but what happens is that we run mprotect() on the parts of the stack where we need to execute code. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
I picture this somehow as being just a bit more functionality added to mprotect(2): /* following magic to identify operating on that segment, rather than * a particular address */ #define ADDR_STACK (void *) (-1) #define ADDR_HEAP (void *) (-2) mprotect(ADDR_STACK, 0, (PROT_READ|PROT_WRITE|PROT_EXEC)); It's a bit harder to bolt on the current implementation of the stack protection. And what is the ADDR_STACK *all* current thread stacks, the stack of main or the current stack? Which does the PT_SUNWSTACK header apply to? I'm not sure what point there would be in per-thread control; if any one thread in an address space is exploitable, the whole address space is potentially corruptible. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] USB pen drive not detected
Or you can file a bug and wait until Solaris 11 Express to push for a fix. It's not like someone would fix your bugs right away with the way things were before Oracle. I still have bugs filed from years ago that haven't been fixed in ON. Like any other OS, if you want your bug fixed, it has to affect enough people or there has to be some support $$$ behind it. Speaking of other OS's, I've had just as many issues with Linux and BSD on new equipment. All it takes is a new chipset revision for things to not work. And even when there are fixes, they rarely work correctly the first or even the third time. Hell even with Windows, you're stuck in driver download hell when you build a PC with the latest stuff. And this is why Mac OS X does so well as a platform. Integrated OS and hardware, results in better user experience. Much as when Sun made workstations, everything would just work. If you don't control the hardware and the OS, you'll always have driver issues, which leads to disgruntle folks. Must be the reason why Apple is doing so well with their Macs;) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Virtualization Architect and Consultant Web: http://unixconsole.blogspot.com E-Mail: unixcons...@yahoo.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* - Original Message From: usafverteran us...@yahoo.com To: opensolaris-discuss@opensolaris.org Sent: Wed, October 20, 2010 7:07:17 AM Subject: Re: [osol-discuss] USB pen drive not detected In short, the Oracle executives said that the open source, community-driven OpenSolaris project as conceived and built by Sun Microsystems five years ago is dead. A quote from http://www.theregister.co.uk/2010/08/13/opensolaris_is_dead/ If the pen drive isn't detected, then perhaps another OS will detect it. I had problems with OpenSolaris not detecting hardware, but that h/w is detected with other operating systems. Oracle has closed development, so if it doesn't see the pen drive, then I suppose your going to write a driver for the OP? If not, then (s)he just sits on an old version of OpenSolaris and not utilizing their h/w they obviously want to get to work? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
Which does the PT_SUNWSTACK header apply to? It sets the fields in the proc structure which defines the stack protection. I'm not sure what point there would be in per-thread control; if any one thread in an address space is exploitable, the whole address space is potentially corruptible. It's different because mprotect() works on the process. Using mprotect requires you to run mprotect on all process stacks (as long as they are created by the library). I'm not sure that the kernel has sufficient information to figure that out. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
Which does the PT_SUNWSTACK header apply to? It sets the fields in the proc structure which defines the stack protection. I'm not sure what point there would be in per-thread control; if any one thread in an address space is exploitable, the whole address space is potentially corruptible. It's different because mprotect() works on the process. Using mprotect requires you to run mprotect on all process stacks (as long as they are created by the library). I'm not sure that the kernel has sufficient information to figure that out. Looks to me like http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/threads/thr.c checks sysconf(_SC_STACK_PROT) and honors it. The only problem is that it caches the return value (static variable stackprot), which would have to be invalidated by the mprotect() wrapper when the magic ADDR_STACK was used (so that it would pick up the new process-wide value that was also set in the proc structure). That would make that setting apply to all future thread stacks. In other words, that source file would have to add a _-prefixed library internal function that zeros stackprot. Maybe the best one can do is the main stack (current+future) and the thread stacks (future), if one can't readily figure out from either user space (syscall wrapper check) or kernel space the location and size of all the current thread stacks. I haven't looked at how sigaltstack() handling might get involved... -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
Looks to me like http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/threads/thr.c checks sysconf(_SC_STACK_PROT) and honors it. The only problem is that it caches the return value (static variable stackprot), which would have to be invalidated by the mprotect() wrapper when the magic ADDR_STACK was used (so that it would pick up the new process-wide value that was also set in the proc structure). That would make that setting apply to all future thread stacks. In other words, that source file would have to add a _-prefixed library internal function that zeros stackprot. Maybe the best one can do is the main stack (current+future) and the thread stacks (future), if one can't readily figure out from either user space (syscall wrapper check) or kernel space the location and size of all the current thread stacks. I haven't looked at how sigaltstack() handling might get involved... It's created by the application and so it's either rwx (32 bit or sparc) or rw- on amd64 unless they created it differently. (The differences are part of history and part of the implementation [PLT tables are instructions on SPARC but are data on x86]) Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
In that case, let me revise my earlier proposal: ADDR_HEAP would apply to the entire heap, current and future. ADDR_STACK would alter future behavior (both for main stack and by invalidating stackprot as previously mentioned, for thread stacks), but for the sake of gcc trampolines and the complexity of determining the bounds of all existing thread stacks, need not alter behavior with respect to current stack pages. (Hypothetically, if it could on some future platform, that's great, but it probably can't now.) That seems like a reasonable, non-disruptive best effort, which, since there are apparently some exceptions that make attempting to make the stack non-executable on 32-bit (x86 or spark) somewhat less than bulletproof anyway, should probably be good enough, and better than nothing (enough to complicate the work involved in an overflow attack, anyway). And quite possibly also good enough given that an LD_PRELOADed shared object that was designed to run very early (using a #pragma init(func) perhaps) should be able to know that it didn't have to worry about stepping on existing trampolines (or about multiple threads), and could take separate action (regular mprotect() usage with a bit of knowledge of the main stack layout) to protect the existing main stack. Any later use of ADDR_STACK, by _not_ altering the protection of existing stack pages, but only future ones, would avoid breaking anything unexpectedly. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
On 10/20/10 3:39 AM, casper@sun.com wrote: I had a few minutes today to try an experiment, and I'm afraid the idea of having ld always generate a PT_SUNWSTACK is a non-starter. The problem is that it overrides the behavior of 'set noexec_user_stack=1' in /etc/system, and can therefore quietly allow programs that would not previously been able to execute on the stack do so. Thanks for this investigation. There is another issue we haven't explored is the use a system call; there's a sysconf(_SC_STACK_PROT) but there's no way to set in on the fly. If we create a function to change it on the fly, we could make a LD_PRELOAD object which enforce it. The current mapped pages would not be protected but threadstacks and additional pages would be rw-. Casper Yet another possibility would be for ld to issue an extra PT_NULL program header, rather than a PT_SUNWSTACK. PT_NULL is a no-op, and would not alter behavior, but elfedit can be later be used to turn it into something else, such as PT_SUNWSTACK. - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] USB pen drive not detected
Octave Orgeron wrote: OpenIndiana is another option like so many now for x86 such as Belinix, Schillix, Nextenta, etc. I just find it distasteful for anyone to shoot down someone's questions or to even suggest they switch to another OS. If you feel that way, you shouldn't be here. +1 I feel the same about such distasteful things but I suppose it is important explaining to people that Opensolaris is Opensource project and that it is just accidentally that was the same name used for Sun binary distribution, previously known as Indiana. There is OpenIndiana/Illumos now and other opensolaris based distributions and it seems like very far from even being dead.. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] [OT] Openindiana mailing list
Sorry for the ot, but hoped to find an openindiana enthusiast who can coach me a bit. Trying to subscribe to openindiana-discuss mailing list at: http://openindiana.org/mailman/listinfo/openindiana-discuss My request is rejected with: Your subscription is not allowed because the email address you gave is insecure In the dozens, maybe over 100 Mailing groups I've belonged to over the years, I've never had this happen. I wanted to subscribe so as to be able to post through `gmane' to the Openindiana group. If the mailing list will not accept my email, how is a subscription possible? The statement says my address is insecure, but isn't that true of ANY email address that has been posted on the internet? Can anyone coach me ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [OT] Openindiana mailing list
On 10/21/10 11:16 AM, Harry Putnam wrote: Sorry for the ot, but hoped to find an openindiana enthusiast who can coach me a bit. Trying to subscribe to openindiana-discuss mailing list at: http://openindiana.org/mailman/listinfo/openindiana-discuss My request is rejected with: Your subscription is not allowed because the email address you gave is insecure hi ... opensolaris.org does not host that mailing list. Our lists are here: http://mail.opensolaris.org/mailman/listinfo. We used to have a list called indiana-discuss, but that list is not longer used and the archives are here: http://mail.opensolaris.org/pipermail/indiana-discuss/. Jim ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [OT] Openindiana mailing list
Jim Grisanzio jim.grisan...@oracle.com writes: hi ... opensolaris.org does not host that mailing list. Our lists are here: http://mail.opensolaris.org/mailman/listinfo. We used to have a list called indiana-discuss, but that list is not longer used and the archives are here: http://mail.opensolaris.org/pipermail/indiana-discuss/. Thank you, but that was understood. As mentioned in my post I hoped to find an openindiana enthusiast here as there are many lurking or posting here. Hoping to get to an openindiana reader who may know what I need to do since I'm rejected from that list as mentioned. And as noted in my subject line it is Off topic here... sorry. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
On 10/20/10 3:39 AM, casper@sun.com wrote: I had a few minutes today to try an experiment, and I'm afraid the idea of having ld always generate a PT_SUNWSTACK is a non-starter. The problem is that it overrides the behavior of 'set noexec_user_stack=1' in /etc/system, and can therefore quietly allow programs that would not previously been able to execute on the stack do so. Thanks for this investigation. There is another issue we haven't explored is the use a system call; there's a sysconf(_SC_STACK_PROT) but there's no way to set in on the fly. If we create a function to change it on the fly, we could make a LD_PRELOAD object which enforce it. The current mapped pages would not be protected but threadstacks and additional pages would be rw-. Casper Yet another possibility would be for ld to issue an extra PT_NULL program header, rather than a PT_SUNWSTACK. PT_NULL is a no-op, and would not alter behavior, but elfedit can be later be used to turn it into something else, such as PT_SUNWSTACK. While I still like the idea of a runtime function (new syscall or extension to mprotect()) to control default stack or heap permissions (mainly for use with a preloadable shared object to apply to existing binaries that don't have a spare program header, although some other runtime uses might be imaginable), leaving oneself the leeway to patch a binary statically also seems desirable. I gather that something had been done to leave some room so that for newer binaries, one could patch in runpath changes longer than the original runpath (whereas for older ones, one might well have been limited to a new runpath that fit in the same space as the old one). Are there any _current_ uses you can see for a spare unused (PT_NULL) program header other than changing it into a PT_SUNWSTACK header? (I imagine that there's always a good chance that future uses as yet unsupported might turn up, i.e. some future feature that could be retrofitted into existing binaries given a spare header to put it into; but I'm thinking now in terms of current possibilities.) -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [OT] Openindiana mailing list
On 10/21/10 11:50, Harry Putnam wrote: Thank you, but that was understood. As mentioned in my post I hoped to find an openindiana enthusiast here as there are many lurking or posting here. Hoping to get to an openindiana reader who may know what I need to do since I'm rejected from that list as mentioned. And as noted in my subject line it is Off topic here... sorry. Ah, I see, ok. Sorry about that. Perhaps there will be someone here who can help you out. Jim ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Fwd: [OT] Openindiana mailing list
Sorry for the last post, the original mail comes here, and explains... Message original Sujet: [osol-discuss] [OT] Openindiana mailing list Date : Wed, 20 Oct 2010 21:16:49 -0500 De :Harry Putnam rea...@newsguy.com Organisation : Still searching... Pour : opensolaris-discuss@opensolaris.org Sorry for the ot, but hoped to find an openindiana enthusiast who can coach me a bit. Trying to subscribe to openindiana-discuss mailing list at: http://openindiana.org/mailman/listinfo/openindiana-discuss My request is rejected with: Your subscription is not allowed because the email address you gave is insecure In the dozens, maybe over 100 Mailing groups I've belonged to over the years, I've never had this happen. I wanted to subscribe so as to be able to post through `gmane' to the Openindiana group. If the mailing list will not accept my email, how is a subscription possible? The statement says my address is insecure, but isn't that true of ANY email address that has been posted on the internet? Can anyone coach me ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
