Bug 121876
Summary: | FC2T3 install boot fails on VMware Workstation | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Phil Schaffner <philip.r.schaffner> |
Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | gczarcinski, mingo, philip.r.schaffner, vandrove |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-05-09 20:59:03 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Phil Schaffner
2004-04-28 20:29:34 UTC
This is a VMWare bug. There's not much I can do about it. No, it is your bug, and VMware can only workaround around it. You are returing with SYSEXIT to segment with limit 0xBFFFFFFF while Intel documentation explicitly states that segment limit for sysexit/sysenter must be 0xFFFFFFFF (and hardware always sets limit to 0xFFFFFFFF regardless what GDT says). This warning is there to only warn you that you wanted to load segment with limit 0xBFFFFFFF to the processor, but it is not going to happen: sysexit ALWAYS loads limit 0xFFFFFFFF. So if you wanted this to do stack no-exec patch, you MUST disable sysenter, otherwise stack is executable after first sysenter based syscall in the process occurs, until first interrupt (or taskswitch) occurs (as interrupts use iret they'll restore proper (shortened) segment limit on CS). And if you set limit on CS to 0xBFFFFFFF for some other reason than stack no-exec (and it does not matter for you that sometime that limit is 0xFFFFFFFF), then I'd like to know that reason... Looks like this may warrant reconsideration from Red Hat. A work-around that seems to work for some, not for others: On Mon, 2004-05-03 at 11:19 -1000, Warren Togami wrote: > Running FC2 Test3 and higher in VMWare is broken because VMWare needs to > implement vdso. For now you can use "vdso=0" boot option. It works for > me when running FC2 Test3 within VMWare 4.5.1 hosted on FC2 Test3 This works for me to run latest FC2/rawhide as a guest OS when the host is FC1 using the vmware-any-any-update65.tar.gz from http://platan.vc.cvut.cz/ftp/pub/vmware/ When host if FC2/rawhide with vmware-any-any-update65, and guest is FC2T3 install attempt, the host reboots during the guest installer boot. I would like to ask Petr where he gets that information, the docs I have state explicitly that sysexit must return to a segment with limits *UPTO* 4Gb (we have an open interpretation request with intel on this one) I've used http://folk.uio.no/botnen/intel/vt/reference/vc312.htm, as it is first reference Google finds when you ask for "sysexit segment limit". See also http://mail-index.netbsd.org/port-i386/2003/11/13/0004.html. And main problem is not that documentation states it, but that it works that way. Just try loading CS's MSR with 0xFFC4, and you'll find that your system still works until first interrupt (iret will not work, as iret consults descriptor tables) - and although you have no LDT, you'll find that CS contains 0xFFC4 (in case of sysenter) or 0xFFD7 (in case of sysexit), with 4GB limit, executable, non-writeable. So CS's MSR is used only as a base for visible portion of CS/SS, and invisible portion is always loaded with base=0, limit=4G-1, big, CS with readable executable code segment, and SS with writable expand-up. P4 even works if you'll load values 0xFFE8-0xFFFF to the CS's base, although then your CS or SS is NULL selector (as Dan Arai found, P3 behaves erratically in this situation, but it is not problem we are hitting here). Yes, sysexit can return to the segment with 0 base and limit *upto* 4GB... Only problem is that you'll have set limit to 4GB then, which does not matter for correct code, but it is killer for stack no-exec... you are right, the limit is set to 4GB on certain CPUs (but not on all SEP-capable x86 CPUs - e.g. the limit worked fine on my primary testbox). I've fixed the exec-shield patch and uploaded a new version. (Arjan updated the Fedora kernel.) we enabled sysenter/sysexit (via vdso=1) for Fedora only a couple of weeks ago, so this bug had minimal exposure so far. The separate exec-shield patches i have never enabled the vdso. Seems to be fixed with kernel-2.6.5-1.356 :-) Currently running FC2 rawhide install with this kernel, VMware 4.5.1/vmware-any-any-update65 on a FC2T3+updates host. Got quite a few line similar to below when install kernel-2.6.5-1.356 with rpm -ivh kernel-2.6.5-1.356.i686.rpm /etc/security/selinux/file_contexts: invalid context system_u:object_r:staff_home_spamassassin_t on line number 1856 Should I get/install mkinitrd-3.5.15.1-2.i386rpm or generate that from kernel source? Can you be more specific about how you install FC2 rawhide? Thanks. |