On 04/17/16 23:14, Andy Lutomirski wrote:
>>
>> It's not "weird", it is the ABI as defined. We have to do this for all
>> the system call arguments, too; you just don't notice it because the
>> compiler does it for us. Some other architectures, e.g. s390, has the
>> opposite convention where the
On Sun, Apr 17, 2016 at 11:01 PM, H. Peter Anvin wrote:
> On 04/17/16 22:48, Andy Lutomirski wrote:
>>
>> I think I prefer the "reject weird input" behavior over the "accept
>> and normalize weird input" if we can get away with it, and I'm fairly
>> confident that we can get away with "reject weir
On 04/17/16 22:48, Andy Lutomirski wrote:
>
> I think I prefer the "reject weird input" behavior over the "accept
> and normalize weird input" if we can get away with it, and I'm fairly
> confident that we can get away with "reject weird input" given that
> distro kernels do exactly that already.
On Sun, Apr 17, 2016 at 10:45 PM, H. Peter Anvin wrote:
> On 04/17/16 22:39, Andy Lutomirski wrote:
>>>
>>> I'm reasonably confident they have, because we have had security bugs
>>> TWICE when someone has tried to "optimize" the code. The masking was
>>> generally done with a movl instruction, wh
On 04/17/16 22:39, Andy Lutomirski wrote:
>>
>> I'm reasonably confident they have, because we have had security bugs
>> TWICE when someone has tried to "optimize" the code. The masking was
>> generally done with a movl instruction, which confused people.
>>
>>> So the type of the syscall nr is a
On Sun, Apr 17, 2016 at 10:21 PM, H. Peter Anvin wrote:
> On 04/17/16 22:18, Andy Lutomirski wrote:
>> On Sun, Apr 17, 2016 at 9:50 PM, H. Peter Anvin wrote:
>>> On 04/17/16 17:47, Ben Hutchings wrote:
We've always masked off the top 32 bits when x32 is enabled, but
hopefully no-one rel
On 04/17/16 22:18, Andy Lutomirski wrote:
> On Sun, Apr 17, 2016 at 9:50 PM, H. Peter Anvin wrote:
>> On 04/17/16 17:47, Ben Hutchings wrote:
>>> We've always masked off the top 32 bits when x32 is enabled, but
>>> hopefully no-one relies on that. Now that the slow path is in C, we
>>> check all
On 04/17/16 22:18, Andy Lutomirski wrote:
> On Sun, Apr 17, 2016 at 9:50 PM, H. Peter Anvin wrote:
>> On 04/17/16 17:47, Ben Hutchings wrote:
>>> We've always masked off the top 32 bits when x32 is enabled, but
>>> hopefully no-one relies on that. Now that the slow path is in C, we
>>> check all
On Sun, Apr 17, 2016 at 9:50 PM, H. Peter Anvin wrote:
> On 04/17/16 17:47, Ben Hutchings wrote:
>> We've always masked off the top 32 bits when x32 is enabled, but
>> hopefully no-one relies on that. Now that the slow path is in C, we
>> check all the bits there, regardless of whether x32 is ena
On 04/17/16 17:47, Ben Hutchings wrote:
> We've always masked off the top 32 bits when x32 is enabled, but
> hopefully no-one relies on that. Now that the slow path is in C, we
> check all the bits there, regardless of whether x32 is enabled. Let's
> make the fast path consistent with it.
We hav
We've always masked off the top 32 bits when x32 is enabled, but
hopefully no-one relies on that. Now that the slow path is in C, we
check all the bits there, regardless of whether x32 is enabled. Let's
make the fast path consistent with it.
Signed-off-by: Ben Hutchings
Cc: Andy Lutomirski
---
11 matches
Mail list logo
