I just read the Intel TSX reference (Chapter 8 of the current
Instruction Set Extensions
Programming Reference). It says, in Section 8.3.8.1:
In addition, in some implementations, the following instructions may
always cause
transactional aborts. These instructions are not expected to be commonly used
inside typical transactional regions. However, programmers must not
rely on these
instructions to force a transactional abort, since whether they cause
transactional
aborts is implementation dependent.
[...]
- Ring transitions: SYSENTER, SYSCALL, SYSEXIT, and SYSRET.
I suspect that many bits of the kernel expect that things they do
won't unhappen. For example, it could be fun to do:
int devrandom = open("/dev/random", O_RDONLY);
unsigned int abort_code = _xbegin();
if (abort_code & 1) {
printf("Your next random byte is %d\n", (int)(abort_code >> 24));
} else if (abort_code != 0) {
printf("Attack failed\n");
} else {
char r;
read(devrandom, &r, 1);
_xabort(r);
}
[This won't compile because _xabort requires an immediate argument.
Fixing that is easy with assembler tricks.]
So... do all of the syscall entries (and maybe even the page fault
handler) need explicit xabort instructions? Or is the manual (or my
understanding of it) wrong?
(The manual also says that IO instructions and sti might not abort.
That seems surprising.)
--Andy
P.S. Aside from this issue, TSX seems really neat. I can even think
of some single-threaded uses for it.
On 02/09/2012 11:40 PM, Andy Lutomirski wrote:
> [...]
>
> - Ring transitions: SYSENTER, SYSCALL, SYSEXIT, and SYSRET.
>
> I suspect that many bits of the kernel expect that things they do
> won't unhappen. For example, it could be fun to do:
>
That's why entering the kernel will cause an abort. In other words, you
will ALWAYS abort when you do a read(), and you will never reach your
_xabort().
> int devrandom = open("/dev/random", O_RDONLY);
> unsigned int abort_code = _xbegin();
>
> if (abort_code& 1) {
> printf("Your next random byte is %d\n", (int)(abort_code>> 24));
> } else if (abort_code != 0) {
> printf("Attack failed\n");
> } else {
> char r;
> read(devrandom,&r, 1);
> _xabort(r);
> }
-hpa
On Fri, Feb 10, 2012 at 9:18 AM, H. Peter Anvin <[email protected]> wrote:
> On 02/09/2012 11:40 PM, Andy Lutomirski wrote:
>>
>> [...]
>>
>> ?- Ring transitions: SYSENTER, SYSCALL, SYSEXIT, and SYSRET.
>>
>> I suspect that many bits of the kernel expect that things they do
>> won't unhappen. ?For example, it could be fun to do:
>>
>
> That's why entering the kernel will cause an abort. ?In other words, you
> will ALWAYS abort when you do a read(), and you will never reach your
> _xabort().
Is that architecturally guaranteed? (My manual suggests that it's
specifically *not* guaranteed, which is surprising.)
--Andy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andy Lutomirski wrote:
> On Fri, Feb 10, 2012 at 9:18 AM, H. Peter Anvin <[email protected]>
> wrote:
>> On 02/09/2012 11:40 PM, Andy Lutomirski wrote:
>>>
>>> [...]
>>>
>>> - Ring transitions: SYSENTER, SYSCALL, SYSEXIT, and SYSRET.
>>>
>>> I suspect that many bits of the kernel expect that things they do
>>> won't unhappen. For example, it could be fun to do:
>>>
>>
>> That's why entering the kernel will cause an abort. In other words, you
>> will ALWAYS abort when you do a read(), and you will never reach your
>> _xabort().
>
> Is that architecturally guaranteed? (My manual suggests that it's
> specifically *not* guaranteed, which is surprising.)
>
> --Andy
My understanding of the architecture manual's wording (which is a bit
clumsy) is that they want to leave themselves wiggle room just in case they
work out a way to do any of these things without requiring an abort.
If, for example, Intel add an MSR for SYSENTER that's used to go to a
different entrypoint if you're mid-transaction, you've suddenly broken all
code that assumes that SYSENTER triggers an abort - instead, some SYSENTERs
trigger an abort (as the kernel does the XABORT), while others don't.
Current implementations appear to always abort on ring transition, though.
- --
Simon Farnsworth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJPNWclAAoJEIKsye9/dtRWNoAH/j6H6mUzk+eS4yeZlcfd1DbG
cIicIJWGJNfm/TWAGb2ABrFgyDS+568ODFUogtAoLFcaxUieVVmuopjfgdjfiLdr
GoANhzyzohknQnHyiQetyTOzmkQVYCrMuRt/qplMO+k5DuvuN0FNxGW990B4jwQL
kFC2KSDMi2QKUnla2XbVsHR7xqe8gRJMEVB5DREkFiVhJGaf4Eyj0Rh4yLfSu9Ka
IngcU7Q6dmSlwCzmt/r+5BJeMvzfDa76+NxdStYDxe2FcZx7BdHeUwM9YyRPcrFp
Cgosn+C8Aiea15Ti/xYpd+M8LWGK8bq4XiV9a8D9WSagGngBrO1u1iCnx2hYKdI=
=hHwE
-----END PGP SIGNATURE-----
On 02/10/2012 09:24 AM, Andy Lutomirski wrote:
>
> Is that architecturally guaranteed? (My manual suggests that it's
> specifically *not* guaranteed, which is surprising.)
>
I asked internally for a statement, and got the following:
"Intel does not expect operating systems to require XABORT at the entry
points. Intel takes system security extremely seriously and that any
functionality added is scrutinized for security implications."
-hpa