On Fri, February 10, 2012 02:15, H. Peter Anvin wrote: > On 02/09/2012 05:09 PM, Indan Zupancic wrote: >> On Thu, February 9, 2012 17:00, H.J. Lu wrote: >>> GDB uses CS value to tell ia32 process from x86-64 process. >> >> Are there any cases when this doesn't work? Someone said Xen can >> have different CS values, but looking at the source it seems it's >> using the same ones, at least with a Linux hypervisor. So perhaps >> it was KVM. Looking at the header it seems paravirtualisation uses >> different cs values. On the upside, it seems we can just use that >> user_64bit_mode() to know whether it is 32 or 64 bit mode, so >> adding a bit telling the process mode is easier than I thought. >> >> Currently there is a need to tell if the 32 or 64-bit syscall >> path is being taken, which is independent of the process mode. >> > > There are definitely cases where the current reliance on magic CS values > doesn't work; never mind the fact that it's just broken. It's only broken because it doesn't work sometimes. ;-) >>> At minimum, we need a bit in CS for GDB. But any changes >>> will break old GDB. >> >> Would adding bits to the upper 32-bit of rflags break GDB? > > It doesn't work for i386, never mind that this is reserved hardware > state and we don't have an OK at this time to redeclare them available. It doesn't need to work for i386 because it's close to practically impossible to ptrace a 64-bit task with a 32-bit ptracer. An alternative would be to use some of the bits in the lower half. E.g. bits 1, 3, 5 and 15 are reserved and very unlikely to be ever used for anything, because they can use plenty of bits at the top. Problem would be that we can't be sure that they are always zero. If they are, they're safe to use. The VIF and VIP flags can also be stolen as they're always zero outside of vm86 mode (which can't be ptraced AFAIK). So we could set VIF or VIP to tell if we stole bits 1, 3, 5 and/or 15. That would give us 6 bits in total, and the only confusing thing might be VIF or VIP set for user space. But anyone counting on those being zero seems unlikely, and even more unlikely for the reserved bits, as they are intermixed with unpredictable bits. We could use VM too, but that might be too confusing, while VIF or VIP without VM set make no sense. Perhaps using VIF or VIP to tell whether the other bits are valid is a good idea anyway, as it can never clash because they are well defined already and always zero for non-VM mode. With the current rate of adding flags it will take forever before any of this might break. And if that happens, we just move to other bits and user space needs to check those first. Or if the flags aren't useful for userspace, hide them and keep using it for the kernel. >> Do you also need a way to know whether the kernel was entered via >> int 0x80, SYSCALL32/64 or SYSENTER? > > gdb, probably not. That came from another user (pin, I think, but I'm > not sure.) Could you find out? Because I have a hard time thinking of any good reason why anyone would want to know this specifically. If this info is added it can replace the bit saying if it's 32 or 64-bit syscall path. So one bit for enabling all this, 2 bits for the syscall entry instruction (with SYSCALL64 being 0 as an easy check for the 64-bit path) and one bit for user space mode. This would end up being 4 bits in total, except if I forgot anything. Only downside of adding the entry instruction info would be that more work in the entry-specific code is needed. The code wouldn't be contained to a small ptrace specific bit anymore. Greetings, Indan -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
