The problem is an IV is used to "start" the CBC chain, and this IV is static as the underlying plaintext changes. So new changes on the same point of the HD get encrypted with the same IV.
It actually makes me happy to see that some people are starting to get the point. I have been pointing out these weaknesses for years.
Some of them are actually even worse. If the IV is just the sector number, then the difference between two neighbor sectors is known, and you can construct a file that will cancel out that difference and the two sectors get the same cipher text. I constructed a file some years ago, that demonstrated the problem. At that time Truecrypt was vulnerable to this attack. Truecrypt did apply some whitening after the encryption, but that didn't really make the pattern much worse. Put the file I mentioned on a Truecrypt volume encrypted in CBC mode, and somewhere in the encrypted image there will be two neighbor sectors that can be XORed together and will cancel out all the data leaving only the whitening pattern, which is easily recognizable because it repeats over many times through the sector.
Encrypting the IV is better, but still vulnerable to the problem you describe. In fact the problem you describe applies one way or another to almost every single disk encryption in existence. All the encryptions need some nonce or randomness, and since it doesn't fit in the sector, they cut a corner and use the sector number, which doesn't change when the sector is overwritten. (I have seen one that used extra space by mapping 32 logical sectors to 33 physical sectors, but that encryption had other problems including a weak pseudo random number generator, and potential data loss caused by the need to update two sectors which isn't done atomically).
Recent Truecrypt versions are no longer vulnerable to the attack I described above. They now use tweakable block ciphers. But just like CBC needs a unique IV for each time you encrypt, tweakable block ciphers need a unique tweak. Truecrypt use the sector number for tweak, so if a sector is overwritten, you have the same problem again. In fact it is even worse because there is no longer any chaining, just a tweak for each 16 byte block, which means changing a byte in a sector would keep changes in the cipher text within the 16 byte block. I didn't verify this in practice, I just read the specification. I mentioned this problem to the authors a long time ago, but they didn't consider it a problem.
By using a counter, it provides random access, stops this class of attacks, and is easy to implement.
Counter mode is one of the least secure ways to encrypt a disk. Counter mode generates a pseudo random one time pad, which in itself is secure if the pseudo random number generator is secure. However when used for disk encryption, the one time pad is reused whenever you overwrite a sector. Reusing a one time pad is not secure.
what I do is get the OOM killer to take action and kill some processes sooner.
Just killing processes more or less at random when the system runs low on memory is not a good idea. (I know it is not completely random, but there surely ain't any guarantee that it will make sane decisions). What you really want is for programs to get an out of memory error when trying to allocate memory, and then they can shut down as gracefully as possible. (Would be neat if the choice of who get the first ENOMEM was chosen by the heuristics that would otherwise kill the process, but I guess that has not been implemented). Guaranteeing that you will never need to kill a process because you are out of memory means the kernel will have to not commit to more than can be backed by memory and swap. However since actual usage tends to be somewhat lower than what is actually committed to, that would be a bit wasteful. This is the main reason why it makes sense to have a large swap partition that is mostly unused. Just so you have backing for the amount you need to commit to in order to optimally use the physically available memory.
You typically wouldn't want to make use of most of that swap. So once any significant amount start getting used, you'd want to start giving ENOMEM errors. And that should help ensuring that the swap will only be used for a short time. There are a few pieces of data in virtual memory that are only used under very rare circumstances, and those it is nice to have on swap so they don't take up precious memory. So the aim is not to have zero swap in use, just some low number of pages that are really not needed in memory.
Is there any kernel out there that gets all of this right? I don't know. But at least those I know about can be tweaked to do pretty well.
I have an Eee 901. It has 1GiB of RAM and 20GB of disk space.
I suppose that is not really a disk but rather flash storage. Swapping to flash is not the best idea as it could cause the flash to last shorter than it should. So I'd say this is probably one of those cases where no swap is the correct configuration.
1) 10.X.X.X for internal usage,
2) 192.168.X.X for internal usage
3) 172.18.X.X for internal usage
There are a few more than that. But that's not a huge deal. There are actually corporations that need that many internal IPs. Of course the correct way would be for a corporation to use part of the IPs that they got allocated, and then just announce the subset they want to be worldwide routable and filter the rest. Using the same internal addresses in multiple corporations is bad because sometimes corporations have partnerships that does involve communication between their networks. If they were already using the same addresses internally, that would be causing trouble. But only corporations that were on the Internet early enough to get a/8 can do things the right way. All others are forced to do things not entirely right. If we revoke those ranges to do things right, we would be out of addresses before we could even release the ranges.
Most, if not all businesses can get away with using the 192.168 or the 172.18 ranges(Exceptions would be google, governments, and research places with over 65k machines)
I think it is safe to assume that there are at least two corporations with such needs. So we can revoke 10/8 and give it to the first and allocate a new/8 and give it to the next. Then we will already have less IPs available than we have now.
6) Everything 1.X.X.X - 10.X.X.X is reserved for IANA.
No, most of those are reserved for corporations that were out early enough to get enough IP addresses. And that was at a time where the four octets in the address were actually supposed to indicate structure of the network to make routing simple.
I think there are 16 multicast (224-239) and 15 reserved (240-254) and the last one reserved for some purpose (255). But if you are going to hand out those, you are probably going to find that loads of systems are filtering them out. Just look at what happened when people started setting the ECN bits. Just something as simple as ignoring a bit was implemented incorrectly by a lot of systems. If you are going to have packets show up from new and unexpected IP ranges, you are going to see at least as many systems just drop your packets. If anybody really want to open op the reserved ranges at this time, I think they should be opened up for the use in products intended to smooth the transition from IPv4 to IPv6.
Besides, NAT's can only handle 65536-1024 connections
Actually you could handle a lot more TCP connections than that. If one user want to contact google.com and another user want to contact yahoo.com, those two connections could appear to come from the same IP and port number. That's perfectly valid according to the TCP standard. Your standard Linux based router probably doesn't support it. But if you had to, you could implement a NAT solution doing that. You'd still be limited to at most 64512 connections per remote port (or 64512 per remote IP if you worry about potential bugs in the TCP stack on the remote end). And if that is not enough, a NAT box does not have to have just one external IP. It could have a range of them, each of which would give you 64512 usable port numbers.
The problem with NAT is not so much the number of port numbers available, but rather keeping track of the state. Do you want to have a single point of failure for the entire country? Probably not. Besides, a single box might not be able to handle the load. Spread it out across multiple boxes, and you'd better be able to handle load and failover. But with multiple boxes you need to coordinate allocation of ports. And you cannot suddenly change port in the middle of a connection, so you'd have to update the state in a way that is consistent across all your boxes. The protocol needed to setup a single entry in the translation table is itself going to be more complicated than TCP. And then wait till somebody decides to DoS the system. Sooner or later somebody is going to start a flood of SYN packets from inside to outside. And no syn cookies are going to come to the rescue there, because those boxes are not terminating the TCP connection, just forwarding the packets with minor translation. Stateful translation at that scale is not something you just do. Stateless handling of packets is just the way to go. That is after all what made the Internet possible to begin with.
Forcing Level 3 to give up a significant amount of IPv4 addresses is probably not the best you can do for the IPv4 network. But maybe it would help push for IPv6 adoption.
DNS names are orthogonal to the protocol. You can name your devices with IPv6 the exact same way you would with IPv4. Do you think the full names are too long? Then just use a DNS search path. Only specify the local part of the name and have every device on your network know which search path to use. With IPv4 you would usually announce the search path through DHCP. I would expect you could do something equivalent with IPv6.
Do you need to change the top level part of the host names? Just update the DNS server as well as the server that announces the search path to everything on your network, and you are all set. Getting tired of having to make such changes? You don't have to buy your own domain name, there are various places where you can get a subdomain for free.
That's a lot of expense saved if they can delay switching over for a year.
I don't believe delaying it will save any expenses. Quite the contrary. The larger the internet gets, the more work it will be to upgrade. I think it would have been a lot cheaper if the switch had happened 10 years ago. But back then people were postponing it because why spend the money on something that might never become necessary, and if it is going to happen maybe by that time it would be somebody else's problem. With issues like the year 2000 bugs, there was a hard deadline to get them fixed, and no way to postpone it. With IPv4 addresses running out, there are workarounds. But each workaround made managing the net more complicated, and it will only take us so far. We still don't have a hard deadline in front of us. But most network administrators by now have realized, that this is something that will need to happen, and they will probably still be around by the time, so it is better to get started.
For all those years I had been assuming nobody had ever made a movie about killer tomatoes. How wrong I have been! Sometimes there are things you just assume without questioning it. In retrospect I should have questioned my first thoughts. If only I had been questioning it, I could have verified it and found out that in fact somebody had made a movie about killer tomatoes. Now all I can do is look back and wonder how many things in my life I would have done differently if I had known. Well, I can only think of one thing I really could have done differently. There was that one time where I was opening a can of tomato purée, and it exploded turning my kitchen from the usual white and blue into white and blue with red dots. If I had only known about killer tomatoes, I would have taken more care.
Re:I don't know if I fully agree with that
on
Fire Your IT Boss
·
· Score: 1
Even though I have only had two different jobs so far, I have already tried both ends of the spectrum. In the previous job I experienced a manager who didn't seem to know what the term source code meant. In my current job the manager of our department have been developing 3D graphics rendering software in the past. I by far prefer the technical manager. Though that is not the only reason I find my current job better.
Are you trying to tell me Web 2.0 does not mean anything? Then how exactly would you explain why so many web pages are served by hosts called www2.somedomain.tld?
The largest Google engineering office outside of USA is in Zürich. I work in this department http://www.google.ch/support/jobs/bin/topic.py?loc_id=1058&dep_id=1115, where we are responsible for the operation of a number of Google services. Such a job involves both system administration and engineering, and having good skills in both areas is the best chance to get hired. We currently need more people, so if you have the skills, there is a good chance of getting hired. We have equivalent jobs in a number of other places including Dublin and USA.
For getting a work permit in Switzerland, I know three things that can help improving your chances. Being an EU citizen, having a university degree, and having a job offer at hand. (Notice that Switzerland is not a member of EU, but has agreements with a number of long time EU members. Citizenship in a country that recently became member of EU is not that much help). I have not heard of any cases where a person satisfying all three conditions could not get a permit.
The only language you need to speak in order to get the job is English. The local language spoken in Zürich is a tough dialect of German, and it might not be the best choice for a second language. But if you learn high German, then you can get by (actually you can get by fairly well even if you only speak English).
We understand what you are saying, it just isn't correct. Once a C program makes a call to code not written in C, then it is no longer running C code. And the speed you see is not the speed of C code, but rather the speed of whatever language that code was written in.
None of us would claim python is as fast as C just because a python program could make use of a library written in C. And none of us would claim basic is as fast as C just because the source of a basic program could contain a binary blob which could be written out and executed.
On top of that, the C program you claim could be written does lack something. A C program can be written such that it can be compiled by an arbitrary C compiler and executed. However anything involving a JIT compiler is going to be tied to the architecture. ANSI C does not provide any means to generate native code, so you can never make such a program work on an arbitrary C compiler.
As processor caches increase, could you use this to run the kernel from the processor caches?
That idea doesn't really have anything to do with XiP support in the file system. You could run the kernel directly from flash as well. And since that is probably simpler, I'd be surprised if that isn't already done. As for running everything from the CPU cache, that is not controlled by the kernel but rather by the CPU itself. And it will try to use the cache for the mostly used parts of memory regardless of whether it is kernel code or not. Of course since the CPU caches are constrained by the number of gates used as well as the number of nanoseconds used to make a decision, they obviously can't always use the caches optimally, but caching all of the kernel wouldn't be optimal either, since there are some rarely used code paths in the kernel.
Clearly no matter how fast the interpreted language goes it can never be faster than C, as long as the interpreter (or JIT, or whatever) is written in C.
That argument doesn't apply to JIT compilers, because you no longer have an interpreted language but a language which is compiled to native code without going through C. But in many cases it is not the language that makes the difference, but rather how well the compiler optimizes the code. (Of course for JIT compilers the compilation time is more important, so you will have a trade off between compilation time and run time).
I can't imagine any case where C++ would outperform C in straightforward computation.
Depending on which compiler you use, there certainly could be a difference. Even between programs compiled with the same compiler there could be a factor of two or more of difference depending on optimization settings.
It was nothing like the Swedish I learned on the Muppets.
You have been deceived, the Swedish chef on the Muppets was never talking Swedish. I'm not sure exactly what he was speaking, to me it sounded more like a dialect of North American, but I'm not sure.
remap unlinking of a file to relinking it to a trash directory, something like $HOME/.Trash
Technically that could be done, but I can come up with a number of reasons why you might not want to implement it.
It might not be compliant with the posix standard, but I don't know for sure.
It screws up the algorithms to avoid fragmentation. If you want to keep files around until you are absolutely out of space, it means block allocation will have less freedom when choosing locations for new files. Less free blocks to choose from means it is more likely to fragment your file system.
Actually figuring out the right per-user trash directory is not something you would want to happen inside the kernel. Sometimes the original location is not even known once the file is deleted. You could have hardlinks from multiple users' home directories, then delete all of them while the file is actually open. Once the file is actually deleted, it doesn't even exist in the file system.
Having quota behave differently depending on where a file is located is problematic. It is hard to update efficiently and correctly when directories can be renamed and files can have multiple hardlinks.
The whole "undelete" thing is a DOS FAT stupidity. The *only* reason why people think that you *can* undelete is that the DOS FAT file system was designed in such a way that file changes could be recovered *IF* you managed not to change the file system too much.
That is actually not the case. The FAT table is used both as a linked list of the contents of a file, and as a free blocks "bitmap" where a special value would indicate a free block. That implies that to delete a file, the list of blocks used by that file would have to be overwritten with this special value. So after a file was deleted all information about where it is located on the disk is lost, except from the first block, which was recorded in the directory entry. What undelete utilities did was to assume the file was not fragmented, and simply take the first free blocks after the first one and pretend they were the file. If the file had been fragmented, it would be corrupted after undeletion. On ext2/ext3 you can undelete a file much more reliably because the free blocks bitmask and the pointers to actual blocks are separated. Though I don't know if the list of the first 12 blocks, which is in the inode, has to be wiped when the file is deleted.
I have successfully undeleted a 1GB file from an ext3 file system a month after it had been deleted on a file system that had writes happening all the time. But maybe I was just lucky.
Slashdot Mirror
It actually makes me happy to see that some people are starting to get the point. I have been pointing out these weaknesses for years.
Some of them are actually even worse. If the IV is just the sector number, then the difference between two neighbor sectors is known, and you can construct a file that will cancel out that difference and the two sectors get the same cipher text. I constructed a file some years ago, that demonstrated the problem. At that time Truecrypt was vulnerable to this attack. Truecrypt did apply some whitening after the encryption, but that didn't really make the pattern much worse. Put the file I mentioned on a Truecrypt volume encrypted in CBC mode, and somewhere in the encrypted image there will be two neighbor sectors that can be XORed together and will cancel out all the data leaving only the whitening pattern, which is easily recognizable because it repeats over many times through the sector.
Encrypting the IV is better, but still vulnerable to the problem you describe. In fact the problem you describe applies one way or another to almost every single disk encryption in existence. All the encryptions need some nonce or randomness, and since it doesn't fit in the sector, they cut a corner and use the sector number, which doesn't change when the sector is overwritten. (I have seen one that used extra space by mapping 32 logical sectors to 33 physical sectors, but that encryption had other problems including a weak pseudo random number generator, and potential data loss caused by the need to update two sectors which isn't done atomically).
Recent Truecrypt versions are no longer vulnerable to the attack I described above. They now use tweakable block ciphers. But just like CBC needs a unique IV for each time you encrypt, tweakable block ciphers need a unique tweak. Truecrypt use the sector number for tweak, so if a sector is overwritten, you have the same problem again. In fact it is even worse because there is no longer any chaining, just a tweak for each 16 byte block, which means changing a byte in a sector would keep changes in the cipher text within the 16 byte block. I didn't verify this in practice, I just read the specification. I mentioned this problem to the authors a long time ago, but they didn't consider it a problem.
Counter mode is one of the least secure ways to encrypt a disk. Counter mode generates a pseudo random one time pad, which in itself is secure if the pseudo random number generator is secure. However when used for disk encryption, the one time pad is reused whenever you overwrite a sector. Reusing a one time pad is not secure.
Just killing processes more or less at random when the system runs low on memory is not a good idea. (I know it is not completely random, but there surely ain't any guarantee that it will make sane decisions). What you really want is for programs to get an out of memory error when trying to allocate memory, and then they can shut down as gracefully as possible. (Would be neat if the choice of who get the first ENOMEM was chosen by the heuristics that would otherwise kill the process, but I guess that has not been implemented). Guaranteeing that you will never need to kill a process because you are out of memory means the kernel will have to not commit to more than can be backed by memory and swap. However since actual usage tends to be somewhat lower than what is actually committed to, that would be a bit wasteful. This is the main reason why it makes sense to have a large swap partition that is mostly unused. Just so you have backing for the amount you need to commit to in order to optimally use the physically available memory.
You typically wouldn't want to make use of most of that swap. So once any significant amount start getting used, you'd want to start giving ENOMEM errors. And that should help ensuring that the swap will only be used for a short time. There are a few pieces of data in virtual memory that are only used under very rare circumstances, and those it is nice to have on swap so they don't take up precious memory. So the aim is not to have zero swap in use, just some low number of pages that are really not needed in memory.
Is there any kernel out there that gets all of this right? I don't know. But at least those I know about can be tweaked to do pretty well.
I suppose that is not really a disk but rather flash storage. Swapping to flash is not the best idea as it could cause the flash to last shorter than it should. So I'd say this is probably one of those cases where no swap is the correct configuration.
There are a few more than that. But that's not a huge deal. There are actually corporations that need that many internal IPs. Of course the correct way would be for a corporation to use part of the IPs that they got allocated, and then just announce the subset they want to be worldwide routable and filter the rest. Using the same internal addresses in multiple corporations is bad because sometimes corporations have partnerships that does involve communication between their networks. If they were already using the same addresses internally, that would be causing trouble. But only corporations that were on the Internet early enough to get a /8 can do things the right way. All others are forced to do things not entirely right. If we revoke those ranges to do things right, we would be out of addresses before we could even release the ranges.
I think it is safe to assume that there are at least two corporations with such needs. So we can revoke 10/8 and give it to the first and allocate a new /8 and give it to the next. Then we will already have less IPs available than we have now.
No, most of those are reserved for corporations that were out early enough to get enough IP addresses. And that was at a time where the four octets in the address were actually supposed to indicate structure of the network to make routing simple.
I think there are 16 multicast (224-239) and 15 reserved (240-254) and the last one reserved for some purpose (255). But if you are going to hand out those, you are probably going to find that loads of systems are filtering them out. Just look at what happened when people started setting the ECN bits. Just something as simple as ignoring a bit was implemented incorrectly by a lot of systems. If you are going to have packets show up from new and unexpected IP ranges, you are going to see at least as many systems just drop your packets. If anybody really want to open op the reserved ranges at this time, I think they should be opened up for the use in products intended to smooth the transition from IPv4 to IPv6.
Actually you could handle a lot more TCP connections than that. If one user want to contact google.com and another user want to contact yahoo.com, those two connections could appear to come from the same IP and port number. That's perfectly valid according to the TCP standard. Your standard Linux based router probably doesn't support it. But if you had to, you could implement a NAT solution doing that. You'd still be limited to at most 64512 connections per remote port (or 64512 per remote IP if you worry about potential bugs in the TCP stack on the remote end). And if that is not enough, a NAT box does not have to have just one external IP. It could have a range of them, each of which would give you 64512 usable port numbers.
The problem with NAT is not so much the number of port numbers available, but rather keeping track of the state. Do you want to have a single point of failure for the entire country? Probably not. Besides, a single box might not be able to handle the load. Spread it out across multiple boxes, and you'd better be able to handle load and failover. But with multiple boxes you need to coordinate allocation of ports. And you cannot suddenly change port in the middle of a connection, so you'd have to update the state in a way that is consistent across all your boxes. The protocol needed to setup a single entry in the translation table is itself going to be more complicated than TCP. And then wait till somebody decides to DoS the system. Sooner or later somebody is going to start a flood of SYN packets from inside to outside. And no syn cookies are going to come to the rescue there, because those boxes are not terminating the TCP connection, just forwarding the packets with minor translation. Stateful translation at that scale is not something you just do. Stateless handling of packets is just the way to go. That is after all what made the Internet possible to begin with.
Forcing Level 3 to give up a significant amount of IPv4 addresses is probably not the best you can do for the IPv4 network. But maybe it would help push for IPv6 adoption.
DNS names are orthogonal to the protocol. You can name your devices with IPv6 the exact same way you would with IPv4. Do you think the full names are too long? Then just use a DNS search path. Only specify the local part of the name and have every device on your network know which search path to use. With IPv4 you would usually announce the search path through DHCP. I would expect you could do something equivalent with IPv6.
Do you need to change the top level part of the host names? Just update the DNS server as well as the server that announces the search path to everything on your network, and you are all set. Getting tired of having to make such changes? You don't have to buy your own domain name, there are various places where you can get a subdomain for free.
I don't believe delaying it will save any expenses. Quite the contrary. The larger the internet gets, the more work it will be to upgrade. I think it would have been a lot cheaper if the switch had happened 10 years ago. But back then people were postponing it because why spend the money on something that might never become necessary, and if it is going to happen maybe by that time it would be somebody else's problem. With issues like the year 2000 bugs, there was a hard deadline to get them fixed, and no way to postpone it. With IPv4 addresses running out, there are workarounds. But each workaround made managing the net more complicated, and it will only take us so far. We still don't have a hard deadline in front of us. But most network administrators by now have realized, that this is something that will need to happen, and they will probably still be around by the time, so it is better to get started.
For all those years I had been assuming nobody had ever made a movie about killer tomatoes. How wrong I have been! Sometimes there are things you just assume without questioning it. In retrospect I should have questioned my first thoughts. If only I had been questioning it, I could have verified it and found out that in fact somebody had made a movie about killer tomatoes. Now all I can do is look back and wonder how many things in my life I would have done differently if I had known. Well, I can only think of one thing I really could have done differently. There was that one time where I was opening a can of tomato purée, and it exploded turning my kitchen from the usual white and blue into white and blue with red dots. If I had only known about killer tomatoes, I would have taken more care.
Even though I have only had two different jobs so far, I have already tried both ends of the spectrum. In the previous job I experienced a manager who didn't seem to know what the term source code meant. In my current job the manager of our department have been developing 3D graphics rendering software in the past. I by far prefer the technical manager. Though that is not the only reason I find my current job better.
Are you trying to tell me Web 2.0 does not mean anything? Then how exactly would you explain why so many web pages are served by hosts called www2.somedomain.tld?
The largest Google engineering office outside of USA is in Zürich. I work in this department http://www.google.ch/support/jobs/bin/topic.py?loc_id=1058&dep_id=1115, where we are responsible for the operation of a number of Google services. Such a job involves both system administration and engineering, and having good skills in both areas is the best chance to get hired. We currently need more people, so if you have the skills, there is a good chance of getting hired. We have equivalent jobs in a number of other places including Dublin and USA.
For getting a work permit in Switzerland, I know three things that can help improving your chances. Being an EU citizen, having a university degree, and having a job offer at hand. (Notice that Switzerland is not a member of EU, but has agreements with a number of long time EU members. Citizenship in a country that recently became member of EU is not that much help). I have not heard of any cases where a person satisfying all three conditions could not get a permit.
The only language you need to speak in order to get the job is English. The local language spoken in Zürich is a tough dialect of German, and it might not be the best choice for a second language. But if you learn high German, then you can get by (actually you can get by fairly well even if you only speak English).
We understand what you are saying, it just isn't correct. Once a C program makes a call to code not written in C, then it is no longer running C code. And the speed you see is not the speed of C code, but rather the speed of whatever language that code was written in.
None of us would claim python is as fast as C just because a python program could make use of a library written in C. And none of us would claim basic is as fast as C just because the source of a basic program could contain a binary blob which could be written out and executed.
On top of that, the C program you claim could be written does lack something. A C program can be written such that it can be compiled by an arbitrary C compiler and executed. However anything involving a JIT compiler is going to be tied to the architecture. ANSI C does not provide any means to generate native code, so you can never make such a program work on an arbitrary C compiler.
That idea doesn't really have anything to do with XiP support in the file system. You could run the kernel directly from flash as well. And since that is probably simpler, I'd be surprised if that isn't already done. As for running everything from the CPU cache, that is not controlled by the kernel but rather by the CPU itself. And it will try to use the cache for the mostly used parts of memory regardless of whether it is kernel code or not. Of course since the CPU caches are constrained by the number of gates used as well as the number of nanoseconds used to make a decision, they obviously can't always use the caches optimally, but caching all of the kernel wouldn't be optimal either, since there are some rarely used code paths in the kernel.
That argument doesn't apply to JIT compilers, because you no longer have an interpreted language but a language which is compiled to native code without going through C. But in many cases it is not the language that makes the difference, but rather how well the compiler optimizes the code. (Of course for JIT compilers the compilation time is more important, so you will have a trade off between compilation time and run time).
Depending on which compiler you use, there certainly could be a difference. Even between programs compiled with the same compiler there could be a factor of two or more of difference depending on optimization settings.
I have successfully undeleted a 1GB file from an ext3 file system a month after it had been deleted on a file system that had writes happening all the time. But maybe I was just lucky.