Finally, we have identified the source of the race condition that led to EBS node failure.
This might be interesting.
Finally, we have identified the source of the race condition that led to EBS node failure.
If protected-mode virtual interrupts are not enabled, STI sets the interrupt flag (IF) in the EFLAGS register. After the IF flag is set, the processor begins responding to external, maskable interrupts after the next instruction is executed. The delayed effect of this instruction is provided to allow interrupts to be enabled just before returning from a procedure (or subroutine).
Starting with the Pentium Pro, Intel processors have supported out-of-order execution, where instructions are not necessarily performed in the order they appear in the executable. This can cause RDTSC to be executed later than expected, producing a misleading cycle count.[3] This problem can be solved by executing a serializing instruction, such as CPUID, to force every preceding instruction to complete before allowing the program to continue or by using RDTSCP instruction, which is a serializing variant of the RDTSC instruction (starting from Core i7[4]).
The LOCK prefix can be prepended only to the following instructions and only to those forms of the instructions where the destination operand is a memory operand: ADD, ADC, AND, BTC, BTR, BTS, CMPXCHG, CMPXCH8B, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR, XADD, and XCHG. The XCHG instruction always asserts the LOCK# signal regardless of the presence or absence of the LOCK prefix.
Hello,
We recently experienced a directed attack on SourceForge infrastructure (http://sourceforge.net/blog/sourceforge-net-attack/ ) and so we are resetting all passwords in the sf.net database -- just in case. We're e-mailing all sf.net registered account holders to let you know about this change to your account.
Our investigation uncovered evidence of password sniffing attempts. We have no evidence to suggest that your password has been compromised. But, what we definitely don't want is to find out in 2 months that passwords were compromised and we didn't take action.
So, as a proactive measure we've invalidated your SourceForge.net account password. To access the site again, you'll need to go through the email recovery process and choose a shiny new password:
https://sourceforge.net/account/registration/recover. php
If you need help with this, feel free to e-mail us:
sfnet_ops@geek.net
We appreciate your patience with us as we work to respond to this attack. We'll be working through the weekend to get things back to normal as quickly as possible.
Watch for updates on the service outages on our blog:
http://sourceforge.net/blog/
Thank you,
The SourceForge Team
Hello,
Please review this notice and contact us at sfnet_ops@geek.net with any concerns.
There was recently an attack on SourceForge systems as detailed here:
http://sourceforge.net/blog/sourceforge-attack-full-report
As a SourceForge user, you should already have received notice of our password reset event, also noted on the sourceforge.net login page.
As part of our response we examined account risks. User SSH key data may have been exposed during this incident. This is generally of limited concern since users post only the public key portion of their key pair.
In reviewing the SSH key data you uploaded for your account, we found one or more rows of data that did not appear to be a SSH public key. This could be junk text, private key data, or other data we can't programmatically identify.
As a precautionary measure have taken the step of clearing the SSH key data we have on file for your account. Please generate a new SSH key, login to sourceforge.net and upload a new public key. Instructions on SSH key generation may be found in our site docs at: http://sourceforge.net/apps/trac/sourceforge/wiki/SSH% 20keys
If you have concerns or require assistance in generating/uploading a new SSH public key, please contact us at sfnet_ops@geek.net
Thank you,
SourceForge.net staff
Password invalidation
Our analysis uncovered (among other things) a hacked SSH daemon, which was modified to do password capture. We don’t have reason to the attacker was successful in collecting passwords. But, the presence of this daemon and server level access to one-way hashed, and encrypted, password data led us to take the precautionary measure of invalidating all SourceForge user account passwords. Users have been asked to recover account access by email.
[someuser@hanworks ~]$ ~?
Supported escape sequences:
~. - terminate connection (and any multiplexed sessions)
~B - send a BREAK to the remote system
~C - open a command line
~R - Request rekey (SSH protocol 2 only)
~^Z - suspend ssh
~# - list forwarded connections
~& - background ssh (when waiting for connections to terminate)
~? - this message
~~ - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)
What is the overhead, in terms of space and time, of using a PAE enabled kernel as compared to an SMP kernel?
PAE doubles the size of page table entries from 32 bits to 64 bits, as well as adding a small third level to the page tables. This means the maximum amount of kernel memory consumed by page tables per process is doubled to slightly more than 6MB. In the 2.4.18 kernels shipped by Red Hat, this memory comes out of the ~700MB of available memory in the normal kernel zone. In the Red Hat Linux Advanced Server series of kernels, page tables can be located anywhere in physical memory.
The performance impact is highly workload dependent, but on a fairly typical kernel compile, the PAE penalty works out to be around a 1% performance hit on Red Hat’s test boxes. Testing with various other workload mixes has given performance hits ranging from 0% to 10%.
Source: Redhat white paper