| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 15 Apr 2022 01:39:49 -0700
From: Dan Li <ashimida@...ux.alibaba.com>
To: Kees Cook <keescook@...omium.org>
Cc: Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH] lkdtm: Add CFI_BACKWARD to test ROP mitigations
On 4/14/22 10:22, Kees Cook wrote:
> On Thu, Apr 14, 2022 at 03:19:02AM -0700, Dan Li wrote:
>> Hi, Kees,
>> Thanks for the rewrite. I tested this patch, and it works fine for
>> me except for a few minor comments below :)
>> We may need to ignore the pac high bits of return address according
>> to TCR.T1SZ (or simply remove the high 16 bits before comparing).
>
> Oh! Hah, yes, I totally forgot that. Thanks for testing -- getting PAC
> emulation working in QEMU has eluded me. I think untagged_addr() will
> work yes? i.e.:
>
> if((untagged_addr(*ret_addr) == expected)
>
untagged_addr might not clear enough bits, the following code works
fine for me:
+#define no_pac_addr(addr) \
+ ((__force __typeof__(addr))((__force u64)(addr) | PAGE_OFFSET))
- if(*ret_addr == expected)
+ if(no_pac_addr(*ret_addr) == expected)
*ret_addr = (addr);
I re-checked the arm manual and found that the pac bits in an address is:
- Xn[54:bottom_PAC_bit] //When address tagging is used
- Xn[63:56, 54:bottom_PAC_bit] //When address tagging is not used
bottom_PAC_bit = 64-TCR_ELx.TnSZ //For kernel is VA_BITS
The pac bits could be at most [63:56, 54:VA_BITS], untagged_addr
clears [63:56] (and clearing the high 16 bits doesn't seem to be
enough either :) ).
For example, when CONFIG_ARM64_VA_BITS_39 enabled, i get a case:
- lr : 0xffffffc0088d04f8
- lr with pac: 0x5681a740088d04f8
- PAGE_OFFSET: 0xffffff8000000000
"lr with pac|PAGE_OFFSET" seems to meet the need.
>>
>>> + else
>>> + /* Check architecture, stack layout, or compiler behavior... */
>>> + pr_warn("Eek: return address mismatch! %px != %px\n",
>>> + *ret_addr, addr);
>>
>> According to the context, it might be "expected" here?
>>
>> pr_warn("Eek: return address mismatch! %px != %px\n",
>> *ret_addr, expected);
>>
>> I simply ignored the upper 16 bits, and tested it separately
>> in gcc/llvm 12 with SCS/PAC and all the four cases worked fine for me.
>
> Great! Do you have the PAC "Oops" text handy so I can include it in the
> commit log as an example of what should be expected?
>
Yeah, in my test environment I get the following output:
/kselftest_install/lkdtm # ./CFI_BACKWARD.sh
[ 58.333529] lkdtm: Performing direct entry CFI_BACKWARD
[ 58.333927] lkdtm: Attempting unchecked stack return address redirection ...
[ 58.334230] lkdtm: ok: redirected stack return address.
[ 58.334870] lkdtm: Attempting checked stack return address redirection ...
[ 58.336287] Unable to handle kernel paging request at virtual address bfffffc0088d0514
[ 58.336633] Mem abort info:
[ 58.336789] ESR = 0x86000004
[ 58.336992] EC = 0x21: IABT (current EL), IL = 32 bits
[ 58.337234] SET = 0, FnV = 0
[ 58.337429] EA = 0, S1PTW = 0
[ 58.337611] FSC = 0x04: level 0 translation fault
[ 58.337874] [bfffffc0088d0514] address between user and kernel address ranges
[ 58.338304] Internal error: Oops: 86000004 [#1] PREEMPT SMP
[ 58.339209] Modules linked in:
[ 58.340384] CPU: 1 PID: 131 Comm: cat Not tainted 5.18.0-rc2-29474-gb8dcca8f6a13-dirty #393
[ 58.340842] Hardware name: linux,dummy-virt (DT)
[ 58.341231] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 58.341593] pc : 0xbfffffc0088d0514
[ 58.342255] lr : lkdtm_CFI_BACKWARD+0x108/0x130
[ 58.342716] sp : ffffffc00a73bc60
[ 58.342906] x29: ffffffc00a73bc60 x28: ffffff8003320000 x27: 0000000000000002
[ 58.343462] x26: ffffffc00a204d00 x25: 0000000000000002 x24: ffffffc0092e72f0
[ 58.343863] x23: 0000000000000006 x22: ffffffc00a204d10 x21: ffffff80188d2000
[ 58.344264] x20: ffffffc00a73bde0 x19: ffffffc00a302000 x18: ffffffffffffffff
[ 58.344732] x17: 663a72646461202c x16: 3866343064383830 x15: 0000000000000004
[ 58.345112] x14: 0000000000000fff x13: ffffffc009f8a3e0 x12: 0000000000000003
[ 58.345492] x11: 00000000ffffefff x10: c0000000ffffefff x9 : 90af2887c07d9500
[ 58.345926] x8 : ffffffc0088d04f8 x7 : 205d323234353333 x6 : 332e38352020205b
[ 58.346288] x5 : ffffffc00a2c313c x4 : 0000000000000001 x3 : 0000000000000000
[ 58.346670] x2 : 0000000000000000 x1 : ffffffc00968626d x0 : 000000000000006d
[ 58.347154] Call trace:
[ 58.347419] 0xbfffffc0088d0514
[ 58.347806] lkdtm_do_action+0x1c/0x30
[ 58.348085] direct_entry+0x178/0x1b0
[ 58.348291] full_proxy_write+0x6c/0xe8
[ 58.348523] vfs_write+0x174/0x3b0
[ 58.348721] ksys_write+0x78/0xe4
[ 58.348914] __arm64_sys_write+0x1c/0x28
[ 58.349125] el0_svc_common+0xa4/0x134
[ 58.349354] do_el0_svc+0x24/0x7c
[ 58.349551] el0_svc+0x28/0xa4
[ 58.349745] el0t_64_sync_handler+0x84/0xe4
[ 58.349995] el0t_64_sync+0x170/0x174
[ 58.350659] Code: bad PC value
[ 58.351182] ---[ end trace 0000000000000000 ]---
CFI_BACKWARD: saw 'call trace:|ok: control flow unchanged': ok
Thanks,
Dan.
Powered by blists - more mailing lists