Activity for ibcs-us
-
Mb38 created ticket #17
Helping Debug
-
Timothy Wooller modified a comment on ticket #15
First of all I have to give a big shout out to Russell for doing work on what he describes as something he hates! It takes real commitment to do that. Virtualising SCO environments is becoming slightly more difficult with the less end-user friendly vmware owners, and solutions like Proxmox won't run OpenServer 6 and only runs 5.0.6 with a lot of work. So the idea of moving those difficult to recode solutions to a Linux environment is very inviting. Also, for some users the computer/network security...
-
First of all I have to give a big shout out to Russell for doing work on what he describes as something he hates! It take real commitment to do that. Virtualising SCO environments is becoming slightly more difficult with the less end-user friendly vmware owners, and solutions like Proxmox won't run OpenServer 6 and only runs 5.0.6 with a lot of work. So the idea of moving those difficult to recode solutions to a Linux environment is very inviting. Also, for some users the computer/network security...
-
Ed Reed posted a comment on ticket #16
Further info - this change is with respect to ibcs-us-4.2.1. For base reference to earlier kernel-based version of ibcs, I used ibcs-3.9.3 running in the following Linux: eer@sled11:/etc> uname -a Linux sled11 3.0.76-0.11-pae #1 SMP Fri Jun 14 08:21:43 UTC 2013 (ccab990) i686 i686 i386 GNU/Linux
-
I don't really know how to submit patches, and can recreate the diff file as I suspect is needed. Also, the changes include a possibly unnecessary restoration of a structure variable, and its assignment. The fact that the structure still has the member getting the assignment suggests it may be useful to restore its assignment. Development done with gcc-12 on OpenSUSE Leap 15.6 to support binary execution of statically linked ELF binary compiler frontend/backend/driver/inline optimizer modules from...
-
UW7 Personality, ELF statically linked binaries need BSS zeroed
-
Russell Stuart posted a comment on ticket #15
Under ibcs-us it's all different. In the original ibcs the kernel loaded the SCO binaries and executed them. Now the kernel doesn't know they exist, and it has no idea how to load coff binaries (which is what SCO is). Thus it's returning a Exec format error to the exec() call. In this new scheme a normal userspace program, ibcs-us is given the program to run as one of it's command line arguments. It loads the coff formated file into memory, intercepts the system calls in userspace and emulates them....
-
Keith Williams created ticket #15
Foxbase+
-
per-cxenix/misc.h AT_FDCWD and AT_EACCESS undefined on SUSE Leap 15.4
-
Thanks for solving this yourself Ed. Closing as requested.
-
Okay - switching to debian to try to reproduce your buildinfo environment. Close this ticket.
-
For the record, rediscovering this response, rather than asking it again ;-) Debian files, here I come.
-
Title line should read misc.c, not misc.h
-
per-cxenix/misc.h AT_FDCWD and AT_EACCESS undefined on SUSE Leap 15.4
-
serock created ticket #13
semaphore initialization failure
-
Juan Carlos Escartí created ticket #12
Congratulations
-
ibcs-us released /ibcs-us-4.2.1-1/ibcs-us_4.2.1-1.dsc
-
-
-
-
-
-
-
Release ibcs-us-4.2.1-1 - see ChangeLog.txt
-
Added tag ibcs-us-4.2.1-1 for changeset 332d0460da34
-
Added tag ibcs-us-4.2.0-1 for changeset 9f21cd6c2f75
-
Release ibcs-us-4.2.0-1 - see ChangeLog.txt
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Sergey Kuzmichov created ticket #11
Oracle Froms 3.0 (SCO) segfault
-
Rod Sheppard created ticket #10
D4GL (4js) COFF get segmentation violation
-
Iv'e got a work around by making /usr/fgl2c an tmpfs at startup, so something to do with the size of the data staructures or inodes being returned on this particular VM. where tge root fs is /dev/nvme0n1p2 60G 6.5G 54G 11% / I created my o\wn test AWS rhel8 machine (default free image), and it had no issue.
-
sh-4.2# file /usr/fgl2c/bin/fglWrt /usr/fgl2c/bin/fglWrt: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped sh-4.2# this also works fine on my inhouse rhel8 but not on the AWS rhel8
-
sh-4.2# file /usr/fgl2c/bin/fglWrt /usr/fgl2c/bin/fglWrt: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped sh-4.2#
-
Since the origianl post, I have also found that 1 32bit satically linked linux ELF binary fglWrt that is the the user license manager that comes with the informix 4gl also exhibits a similar problem when run with the -u option to verify users. sh-4.4# fglWrt -u ERROR(-6071):Cannot use directory '/usr/fgl2c/lock'. Check FGLDIR and verify if access rights are 'drwxrwxrwx'. running a system trace.... sh-4.4# (strace /usr/fgl2c/bin/fglWrt -u 2>&1) >fglWrt_u.strace fglWrt_u.strace attached, see line 53...
-
forgot to add.. these are the lines in the trace files I believe where I'm hitting the problem.. In callextdet_22220107.strace line 481: read(7, ERROR(-6071):Cannot use directory '/usr/fgl2c/lock'. In ibcs-us_callextdet_20220107.trace line 530: read(7, 0x00475A4C, 1024) read returns 1 (edx:1)
-
read(7, ERROR(-6071):Cannot use directory '/usr/fgl2c/lock'.
-
Rob Pomeroy posted a comment on ticket #5
Commenting to subscribe to issue - same (?) scenario, "Exec format error" with SCO/80386 COFF executable on RHEL 8. Working fine on Ubuntu 20.04.
-
-
-
-
-
-
-
-
Release ibcs-us-4.1.6-1 - see ChangeLog.txt
-
Added tag ibcs-us-4.1.6-1 for changeset 7cc9e03acbe9
-
I see you closed the ticket, and that's fine, unless you want me to document the resolution, which I've done above. I closed the ticket because there is not much I personally will do. I don't have a i286emul to test it on, I don't have any spare time, and as the ibcs-us man page says I don't particularly like working on the thing. And I like to keep my open tickets manageable. 4) in more than a decade of deployments on the internet by ICL for the UK MoD CHoTS program, and the NSA's BLACKER program,...
-
lol - yeah, that's what they say. You'll be amused to know that 1) GEMSOS is a Class A1 (under TCSEC) real time secure operating system that I work on for highly secure systems. 2) GEMSOS, as a security kernel together with the firmware and x86 architecture hardware, creates a security kernel whose design center is, as they say, security, rather than performance or speed or nifty gadgets. 3) like ALL other secure systems built as reference monitors implementing Mandatory Access Controls (MAC), GEMSOS...
-
svr4/sysi86.c case SI86DSCR
-
God lord, a fellow hacker who has read the Intel x86 Architecture documentation back in the 90's. They were such small books back then. One question I have about the user space IBCS you're working with - how do you access the LDT and GDT of the process from outside the kernel? You can't. All the crap Intel stuffed into them notwithstanding, their primary use back in the 8086/286 days was to increase the the addressing space beyond 64k using segments. Extending the register size 32bit is a much saner...
-
Okay, so according to http://docsrv.sco.com/cgi-bin/man?mansearchword=i286emul&mansection=C&lang=en , i286emul (and more importantly, SysVR2 and SysVR3 on i286) do, indeed, use GDT callgate 89: "i286emul reads the 286 program's text and data into memory and maps them through the LDT (Local Descriptor Table) (via sysi86(S)) as 286 text and data segments. It also sets callgate 89 in the GDT (Global Descriptor Table) (which is used by 286 programs for system calls) to point to a routine in i286emul....
-
svr4/sysi86.c case SI86DSCR
-
Giordano Contigiani posted a comment on ticket #7
thanks for the quick reply. I tried to compile the ibcs64 project with debian 10, then switched to 9 and finally to 8. but the differences of the headers are not very easy to solve (especially for me who know little about the linux environment). for now I continue to use my old VM centos 5.5 where the abi modules work fine. for the ibcs-us project, I have not investigated thoroughly, but I believe that my binary application makes some strange calls, the company that made the application no longer...
-
if I may, could you tell me on which version of debian did you compile the ibcs64 project? I don't remember, but the last bug fix was in 2011, so I'm guessing it was Debian Sarge. (ibcs-us) is fine for most applications, except one that manages the license, I couldn't get it to work. That's surprising. Is the licence manager likely doing something odd, like copy protection? If so, the issue is may be caused by ibcs-us modifying the binary on the fly. I am working on a version that doesn't do tha...
-
ibcs64
-
An mmap() of a file to address 0 is returning EPERM on RHEL 8, whereas it succeeds on every other Linux if you are root, or have the executable has CAP_SYS_RAW_IO. For anyone following along: Turns out that isn't what's going on. Instead the mmap() is failing because it's asking for both write and execute permissions on the mapped memory, ie asking PROT_EXEC|PROT_WRITE. That works on a standard kernel, but a program with those permissions can be a little easier to exploit easier so there are kernel...
-
Thanks Russell, I will see if I can get access. -- reply above this line -- Rodney Sheppard Software Engineer - Development Manager Trans-Mit Pty. Ltd. 7 Wendy Court Hampton Park, Vic 3976, Australia Phone... +61 3 87878744 Email...... rod@transmit.com.au Web....... www.transmit.com.au ----- Original Message ----- From: Russell Stuart To: [ibcs-us:tickets] Sent: Wednesday, January 06, 2021 9:21 PM Subject: [ibcs-us:tickets] #5 error running SCO coff on RHEL8 At long last I've had a chance to have...
-
At long last I've had a chance to have a look at this. An mmap() of a file to address 0 is returning EPERM on RHEL 8, whereas it succeeds on every other Linux if you are root, or have the executable has CAP_SYS_RAW_IO. The next step is normally to look at the kernel source to see if its possible to work around this. (That's how I learnt ibcs-us needs CAP_SYS_RAW_IO). Failing that with the source you could even patch the kernel and recompile. However, in a change as of RHEL 8, RedHat doesn't appear...
-
Actually the RHEL 7.8 runs on 3.10 kernel. May be this could be the reason. Is there any changes in Makefile/Configuration file ? I don't know. Sorry, but I don't have the time available to support old kernel versions. I barely have the time to support ibcs-us at all. cc: error: unrecognized command line option ‘-Wduplicated-cond’ cc: error: unrecognized command line option ‘-Wnull-dereference’ cc: error: unrecognized command line option ‘-ffile-prefix-map=.=./binfmt-coff’ These options were added...
-
mlthati posted a comment on ticket #6
Sir here is ther error : make make --directory binfmt-coff ../build/binfmt-coff.o make[1]: Entering directory /root/Desktop/ibcs-us-4.1.5/binfmt-coff' mkdir -p ../build/build-binfmt-coff cc -I ../include -g -O2 -fno-builtin -ffreestanding -Wall -Wextra -Wno-unused-parameter -Wno-sign-compare -Wduplicated-cond -Wlogical-op -Wnull-dereference -Wdouble-promotion -Wshadow -Werror -m32 -DIBCS_VERSION="\"4.0\"" -DCONFIG_BINFMT_XOUT_X286 -DCONFIG_ABI_TRACE -DCONFIG_ABI_SPX -DCONFIG_ABI_XTI -DCONFIG_ABI_SHINOMAP...
-
SIr Actually the RHEL 7.8 runs on 3.10 kernel. May be this could be the reason. Is there any changes in Makefile/Configuration file ? Please let me know On Sat, Nov 7, 2020 at 5:00 PM Russell Stuart rstuart@users.sourceforge.net wrote: Is there any kernel version issue. Is the code applicable for kernel 4 version ? Not that I'm aware of. It successfully compiles with kernels 4.19 and 5.9 on Debian. My guess is any compile issues on RedHat will be caused differences between the kernel headers shipped...
-
Is there any kernel version issue. Is the code applicable for kernel 4 version ? Not that I'm aware of. It successfully compiles with kernels 4.19 and 5.9 on Debian. My guess is any compile issues on RedHat will be caused differences between the kernel headers shipped on RedHat and the same headers shipped by Debian. Resolving that will be difficult without doing complies on both.
-
Thanks for your immediate response Sir, Is there any kernel version issue. Is the code applicable for kernel 4 version ? Sir, if possible please help me. I don't want to disturb you more On Sat, Nov 7, 2020 at 5:14 AM Russell Stuart rstuart@users.sourceforge.net wrote: status: open --> closed [tickets:#6] https://sourceforge.net/p/ibcs-us/tickets/6/ ibcs-us compilation on RHEL-7* Status: closed Milestone: 1.0 Created: Fri Nov 06, 2020 10:08 AM UTC by mlthati Last Updated: Fri Nov 06, 2020 11:43 PM...
-
ibcs-us compilation on RHEL-7
-
It's explained in the README.txt: https://ibcs-us.sourceforge.io/README.txt If that doesn't work then work is required. RedHat is both not a priority for me and a lot of work - I don't Redhat develop system set up. It may happen anyway - others have kindly offered ssh access to a suitable machine. And patches are accepted. :D
-
Dear Russell Stuart Sir, Please can you guide or provide any document to compile ibcs-us on RHEL 7.8 i.e 3.10 kernel to run sco based foxplus. Thanks in advance
-
Sir, Please let me know how to compile ibcs-us on RHEL-7.8 64bit OS to run older sco binaries, please
-
ibcs-us compilation on RHEL-7
-
If you need access to a dev/test RHEL 8 system, I can setup a user rstuart with your pub key from last time, and open a port to it. Rod -- reply above this line -- Rodney Sheppard Software Engineer - Development Manager Trans-Mit Pty. Ltd. 7 Wendy Court Hampton Park, Vic 3976, Australia Phone... +61 3 87878744 Email...... rod@transmit.com.au Web....... www.transmit.com.au ----- Original Message ----- From: Russell Stuart To: [ibcs-us:tickets] Sent: Wednesday, October 07, 2020 5:12 PM Subject: [ibcs-us:tickets]...
-
On 7/10/20 3:57 pm, Rodney Sheppard wrote: > FYI > I've tried compiling on RHEL 8 with the below result.... > In file included from ./misc.c:9: > ./misc.c: In function 'xnx_eaccess': > ./misc.c:311:31: error: 'AT_FDCWD' undeclared (first use in this function) > return (int)SYS(faccessat, AT_FDCWD, path, mode, AT_EACCESS); > ^~~~~~~~ > ../include/ibcs-us/ibcs/linux26-compat.h:44:59: note: in definition of > macro 'SYS' > #define SYS(name, args...) linux26_syscall(__NR_##name, ##args) > ^~~~ > ./misc.c:311:31:...
-
Sidao posted a comment on ticket #5
Hello. Some news about this topic ? I am having the some trouble.
-
csum.coff (attached) Usage: csum filename It generates a check sum of filename or stdin of no param I also get the error with all other coff binaries the ibcs-us version is 4.1.5 ibcs-us csum.coff works if run on rhel 7 Linux rhel72t21 3.10.0-1127.13.1.el7.x86_64 #1 SMP Fri Jun 12 14:34:17 EDT 2020 x86_64 x86_64 x86_64 GNU/Linux the kernel for rhel 8 is Linux rhel80t21 4.18.0-193.14.3.el8_2.x86_64 #1 SMP Mon Jul 20 15:02:29 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
-
error running SCO coff on RHEL8
-
Can you give me a copy of the binary (eg, email), csum.coff?
-
error running SCO coff on RHEL8
-
Wait() system call is not waiting
-
Hi Russell, That did the trick, there it was plain and clear in the man page, sorry should have read the man page. Rod -- reply above this line -- Rodney Sheppard Software Engineer - Development Manager Trans-Mit Pty. Ltd. 7 Wendy Court Hampton Park, Vic 3976, Australia Phone... +61 3 87878744 Fax.........+61 3 87875722 Email...... rod@transmit.com.au Web....... www.transmit.com.au ----- Original Message ----- From: Russell Stuart To: [ibcs-us:tickets] Sent: Tuesday, December 03, 2019 9:46 AM Subject:...
-
Wait() system call is not waiting
-
Fork() is returning 130332. That would be a Process ID that is bigger than 15 bits. IBCS has no problem with it itself, but the systems it emulates had 15 bit PID's and the code it runs sometimes assumes that. The steps for telling the kernel to only use 16 bit PID's are in the man page.
-
Wait() system call is not waiting
1 >
