Re: arch/x86/kernel/vsyscall_64.c: overeager NOP of syscalls
Andi Kleen <[EMAIL PROTECTED]> writes: > On Wed, Feb 20, 2008 at 02:57:34PM +0100, Arne Georg Gleditsch wrote: >> Hi, >> >> I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP >> out the actual system call instructions of the vsyscall page when >> vsyscall64 is enabled. This seems to interact badly with the fallback >> code in do_vgettimeofday which tries to call gettimeofday if the >> configured clock source does not support vread. (In effect, >> gettimeofday() becomes a nop and time() always returns 0. Not very >> useful.) >> >> Is there a good reason to keep this? Aren't the instructions in >> question avoided (or invoked) according to the vsyscall64 flag by the >> surrounding logic anyway? > > Yes they are. But a system call sequence at a known fixed address > is potentially useful to exploits. That is why it is nop'ed out when > it is not needed. Reasonable enough, as long as it can be determined to be not needed. Still, isn't the __vsyscall_gtod_data structure part of the same page? Wouldn't that give you access to any 2-byte opcode you want every 64k seconds? You'd need to time your attack, of course, but that could be done prior to actually launching the exploit... -- Arne. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/x86/kernel/vsyscall_64.c: overeager NOP of syscalls
Andi Kleen [EMAIL PROTECTED] writes: On Wed, Feb 20, 2008 at 02:57:34PM +0100, Arne Georg Gleditsch wrote: Hi, I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP out the actual system call instructions of the vsyscall page when vsyscall64 is enabled. This seems to interact badly with the fallback code in do_vgettimeofday which tries to call gettimeofday if the configured clock source does not support vread. (In effect, gettimeofday() becomes a nop and time() always returns 0. Not very useful.) Is there a good reason to keep this? Aren't the instructions in question avoided (or invoked) according to the vsyscall64 flag by the surrounding logic anyway? Yes they are. But a system call sequence at a known fixed address is potentially useful to exploits. That is why it is nop'ed out when it is not needed. Reasonable enough, as long as it can be determined to be not needed. Still, isn't the __vsyscall_gtod_data structure part of the same page? Wouldn't that give you access to any 2-byte opcode you want every 64k seconds? You'd need to time your attack, of course, but that could be done prior to actually launching the exploit... -- Arne. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
arch/x86/kernel/vsyscall_64.c: overeager NOP of syscalls
Hi, I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP out the actual system call instructions of the vsyscall page when vsyscall64 is enabled. This seems to interact badly with the fallback code in do_vgettimeofday which tries to call gettimeofday if the configured clock source does not support vread. (In effect, gettimeofday() becomes a nop and time() always returns 0. Not very useful.) Is there a good reason to keep this? Aren't the instructions in question avoided (or invoked) according to the vsyscall64 flag by the surrounding logic anyway? -- Arne. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
arch/x86/kernel/vsyscall_64.c: overeager NOP of syscalls
Hi, I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP out the actual system call instructions of the vsyscall page when vsyscall64 is enabled. This seems to interact badly with the fallback code in do_vgettimeofday which tries to call gettimeofday if the configured clock source does not support vread. (In effect, gettimeofday() becomes a nop and time() always returns 0. Not very useful.) Is there a good reason to keep this? Aren't the instructions in question avoided (or invoked) according to the vsyscall64 flag by the surrounding logic anyway? -- Arne. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Documentation about unaligned memory access
dean gaudet <[EMAIL PROTECTED]> writes: > on AMD x86 pre-family 10h the boundary is 8 bytes, and on fam 10h it's 16 > bytes. the penalty is a mere 3 cycles if an access crosses the specified > boundary. Worth noting though, is that atomic accesses that cross cache lines on an Opteron system is going to lock down the Hypertransport fabric for you during the operation -- which is obviously not so nice. -- Arne. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Documentation about unaligned memory access
dean gaudet [EMAIL PROTECTED] writes: on AMD x86 pre-family 10h the boundary is 8 bytes, and on fam 10h it's 16 bytes. the penalty is a mere 3 cycles if an access crosses the specified boundary. Worth noting though, is that atomic accesses that cross cache lines on an Opteron system is going to lock down the Hypertransport fabric for you during the operation -- which is obviously not so nice. -- Arne. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Opteron box and 4Gb memory
"J.A. Magallón" <[EMAIL PROTECTED]> writes: > Software Memory Hole > When "Enabled", allows software memory remapping around the memory > hole. Options are Enabled and Disabled. > > Hardware Memory Hole > When "Enabled", allows software memory remapping around the memory > hole. Options are Enabled and Disabled. Note: this is only supported by > Rev E0 processors and above. > ( I have two Opteron 275 processors, no idea about revision) The configuration register used to to reclaim DRAM lost to an MMIO hole was introduced with revision E of the gen1 Opterons. (This feature is supposed to work both in interleaved and non-interleaved mode.) What does /proc/cpuinfo say? (On both?) (Still, even without this your BIOS should be able to map your memory so that you are able to use all 4G. Provided you disable interleaving, I can't see that there's anything stopping the BIOS from mapping the memory from node 1 to 0-2G and the memory from node 2 to 4-6G, leaving a 2G hole for MMIO and other junk. Whether your BIOS actually supports this is another matter.) -- Arne. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Opteron box and 4Gb memory
J.A. Magallón [EMAIL PROTECTED] writes: Software Memory Hole When Enabled, allows software memory remapping around the memory hole. Options are Enabled and Disabled. Hardware Memory Hole When Enabled, allows software memory remapping around the memory hole. Options are Enabled and Disabled. Note: this is only supported by Rev E0 processors and above. ( I have two Opteron 275 processors, no idea about revision) The configuration register used to to reclaim DRAM lost to an MMIO hole was introduced with revision E of the gen1 Opterons. (This feature is supposed to work both in interleaved and non-interleaved mode.) What does /proc/cpuinfo say? (On both?) (Still, even without this your BIOS should be able to map your memory so that you are able to use all 4G. Provided you disable interleaving, I can't see that there's anything stopping the BIOS from mapping the memory from node 1 to 0-2G and the memory from node 2 to 4-6G, leaving a 2G hole for MMIO and other junk. Whether your BIOS actually supports this is another matter.) -- Arne. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC+PATCH] RTC calibration
Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: > + case RTC_SPEED_UP: > + err = rtc_speed_up(rtc); > + break; > + > + case RTC_SLOW_DOWN: > + err = rtc_speed_up(rtc); > + break; This doesn't look quite right. rtc_slow_down, surely? -- Arne. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC+PATCH] RTC calibration
Dag-Erling Smørgrav [EMAIL PROTECTED] writes: + case RTC_SPEED_UP: + err = rtc_speed_up(rtc); + break; + + case RTC_SLOW_DOWN: + err = rtc_speed_up(rtc); + break; This doesn't look quite right. rtc_slow_down, surely? -- Arne. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona
"Yinghai Lu" <[EMAIL PROTECTED]> writes: > mmconfig is set in NB ( in new CPU), Do we still need to set mmconfig > in SB like mcp55? I wasn't aware that the family 10h-chips had MSRs for setting the mmconfig address space directly in the NB (core?). Please disregard my previous comment... -- Arne. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona
"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > You're missing the point. How will the PCI bus transactions be > different when using MMCONFIG versus your extended CF8 version? Conceivably this is useful if the IO hub does not support MMCONFIG accesses. The AMD 8111 does not, as far as I can see. At least I have an Opteron system where MMCONFIG is not supported, and I assume it's because the 8111 doesn't provide it. I don't know if this is going to be a realistic scenario for Barcelona systems. -- Arne. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona
H. Peter Anvin [EMAIL PROTECTED] writes: You're missing the point. How will the PCI bus transactions be different when using MMCONFIG versus your extended CF8 version? Conceivably this is useful if the IO hub does not support MMCONFIG accesses. The AMD 8111 does not, as far as I can see. At least I have an Opteron system where MMCONFIG is not supported, and I assume it's because the 8111 doesn't provide it. I don't know if this is going to be a realistic scenario for Barcelona systems. -- Arne. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5 june 30th to july 1st date hang?
Florian Attenberger <[EMAIL PROTECTED]> writes: > yep, controlled by ntpd. > You're right according to > ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.33 > that event shouldn't have been there. I'm not all that versed in ntp-ish, but it appears that the leap second insertion should be propagated through the ntp protocol. Whether the leap second in question came from a ntp server giving out wrong data or from a misinterpretation or bug in ntpd is of course hard to say, but either way turning the clock back is unlikely to reconstruct the circumstances. An interesting exercise might be to code up a small program to call adjtimex with timex.status |= STA_INS, to see if this can trigger the problem. (The bogus leap second might be a red herring entirely, of course...) -- Arne. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5 june 30th to july 1st date hang?
Florian Attenberger <[EMAIL PROTECTED]> writes: > there was one 'special' event at that date: > syslog.2.gz:Jul 1 01:59:59 master kernel: Clock: inserting leap second > 23:59:60 UTC As far as I can tell, no leap second was due to be inserted at 1. of July this year. Is the year set correctly for this box? -- Arne. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5 june 30th to july 1st date hang?
Florian Attenberger [EMAIL PROTECTED] writes: there was one 'special' event at that date: syslog.2.gz:Jul 1 01:59:59 master kernel: Clock: inserting leap second 23:59:60 UTC As far as I can tell, no leap second was due to be inserted at 1. of July this year. Is the year set correctly for this box? -- Arne. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.5 june 30th to july 1st date hang?
Florian Attenberger [EMAIL PROTECTED] writes: yep, controlled by ntpd. You're right according to ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.33 that event shouldn't have been there. I'm not all that versed in ntp-ish, but it appears that the leap second insertion should be propagated through the ntp protocol. Whether the leap second in question came from a ntp server giving out wrong data or from a misinterpretation or bug in ntpd is of course hard to say, but either way turning the clock back is unlikely to reconstruct the circumstances. An interesting exercise might be to code up a small program to call adjtimex with timex.status |= STA_INS, to see if this can trigger the problem. (The bogus leap second might be a red herring entirely, of course...) -- Arne. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info
Randy Dunlap <[EMAIL PROTECTED]> writes:
> On Tue, 26 Jun 2007 19:25:00 +0200 Julio M. Merino Vidal wrote:
>> The correct expression could be $((${a} + 2)). Tested under NetBSD's
>> sh, which is very POSIX-compliant.
>
> Thanks. Does anyone see other changes that are needed?
[..]
> and the complete script is:
Both busybox sh and dash are happy with this. (Or rather, busybox
would be if its mktemp hadn't been broken.)
--
Arne.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info
Randy Dunlap [EMAIL PROTECTED] writes:
On Tue, 26 Jun 2007 19:25:00 +0200 Julio M. Merino Vidal wrote:
The correct expression could be $((${a} + 2)). Tested under NetBSD's
sh, which is very POSIX-compliant.
Thanks. Does anyone see other changes that are needed?
[..]
and the complete script is:
Both busybox sh and dash are happy with this. (Or rather, busybox
would be if its mktemp hadn't been broken.)
--
Arne.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info
Randy Dunlap <[EMAIL PROTECTED]> writes: > OTOH, you also didn't supply a patch. If you do this, I'll be > glad to consider it. If I can read it, that is. I like bash as much as the next guy, but (to my surprise) /bin/sh on my current workstation is actually dash. How about just replacing the substring-interpolations with: if [ $marker -ne 0 ]; then beforemark=`echo "$code" | cut -c-$((marker - 1))` [..] # and fix code at-and-after marker code=`echo "$code" | cut -c$marker-` fi and be done with it? -- Arne. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info
Randy Dunlap [EMAIL PROTECTED] writes: OTOH, you also didn't supply a patch. If you do this, I'll be glad to consider it. If I can read it, that is. I like bash as much as the next guy, but (to my surprise) /bin/sh on my current workstation is actually dash. How about just replacing the substring-interpolations with: if [ $marker -ne 0 ]; then beforemark=`echo $code | cut -c-$((marker - 1))` [..] # and fix code at-and-after marker code=`echo $code | cut -c$marker-` fi and be done with it? -- Arne. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] - LXR on kernel.org ? was: Re: What tools to use?
[EMAIL PROTECTED] writes: > I like lxr pretty much. i`m not a programmer, but i often need some > information on "what`s the driver version of xyz in latest kernel" or > "was this or that feature/patch already being merged" or "i have this > line of code in kernel - how does it look in recent kernel , did it > change " ? > > over the years, i have downloaded tons of kernels for this, very much > waste of bandwidth and time - because whenever i need to take a look, > i have no recent kernel source around - so i need to download that big > thing and go trough that untar orgy. having recent > browsable/searchable and easy to find lxr`ed kernel-source online > would be really great > > i seldom find lxr for current kernels on the net, so i just wonder: > [..] I maintain the original LXR site at lxr.linux.no, which unfortunately tends to lag behind quite a bit. This is partly due to lack of time to keep it current on my part, but also due to the fact that adding new kernels to the version running on lxr.linux.no is a bit more time and resource-consuming than it ought to be. Better support for both incremental indexing and git-based repos is forthcoming, and I hope the situation will improve a bit with that. I'll keep you posted. -- Arne. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] - LXR on kernel.org ? was: Re: What tools to use?
[EMAIL PROTECTED] writes: I like lxr pretty much. i`m not a programmer, but i often need some information on what`s the driver version of xyz in latest kernel or was this or that feature/patch already being merged or i have this line of code in kernel - how does it look in recent kernel , did it change ? over the years, i have downloaded tons of kernels for this, very much waste of bandwidth and time - because whenever i need to take a look, i have no recent kernel source around - so i need to download that big thing and go trough that untar orgy. having recent browsable/searchable and easy to find lxr`ed kernel-source online would be really great i seldom find lxr for current kernels on the net, so i just wonder: [..] I maintain the original LXR site at lxr.linux.no, which unfortunately tends to lag behind quite a bit. This is partly due to lack of time to keep it current on my part, but also due to the fact that adding new kernels to the version running on lxr.linux.no is a bit more time and resource-consuming than it ought to be. Better support for both incremental indexing and git-based repos is forthcoming, and I hope the situation will improve a bit with that. I'll keep you posted. -- Arne. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto: convert crypto.h to UTF-8
"John Anthony Kazos Jr." <[EMAIL PROTECTED]> writes: > Besides, based on the actual binary representation of UTF-8, it's > extremely unlikely for any ISO-8859-1 string to be detected as UTF-8. VIm > already does this: UTF-8 it handles natively, but open up one of these > unpatched files in VIm and you'll see "[converted]" at the bottom of your > screen. Should happen if you open the attached .patch.bin file in VIm. Yes, I agree that heuristics can be used to determine the coding system used with a high degree of probability. I'm just suggesting we make the coding system explicit, in order to spare other applications that do visual presentation of Linux source code having to perform their own heuristics. But hey, if I'm the only one wanting to see this particular bike shed painted blue... -- Arne. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto: convert crypto.h to UTF-8
"John Anthony Kazos Jr." <[EMAIL PROTECTED]> writes: > Did this file individually, per request. Will re-do the whole tree later > as I'm still working on my handy-dandy testing and patching tools and > don't have a lot of time outside of work until the summer gets underway. While this is probably inevitable, it would be nice if there was some way to determine the actual coding system used for individual files. Especially if we're mixing latin1 and utf8 in the same tree. Has something like adding "/* -*- coding: utf-8; -*- */" or similar to the top of converted files been considered? -- Arne. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto: convert crypto.h to UTF-8
John Anthony Kazos Jr. [EMAIL PROTECTED] writes: Did this file individually, per request. Will re-do the whole tree later as I'm still working on my handy-dandy testing and patching tools and don't have a lot of time outside of work until the summer gets underway. While this is probably inevitable, it would be nice if there was some way to determine the actual coding system used for individual files. Especially if we're mixing latin1 and utf8 in the same tree. Has something like adding /* -*- coding: utf-8; -*- */ or similar to the top of converted files been considered? -- Arne. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto: convert crypto.h to UTF-8
John Anthony Kazos Jr. [EMAIL PROTECTED] writes: Besides, based on the actual binary representation of UTF-8, it's extremely unlikely for any ISO-8859-1 string to be detected as UTF-8. VIm already does this: UTF-8 it handles natively, but open up one of these unpatched files in VIm and you'll see [converted] at the bottom of your screen. Should happen if you open the attached .patch.bin file in VIm. Yes, I agree that heuristics can be used to determine the coding system used with a high degree of probability. I'm just suggesting we make the coding system explicit, in order to spare other applications that do visual presentation of Linux source code having to perform their own heuristics. But hey, if I'm the only one wanting to see this particular bike shed painted blue... -- Arne. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
