Richard Henderson wrote:
>On 06/20/2011 04:39 PM, H. Peter Anvin wrote:
>> sys_foo:
>> cmpl$10, %edi
>> jae .L1
>>
>> movqfoo_table(,%rdi,3), %rax
>> retq
>> .L1:
>> movq$-EINVAL, %rax
>> retq
>>
>> Enter this function with a non-normalized %rdi and
On 06/20/2011 04:39 PM, H. Peter Anvin wrote:
> sys_foo:
> cmpl$10, %edi
> jae .L1
>
> movqfoo_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
On 06/20/2011 03:49 PM, Richard Henderson wrote:
>>
>> As I have already stated, if we *cannot* require pointers to be
>> zero-extended on entry to the kernel, we're going to have to have
>> special entry points for all the x32 system calls except the ones that
>> don't take pointers.
>
> If it's
On 06/20/2011 07:33 AM, H. Peter Anvin wrote:
> On 06/20/2011 07:01 AM, H.J. Lu wrote:
>> On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt
>> wrote:
>>> On 06/20/2011 03:51 PM, H.J. Lu wrote:
Promote pointers to Pmode when passing/returning in registers is
a security concern.
>
> No. Pr
On 06/20/2011 07:43 AM, H.J. Lu wrote:
> On Mon, Jun 20, 2011 at 7:33 AM, H. Peter Anvin wrote:
>> On 06/20/2011 07:01 AM, H.J. Lu wrote:
>>> On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt
>>> wrote:
On 06/20/2011 03:51 PM, H.J. Lu wrote:
> Promote pointers to Pmode when passing/returni
On Mon, Jun 20, 2011 at 7:40 AM, Jeff Law wrote:
>
>>> Peter, do you think it is safe to assume upper 32bits are zero in
>>> user space for x32? Kernel isn't a problem since pointer is 64bit
>>> in kernel and we don't pass pointers on stack to kernel.
>>
>> As I have already stated, if we *cannot*
On Mon, Jun 20, 2011 at 7:33 AM, H. Peter Anvin wrote:
> On 06/20/2011 07:01 AM, H.J. Lu wrote:
>> On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt
>> wrote:
>>> On 06/20/2011 03:51 PM, H.J. Lu wrote:
Promote pointers to Pmode when passing/returning in registers is
a security concern.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/20/11 08:33, H. Peter Anvin wrote:
> On 06/20/2011 07:01 AM, H.J. Lu wrote:
>> On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt
>> wrote:
>>> On 06/20/2011 03:51 PM, H.J. Lu wrote:
Promote pointers to Pmode when passing/returning in register
On 06/20/2011 07:01 AM, H.J. Lu wrote:
> On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt
> wrote:
>> On 06/20/2011 03:51 PM, H.J. Lu wrote:
>>> Promote pointers to Pmode when passing/returning in registers is
>>> a security concern.
No. Promoting *NON*-pointers (or rather, requiring non-pointers
On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt wrote:
> On 06/20/2011 03:51 PM, H.J. Lu wrote:
>> Promote pointers to Pmode when passing/returning in registers is
>> a security concern.
>
> Whuh?
>
Peter, do you think it is safe to assume upper 32bits are zero in
user space for x32? Kernel isn't
On 06/20/2011 03:51 PM, H.J. Lu wrote:
> Promote pointers to Pmode when passing/returning in registers is
> a security concern.
Whuh?
> * combine.c (cant_combine_insn_p): Check zero/sign extended
> hard registers.
This part is OK.
Bernd
Promote pointers to Pmode when passing/returning in registers is
a security concern. This patch removes ix86_promote_function_mode,
which exposes:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47725
There are 2 different patches for PR 47725:
http://gcc.gnu.org/ml/gcc-patches/2011-02/threads.html
12 matches
Mail list logo