On 12/12/2014 05:45 PM, Andy Lutomirski wrote:
> I was thinking of this:
>
> + if (is_64bit_mm(mm)) {
> + vaddr_space_size = 1ULL << __VIRTUAL_MASK_SHIFT;
> + bd_entry_virt_space = vaddr_space_size / MPX_BD_NR_ENTRIES_64;
> + /*
> + * __VIRTUAL_MASK takes the 64-bit addressing hole
> + * in
On Fri, Dec 12, 2014 at 4:23 PM, Dave Hansen wrote:
> On 12/12/2014 04:11 PM, Andy Lutomirski wrote:
>> On Fri, Dec 12, 2014 at 3:16 PM, Dave Hansen wrote:
>>> On 12/12/2014 03:04 PM, Andy Lutomirski wrote:
Anyway, do your patches handle the case where a 32-bit app maliciously
executes
On 12/12/2014 04:11 PM, Andy Lutomirski wrote:
> On Fri, Dec 12, 2014 at 3:16 PM, Dave Hansen wrote:
>> On 12/12/2014 03:04 PM, Andy Lutomirski wrote:
>>> Anyway, do your patches handle the case where a 32-bit app maliciously
>>> executes a 64-bit mpx insn with a very large address? I think it's
On Fri, Dec 12, 2014 at 3:16 PM, Dave Hansen wrote:
> On 12/12/2014 03:04 PM, Andy Lutomirski wrote:
>> Anyway, do your patches handle the case where a 32-bit app maliciously
>> executes a 64-bit mpx insn with a very large address? I think it's
>> okay, but I might have missed something.
>
> You
On 12/12/2014 03:04 PM, Andy Lutomirski wrote:
> Anyway, do your patches handle the case where a 32-bit app maliciously
> executes a 64-bit mpx insn with a very large address? I think it's
> okay, but I might have missed something.
You mean in the instruction decoder? I haven't tried that case
e
n Fri, Dec 12, 2014 at 1:41 PM, Dave Hansen wrote:
> On 12/12/2014 12:48 PM, Andy Lutomirski wrote:
>> On Fri, Dec 12, 2014 at 12:27 PM, Dave Hansen wrote:
>>> You want the same size structures with the same format for 32-bit and
>>> 64-bit modes?
>>
>> Yes. Especially because programs can switc
On 12/12/2014 12:48 PM, Andy Lutomirski wrote:
> On Fri, Dec 12, 2014 at 12:27 PM, Dave Hansen wrote:
>> You want the same size structures with the same format for 32-bit and
>> 64-bit modes?
>
> Yes. Especially because programs can switch between 32-bit and 64-bit
> mode entirely in userspace.
On Fri, Dec 12, 2014 at 12:27 PM, Dave Hansen wrote:
> On 12/12/2014 12:22 PM, Andy Lutomirski wrote:
>> On 12/12/2014 11:12 AM, Dave Hansen wrote:
>>> This is 3.20 material. I'm hoping to get some comments early
>>> in case folks have some issues with the way it's being done.
>>>
>>> The MPX har
On 12/12/2014 12:27 PM, Andy Lutomirski wrote:
> On 12/12/2014 11:12 AM, Dave Hansen wrote:
>> This is 3.20 material. I'm hoping to get some comments early
>> in case folks have some issues with the way it's being done.
>
> Would it make sense to disable MPX for 32-bit binaries on 64-bit kernels
On 12/12/2014 11:12 AM, Dave Hansen wrote:
This is 3.20 material. I'm hoping to get some comments early
in case folks have some issues with the way it's being done.
Would it make sense to disable MPX for 32-bit binaries on 64-bit kernels
for 3.19?
--Andy
--
The MPX hardware structures d
On 12/12/2014 12:22 PM, Andy Lutomirski wrote:
> On 12/12/2014 11:12 AM, Dave Hansen wrote:
>> This is 3.20 material. I'm hoping to get some comments early
>> in case folks have some issues with the way it's being done.
>>
>> The MPX hardware structures differ in layout in 32 and 64-bit
>> mode.
On 12/12/2014 11:12 AM, Dave Hansen wrote:
This is 3.20 material. I'm hoping to get some comments early
in case folks have some issues with the way it's being done.
--
The MPX hardware structures differ in layout in 32 and 64-bit
mode. A 32-bit binary running on a 64-bit kernel needs the
32-b
12 matches
Mail list logo
