Fedora/x86_64 vs 32-bit user space
by Zoltan Boszormenyi
Hi,
I am thinking about buying an Athlon64 machine and use Fedora.
Is there a way to be able to use (and maybe compile) ia32 binaries
with this setup? I have seen only /lib64 and /usr/lib64 in
glibc-2.3.2-101.x86_64.rpm the are conflicts between glibc-*i[36]86.rpm
and glibc-*x86_64.rpm
I was thinking about dosemu and wine (games mostly) but I would like
to use the increased performance of the 64-bit mode with e.g. PostgreSQL,
etc.
--
Best regards,
Zoltán Böszörményi
---------------------
What did Hussein say about his knife?
One in Bush worth two in the hand.
20 years, 4 months
I believe symlink libart_lgpl_2.so is missing
by Jean-Francois Veillette
Hi
On my system,
>ls -l /usr/lib/libart_lgpl_2*
>symlink libart_lgpl_2.so.2 -> symlink libart_lgpl_2.so.2.3.16
>symlink libart_lgpl_2.so.2.3.16
apps like rekall won't compile because of that, making the symlink fix the
compile problem.
search buzilla with ibart_lgpl_2 found nothing about that.
Jean-Francois Veillette
_________________________________________________________________
MSN Messenger : discutez en direct avec vos amis !
http://messenger.fr.msn.ca/
20 years, 4 months
[Fwd: [Bug 23679] NTLM auth for HTTP]
by Rui Miguel Silva Seabra
Good news, mozilla >= 1.6 will probably support NTLM on all platforms.
-----Forwarded Message-----
From: bugzilla-daemon(a)mozilla.org
To: rms(a)1407.org
Subject: [Bug 23679] NTLM auth for HTTP
Date: Mon, 17 Nov 2003 19:13:56 -0800
http://bugzilla.mozilla.org/show_bug.cgi?id=23679
darin(a)meer.net changed:
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn| |224653
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
------- Additional Comments From darin(a)meer.net 2003-11-17 19:12 -------
this bug is fixed. see bug 224653 for details. here's a quick summary:
o starting with mozilla 1.6 beta, it should be possible to connect using NTLM
authentication on all platforms. note: NTLM is currently only supported
for HTTP or HTTPS.
o it is not supported when FIPS mode is enabled (because it uses MD4).
o the SSPI based WIN32 implementation has been dropped in favor of the new
cross-platform implementation. we had too many bugs with SSPI crashing on
older machines. if possible, i'd therefore like to avoid SSPI altogether.
however, i'm willing to entertain the possibility of adding it back under
certain conditions if it proves valuable.
o the new implementation attempts to negotiate the preferred NTLM2 session
key mode whenever the server supports it. this improves security.
o as with the previous SSPI based implementation, mozilla does not
automatically send username, password, and domain (based on the user's
WINNT logon) since we feel that that is a security risk. in a future
version we may eliminate this restriction for proxy authentication.
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
20 years, 4 months
Bug Day 6: Doin' the Configure Tool Cha-Cha
by Jef Spaleta
Nov. 19, 2003 Bug Day Topic:
Bug squashing for the redhat-config-* packages
That's right...tomorrow is another bug day!!!!! But this time its
official, bug days now get a passing mention at:
http://fedora.redhat.com/participate/
Little birdies have told me, that certain people are agitating for a
chance to get their hands dirty working with some of the config tools.
So why not start by first trying to get a handle on all the open bugs
that are sitting in bugzilla right now and close as many as possible.
And if your lucky...there might even be a bug that you can dig into and
submit a patch for. And, hopefully people will be standing by in
#fedora-bugs on the Freenode.net irc network to help you if you have any
questions on how to master bugzilla diving.
Here's a pre-built query showing all the open bugs for the
redhat-config-* tools:
http://tinyurl.com/vmh2
A Note. Please try to use the formatted triage->reason syntax
when annotating bug reports ( http://www.fedora.us/wiki/TriageComment ).
Example if you find an old unresolved bug report that is clearly fixed
in the current release, please add the comment "triage->currentrelease"
If you are unsure which reason is most appropriate, stop into
#fedora-bug irc channel and ask for assistance.
A second note. Just as a reminder, it might be good to glance over the
wiki for the Fedora Triage effort:
http://www.fedora.us/wiki/FedoraTriage
In other news.....
Fedora.us is still in great need for community members to do QA.
There are 280+ packages waiting for QA ( http://www.fedora.us/QA ).
Please read http://www.fedora.us/wiki/PackageSubmissionQAPolicy
and get involved in the community QA process on the community submitted
packages. So please take a look over the list of packs in the QA list,
and see if there are packages there you want to see published..pick
one..and pitch in to the QA process for the package you love.
In other, other news....
Paul Nasrat is working on hacking up some example code
to interface with the xmlrpc interface to bugzilla. I'll let him
fill you in on the details when he's ready to show off his mad skills.
But i mention it here because, I hope his experimental tools are
something that can become the basis for ease-of-use tools to work with
bugzilla to do triage and fedora.us(or extras/alternatives) package
submit/QA down the road. Since tomorrow(err i mean today) is config
tool bughunt day...i thought it appropriately ironic to mention that I'm
hoping for a config tool just to help do bughunting.
-jef"it just wouldn't be right...if a can of whoopass cola..tasted
good"spaleta
20 years, 4 months
Re: [Gcl-devel] exec-shield mmap & brk randomization
by Roland McGrath
> Bingo. In fact, we use exactly emacs' unexec. I'm hoping your past
> tense of the verb to break here indicates that a fix for unexec is
> already at hand?
Not exactly. I do plan to resolve the situation in the Fedora Core 2
development cycle, but exactly how is not yet clear. I'd like to
understand GCL's constraints as well as Emacs's before deciding what to do.
> Thankfully, GCL does not have to know precisely where its heap lower
> bound is (apart from unexec) until the first call to sbrk(0) is made,
> but we do absolutely need contiguity of this heap. As long as you
> don't dump brk altogether, I may retain my head of hair. :-).
Do you make many repeated sbrk calls to expand the heap? If you make just
one big allocation and don't really care what the base address is, then
mmap is just as good for you. However, it sounds like you want to choose
the actual address range at compile time. Is that so?
> Only in unexec. If emacs has a fix, we can use it directly.
But, in the binary produced by unexec, do you rely on the _end/end and
_edata/edata symbols beind adjusted to included brk data allocated by the
loadup run before the unexec? (I haven't yet checked whether Emacs does.)
That is, if what unexec did were to just restore some particular memory
allocated in the first run, disjoint from the original data segment, would
that make you happy?
> I'm not really sure how much memory could be wasted, but this likely
> seems a very small consideration compared to the complexity of
> redesigning the garbage collector, etc.
Sure. Contiguity is inherently limited in the ways I mentioned, but there
are plenty of reasons to like it if those limitations aren't your primary
concern. If you like contiguity, you just need to find the best ways to
ask up front for all the contiguity you really need.
> 2) come up with a configure time absolute lower bound to the first
> sbrk after exec
That is not something you ought to try to rely on in the current situation.
It is in fact a known range at the moment, but if the brk randomization
feature remains, you can't be sure the range will remain the same, or that
a compile-time determination would apply correctly to running on slightly
different kernels or different hardware configurations.
> Else we must
>
> 3) use setarch
This is certainly the right stop-gap solution if you are concerned about
people building GCL on FC1 tomorrow. It's trivial to implement in the src
rpm spec, and probably not worth putting in configure now since it likely
won't be required for very long.
Thanks,
Roland
20 years, 4 months
Re: exec-shield mmap & brk randomization
by Roland McGrath
> Ummm, I've read this 3 times and I understand that lisp (in fact every
> lisp I've ever worked on) will break in this model. Lisp systems depend
> on managing memory.
You are overreacting. You have quite a lot of control over your address
space. It's just that "presume it will be like it usually has been" does
not constitute control. You have to use the proper explicit mechanisms.
> If I understand what you wrote it appears that in the worst case I
> could get back a page at a time which could not be remapped into a
> contiguous area! Please tell me that I'm wrong.
I don't really know what you are referring to. Unless you have already
loaded zillions of libraries or other randomized mmaps, most of your
address space will be free. If you want a 1GB chunk, mmap a 1GB chunk
first thing. You know that the address space is 3GB or more and you've
decided that 1GB is enough because it makes it easier to only handle one
contiguous and that's the size you can reasonably expect, then fine.
If you want to be absolutely sure of a certain minimum size before any
shared libraries are loaded, then you need to have a PT_LOAD program header
in your executable requesting a specific mapping. This is equivalent to
allocating a huge data area in the executable, but you can do it without
making the region accessible before your explicit mappings, and without
consuming any real RAM or disk for it. I explained this already.
> Do you have a set of examples from the design to show me what expectations
> will be violated? I read your text but it would be helpful to see actual
> code that used to work and will no longer be guaranteed to work. Is there
> a design document I can read to understand this better?
There is a POSIX specification of what has been guaranteed and what has
always unspecified implementation detail you should never have been relying
on. You have never been able to presume the layout mmap will use, or how
close to the break it might be. However, you can reasonably expect that
any implementation of decent quality would endeavor make it possible to get
contiguous mappings of both small and large sizes. The locations of small
mappings such as those for the shared libraries are not predictable, but
they do not create ludicrous amounts of fragmentation.
20 years, 4 months
rekall
by d_bradsh@bellsouth.net
Hi folks, most of you dont know me because I am new here. I learned via /. that Rekall has been gpl'd and was wanting to start a discussion on whether it would be useful to incorporate it into fedora, or at least make it available via Yum. I have not tried it yet, and really dont know if I have much need for a database manager..but feel a lot of businesses and organizations might. Of course we already have most of what we need, but Rekall is getting good buzz and that is important. Well thank you all for your time.
http://thekompany.com/products/rekall/
20 years, 4 months
exec-shield mmap & brk randomization
by Roland McGrath
I kind of suspected that GCL's trouble might relate to brk randomization.
I avoided getting into these details in my first long message because I
wanted to post that write-up about the executability issues for general
reference, and not make it any more complicated than it already was.
> > System-wide, you can disable the exec-shield functionality with:
> >
> > echo 0 > /proc/sys/kernel/exec-shield
>
> Does this only effect PROT_EXEC settings on memory pages?
Nope. This disables the "exec-shield mode" for all new execs (for those
reading kernel sources at home, PF_RELOCEXEC in task_struct.flags). Using
"setarch i386 foobar" disables the mode for the run of foobar and its
children; otherwise ELF execs have the mode enabled or disabled according
to the presence or absence of PT_GNU_STACK program headers as I've already
described in detail. That mode enforces nonexecutability as I described
previously. It also enables some other layout changes. I'll describe them
after answering your other various questions about how to be sure what's what.
> This at least could function as a work-around for now, if we can make
> configure figure out when it is needed (cat
> /proc/sys/kernel/exec-shield && [ -x setarch ] ?) If this is the
> wisest solution, let me know and I'll protect the image creations with
> this command.
I would just check for setarch. You don't really need to check for
/proc/sys/kernel/exec-shield existing, though I suppose it doesn't hurt
since you shouldn't need to use setarch when exec-shield isn't there.
> To my knowledge, we have no nested functions, nor rely on an
> executable C stack.
The failures are pretty obvious when that's the nature of the problem.
i.e., you will get a SIGSEGV with the PC value set to some address,
and you can look in /proc/PID/maps and see the region containing the PC is
not executable, and voila, you're sure that's the problem (or isn't).
> Are these utils in any (unstable) Debian packages?
The `execstack' program is only available as part of the prelink package by
Jakub Jelinek, in very recent versions of that package. Off hand I don't
know what version of prelink, if any, is in Debian. readelf and objdump
are part of binutils, and versions too old to know the PT_GNU_STACK magic
number just show you the number instead of the name (match up with <elf.h>
values), so you can still see what's going on.
> So even with nested functions, code should compile and run from
> source, right?
With current tools on FC1, yes. You should always be able to tell by
examining the binaries with readelf/objdump/execstack how the tools marked
(or didn't mark) the binary.
> We don't use any asm.
In that case you can be pretty sure that executable stack per se is not the
problem unless you are using GCC nested functions and we have some tools bugs.
> We get all pages via sbrk, and redefine malloc to a call to a native
> memory management system which in turn calls sbrk as needed.
This is probably where your problem lies. See below.
I mentioned layout changes enabled by the exec-shield mode. The first of
these is randomization of the addresses returned by mmap when not using the
MAP_FIXED flag bit and supplying 0 as the first argument rather than a
specific hint address. It has always been the case that mmap is specified
to return unpredictable addresses when not given MAP_FIXED, and the
application cannot presume any particular choices will be made (the address
given in the first argument to mmap is a nonbinding suggestion). In the
past, Linux kernels have always returned a very predictable sequence of
addresses. In Fedora Core kernels, for processes in exec-shield mode, mmap
returns truly unpredictable addresses. This affects programs that presume
what addresses their mmap calls will return, and those that presume what
addressses no mmap call will ever return. Note that this includes the mmap
calls made by the dynamic linker to load shared libraries before any
library or application code gets control, and potentially even the kernel's
mapping of the dynamic linker itself done at exec. So if you had your eye
on some particular part of the address space not directly mapped by your
executable, it might already be in use by the time you get a chance to look.
Incidentally, the mmap randomization is what broke MIT Scheme. It presumed
that the low 64MB of the address space would never be used at all, and did
mmap with MAP_FIXED on addresses in that range that would overwrite other
mappings such as those for the shared library containing the mmap function
itself. That's a case of presuming what addresses "anywhere" mmap calls
would rule out, when no such guarantee was ever part of the specification
of the system interface. MIT Scheme really wants that particular part of
the address space for its data due to its pointer tagging implementation
(high tags). The mmaps for shared libraries done before the Scheme runtime
gets control are now randomized and might very well impinge on the
[0,0x4000000) range. The only proper way to reserve such a range is with a
PT_LOAD program header in the ELF executable, which can request a PROT_NONE
mapping to reserve the range (without consuming any disk or RAM) so that it
has carte blanche to overwrite that range with MAP_FIXED mappings later.
Unfortunately, getting that into your binary is a bit of a pain in the ass
futzing with linker scripts and bits of magic dust. I posted some quick
examples that demonstrated it adequately for the MIT Scheme maintainer, but
that maintainer is rather more experienced than the average bear. If you
need to make this happen, I'll be happy to help you figure out the magic.
The second layout change is what I suspect broke GCL. It broke Emacs's
unexec as well. Personally, I consider this change incorrect. However, we
have not yet hashed out among the RH developers concerned with this area
what the resolution will be. Moreover, I tend to think that anything
broken by it probably ought to be doing things differently in the long run.
Since the dawn of time, the "break area" in Unix has started immediately
after the executable's writable segment (i.e. after its .bss section) and
extended upward from there. By "the break area", I mean the region of
memory starting at the address returned by sbrk the first time it's called
after an exec. From the beginning of Unix until two weeks ago Wednesday,
the first `sbrk (0)' returned &end, the end of your .bss; increasing the
break with sbrk calls gave a contiguous region from your data segment
through to the current address of the dynamically-extended break. In
Fedora Core kernels, for processes in exec-shield mode, this is no longer
the case. The starting address of the break area is randomized at exec
time, in a fashion similar to the randomization of mmap addresses. The
first call to `sbrk (0)' will tell you the lower bound of the region, which
will not be lined up with the end of your executable's writable segment.
As always, calls to sbrk to increase the size of the region will work as
long as there is unused address space above the current break region
(randomly placed mmaps will tend to be elsewhere, lower in the address
space, and not impinge on break expansion). But the exact location of the
region is now somewhat unpredictable, and you can always expect a hole
between static data (your program's writable segment, i.e. .data+.bss) and
the dynamically-extended break region.
As I said, I personally don't like this change. That's because I consider
starting at &end to have been part of the specification of the break
functionality inherited from ancient Unix, and breaking such things is just
plain wrong. Nonetheless it is at least for the moment the way things are
in FC1 kernels. I don't want to engage in a discussion here about the
merits of this change. I would like to help hash out how precisely it
affects you and any possible ways to work around it there might be. (If
figuring it all out turns out to lead you not to want to change anything
and instead to complain heartily about the kernel behavior change, then
that's as may be.)
I said that anything broken by it probably ought to be doing things
differently. The reason I say that is that I consider the brk interface
obsolete. I can't really see any good reason to be using it in preference
to the other options. It's inherently limited as an allocation interface
in that it provides just one contiguous region; address space fragmentation
from the mappings for the executable, shared libraries, thread stacks, etc,
will mean that many smaller discontiguous holes are available, and using
only the break region will mean the total limit on useful allocation in the
process can be much lower than the true limit imposed by the configured
resource limits, the system implementation, or available virtual memory
resources. The other option to use mmap and be prepared to get
discontiguous regions when requesting pages on separate occasions. If
contiguity is required, you can use the mremap call when available (AFAIK
only on Linux kernels) to extend a region and move it if a sufficient
contiguous region is not free in the original location. If contiguity is
only somewhat preferred but not strongly so, you can use a nonzero first
argument to mmap (without using the MAP_FIXED flag), and you will
ordinarily get the requested address or the next following address with a
free region of the requested size. (But note that there is still no
guarantee of getting the requested region without MAP_FIXED and the robust
program must be prepared to handle discontiguous regions. FC1 kernels will
in fact hand back predictable addresses, but future kernels might not
always do so.)
If you specifically rely on treating static data and the dynamic break
region as a single contiguous region, something has to change. If you
don't rely on that, but just on knowing the start and end of the contiguous
break region itself, then you can make the simple and portable change of
using sbrk (0) instead of &end to initialize your idea of the lower bound
of the break region. In the long run, I would still recommend more drastic
changes to avoid relying on a contiguous break region at all, for the
reasons I gave in the previous paragraph. If you make those changes, you
will not impose so low a limit on the total memory you can allocate in a
process, a benefit you'll get in the same way on all modern Unix-like
systems (at least the 32-bit ones, I guess 64-bit systems always have more
unused address space after the break than you could possibly need).
Please let me know if there is anything I clarify or anything I can do to
help you figure out what changes to your program might be best.
Thanks,
Roland
20 years, 4 months
Re: gFTP 2.0.14
by Gene C.
On Tuesday 18 November 2003 14:19, Phillip Compton wrote:
> On Tue, 2003-11-18 at 01:01, Jonathan C. Sitte wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Seems odd to me but gFTP 2.0.14 is crashing on me allot. Anyone else
> > have this problem? Also when I use to upload images some of them do not
> > upload entirely. Just wondering if it is just me. :)
>
> Have you tried 2.0.16
>
> https://bugzilla.fedora.us/show_bug.cgi?id=677
>
> 2.0.14 and 2.0.15 seemed to crash a fair amount on me, bu 2.0.16 has
> been rock solid.
I agree about gftp-2.0.16 being rock solid. In addition, it fixes handling of
http so that it actually works correctly.
However, I do not understand the posting of a gftp update to fedora.us. This
package is part of Fedora Core 1. Shouldn't this update be part of the
updates flowing out of the Red Hat errata process? While Red Hat updates do
not always come out to "my" schedule (I want it "now" ;), how are users to
differentiate between those available through
http://download.fedora.redhat.com and those from http://download.fedora.us ?
This duplication does not make sense to me. While making updated packages
available through some "private" repository or server is OK with me, making
them available through http://download.fedora.us is confusing since it
carries some "official" status.
I really do not like cross-posting but will CC the devel list on this since I
believe it is an important issue and is more likely to be addressed there
(with the lower email volume).
I really empathize with the problem of needing an updated package and not
being sure just when it will come from Red Hat since their limited resources
are covering lots of areas and sometimes cannot address things like gftp as
soon as some of us would like (yes, I had already built 2.0.16 packages for
myself).
Perhaps there is some middle ground where user (non Red Hat) updated packages
of packages in the Core can be placed and it would be clear that these were
user updates. It was/is my understanding that fedora.us focuses on "Extras"
and "Legacy" rather than quick updates of packages in Fedora Core.
I would really like to hear from some Red Hat folks on this. I would like to
see some means of folks outside of Red Hat providing updated packages where
Red at currently does not have to resources available to do them "right now".
After all, the whole idea of the Fedora Project is to leverage (utilize)
resources outside of Red Hat to deliver a better product that could be done
using only Red Hat resources.
Some of this may "shake out" over the next few months as the whole Fedora
process develops.
--
Gene
20 years, 4 months