[sandbox][testing] Filter out Arm64 unaddressable crashes [v8/v8 : main]
Maksim Ivanov (Gerrit)
Maksim Ivanov added 1 comment![]( "Open in Gerrit")
WDYT - this seems to fix spurious errors on ARM64. It doesn't address LA57 (even this simple test case triggers sandbox violation detected) but I'm not sure about the plan there.
Related details
- Samuel Groß
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Samuel Groß (Gerrit)
Samuel Groß added 1 comment![]( "Open in Gerrit")
WDYT - this seems to fix spurious errors on ARM64. It doesn't address LA57 (even this simple test case triggers sandbox violation detected) but I'm not sure about the plan there.
So what are the different configuration options? Is it just 48 or 57 bits? Or are there other address space configurations? I think currently the sandbox pretty much expects 48 bit VA, so we could also hardcode that into the filter, or alternatively mark the (assumed to be non-canonical) address range as safe memory region. But I agree, it probably also depends a bit on our plan for LA57.
Related details
- Maksim Ivanov
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Maksim Ivanov (Gerrit)
Maksim Ivanov added 1 comment![]( "Open in Gerrit")
Samuel GroßWDYT - this seems to fix spurious errors on ARM64. It doesn't address LA57 (even this simple test case triggers sandbox violation detected) but I'm not sure about the plan there.
So what are the different configuration options? Is it just 48 or 57 bits? Or are there other address space configurations? I think currently the sandbox pretty much expects 48 bit VA, so we could also hardcode that into the filter, or alternatively mark the (assumed to be non-canonical) address range as safe memory region. But I agree, it probably also depends a bit on our plan for LA57.
I found information about 48, 52 (ARMv8.2-A) and 57 bits.
Hardcoding max=48 bits in the filter can also be OK as a stop-gap solution until we figure out what to do with the sandbox.
Originally I was trying to make crash filters independent from the sandbox' own logic and just inferring actual virtual address space boundaries. However, it's probably pointless if the sandbox itself hardcodes 48 bits (is the latter true? does perhaps the fast untagging rely on <=48 bits?..).
Adding @mlippautz, @omerkatz for thoughts as well.
Related details
- Michael Lippautz
- Omer Katz
- Samuel Groß
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Omer Katz (Gerrit)
Omer Katz added 1 comment![]( "Open in Gerrit")
Samuel GroßWDYT - this seems to fix spurious errors on ARM64. It doesn't address LA57 (even this simple test case triggers sandbox violation detected) but I'm not sure about the plan there.
Maksim IvanovSo what are the different configuration options? Is it just 48 or 57 bits? Or are there other address space configurations? I think currently the sandbox pretty much expects 48 bit VA, so we could also hardcode that into the filter, or alternatively mark the (assumed to be non-canonical) address range as safe memory region. But I agree, it probably also depends a bit on our plan for LA57.
I found information about 48, 52 (ARMv8.2-A) and 57 bits.
Hardcoding max=48 bits in the filter can also be OK as a stop-gap solution until we figure out what to do with the sandbox.
Originally I was trying to make crash filters independent from the sandbox' own logic and just inferring actual virtual address space boundaries. However, it's probably pointless if the sandbox itself hardcodes 48 bits (is the latter true? does perhaps the fast untagging rely on <=48 bits?..).
Adding @mlippautz, @omerkatz for thoughts as well.
IIUC the issue for the sandbox with LA57 would be reservation size and not having enough bits for tags, right?
Could we "force" 48-bit VA by mapping any address requiring more than 48 bits as inaccessible? Just so we can safely assume a 48-bit VA until we have a better solution.
Related details
- Maksim Ivanov
- Michael Lippautz
- Samuel Groß
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Michael Lippautz (Gerrit)
Michael Lippautz added 1 comment![]( "Open in Gerrit")
Samuel GroßWDYT - this seems to fix spurious errors on ARM64. It doesn't address LA57 (even this simple test case triggers sandbox violation detected) but I'm not sure about the plan there.
Maksim IvanovSo what are the different configuration options? Is it just 48 or 57 bits? Or are there other address space configurations? I think currently the sandbox pretty much expects 48 bit VA, so we could also hardcode that into the filter, or alternatively mark the (assumed to be non-canonical) address range as safe memory region. But I agree, it probably also depends a bit on our plan for LA57.
Omer KatzI found information about 48, 52 (ARMv8.2-A) and 57 bits.
Hardcoding max=48 bits in the filter can also be OK as a stop-gap solution until we figure out what to do with the sandbox.
Originally I was trying to make crash filters independent from the sandbox' own logic and just inferring actual virtual address space boundaries. However, it's probably pointless if the sandbox itself hardcodes 48 bits (is the latter true? does perhaps the fast untagging rely on <=48 bits?..).
Adding @mlippautz, @omerkatz for thoughts as well.
IIUC the issue for the sandbox with LA57 would be reservation size and not having enough bits for tags, right?
Could we "force" 48-bit VA by mapping any address requiring more than 48 bits as inaccessible? Just so we can safely assume a 48-bit VA until we have a better solution.
We expect 48 bits for now so encoding that is okay.
We can also assume for now that 57 bits in Chrome are not addressable.
Related details
- Maksim Ivanov
- Samuel Groß
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |