Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • Jan 02 2019 02:34
    stasoid opened #106
  • Dec 21 2018 13:48
    eadmaster commented #103
  • Dec 21 2018 13:40
    eadmaster commented #103
  • Dec 21 2018 13:39
    eadmaster commented #103
  • Oct 02 2018 10:13
    eadmaster edited #105
  • Oct 01 2018 15:01
    eadmaster opened #105
  • Sep 05 2018 13:54
    stuaxo commented #104
  • Sep 05 2018 13:08
    DovaMerith commented #104
  • Sep 04 2018 21:41
    stuaxo commented #104
  • Sep 04 2018 01:56
    DovaMerith opened #104
  • Aug 18 2018 06:21
    unikzforce commented #102
  • Aug 16 2018 21:04
    q2dg commented #102
  • May 10 2018 11:46
    inoit commented #103
  • May 10 2018 11:41
    inoit opened #103
  • Nov 28 2017 17:36
    unikzforce edited #102
  • Nov 28 2017 17:35
    unikzforce opened #102
  • Sep 21 2017 15:21
    mdirik commented #101
  • May 18 2017 05:23
    Creeper20428 commented #100
  • Apr 15 2017 08:19
    wishstudio commented #62
  • Apr 15 2017 08:18
    wishstudio commented #101
I'm looking for more details about it : "I have also noted some interesting additions to recent CPUs and operating systems related to this case. One is the FSGSBASE extension instructions starting with Intel Sandy Bridge and AMD Steamroller. This allows a Ring 3 code to directly access the fs and gs registers."
For what I know about, writing to FS/GS.BASE MSR registers can only be done in Ring 0
Xiangyan Sun
To my knowledge the FSGSBASE instructions are designed to allow R/W access to fs/gs in Ring 3.
Otherwise we can already access them using MSR registers. Why bother create a new extension?
Ok, I didn't know there are dedicated instructions [RD/WR][F/G]SBASE. I thought they were speaking about dedicated MSR registers relative to FS/GS segments. So... those "new" instructions appears to be usable only in 64-bit mode. And there is no indication about RING execution restriction.
Messing with GS segment would be obviously wrong as it should contain TEB64. Messing with FS segment? well it seems to contain "random" value every times I launch a process.
Ok, I remade some tests with poking'n peeking through FS segment by using RDFSBASE/WRFSBASE instructions to get/set FS base address. It's pretty clear that Windows OS is writing "random" FS base because even reading the FS base after I set it, I get a "random" value. I guess the OS register context switch is not restoring the FS base register value.
Xiangyan Sun
I remember reverse engineered some piece of the context switch code. It looks like the OS just clears FS to zero when doing context switch.
that piece of the context switch code was for a 32-bit or 64-bit running code? I heard 64-bit windows should use WR[F/G]BASE instead of a MOV seg,reg.
I-One DarkSnow
Hello =) How i can install another distributive linux?
Henry Korir
Why is pacman failing ?
error: failed retrieving file 'core.db' from mirror.rackspace.com : The reque
sted URL returned error: 404
error: failed to update core (unexpected error)
error: failed retrieving file 'extra.db' from mirror.rackspace.com : The requ
ested URL returned error: 404
error: failed to update extra (unexpected error)
error: failed retrieving file 'community.db' from mirror.rackspace.com : The
requested URL returned error: 404
error: failed to update community (unexpected error)
error: failed to synchronize any databases
error: failed to init transaction (unexpected error)
@wishstudio any work around?
1 reply
David Macek
Maybe the mirror is no longer active.
Henry Korir
I checked the problem is because the mirrors are for x86_64 and my machine is i386.
I checked the problem is because the mirrors are for x86_64 and my machine is i386.
I changed the mirrors to point to archlinux32 servers and it worked but the flinux crushed.
I really need to use base-devel packages especially the gcc in flinux on i386 in windows 7. Is there any work-around?
Henry Korir
@elieux any pointers on the issue?
David Macek
Not really, sorry. Could be that Arch upgraded something and tries some new syscalls that Flinux doesn’t understand.
You can try upgrading selectively.
Henry Korir
That is what I have resorted to do, thanks
And gcc crushes after installation. Could it be that it is only meant for i686 and my i386 wont handle it? If so, how can I get the gcc working with flinux?
is this project is still maintained?
1 reply
Trung Nguyen
Anyone able to, and interested in, providing x86_64 support for this project?
@wishstudio Are you still online these days? I'm interested in contributing if you give me a few basic guidelines.
2 replies
For folks trying to upgrade -- it won't work because many things have changed and the old version of Arch that is compatible with flinux is outdated. The newest version that I was able to get to work was this one - https://archive.archlinux.org/iso/2017.03.01/archlinux-bootstrap-2017.03.01-i686.tar.gz -- unpack this inside the existing Arch Linux environment from 2015, in its own directory, and then move it out of the Arch Linux flinux virtual file system (i.e. move it to its own folder, in Windows, and launch flinux from the new folder).
I was not able to get any version of Arch Linux 32 to work - it appears that there are indeed new syscalls being used that aren't implemented. If you're curious, try installing something standalone from Arch Linux 32 like busybox. Then run flog.exe, start flinux, and then run /bin/true and busybox. Observe the logs (in the flog.exe window) and compare.