Richard Henderson <r...@redhat.com> wrote: >On 06/20/2011 04:39 PM, H. Peter Anvin wrote: >> sys_foo: >> cmpl $10, %edi >> jae .L1 >> >> movq foo_table(,%rdi,3), %rax >> retq >> .L1: >> movq $-EINVAL, %rax >> retq >> >> Enter this function with a non-normalized %rdi and you have a >security >> hole even though the C is perfectly fine. > >Yes, I get that. Isn't it already the case that x86_64 defines the >upper half of 32-bit inputs as garbage? Assuming you're never >intending >to run an x32 kernel, but always an x32 environment within an x86_64 >kernel, where does the talk of security holes wrt non-pointers come >from? > > >r~
H.J. was proposing an ABI change. I wanted to explain that the current ABI is the way it is for a reason. x32 pointers, however, can and should be zero-extended since they will be 64 bits in the kernel, as you correctly point out. -- Sent from my mobile phone. Please excuse my brevity and lack of formatting.
