From 472de63b0b8383565e103f809f5df37d1c4390ab Mon Sep 17 00:00:00 2001 From: James Morse Date: Tue, 19 May 2020 19:21:08 +0100 Subject: [PATCH] firmware: arm_sdei: Document the motivation behind these set_fs() calls The SDEI handler save/restores the addr_limit using set_fs(). It isn't very clear why. The reason is to mirror the arch code's entry assembly. The arch code does this because perf may access user-space, and inheriting the addr_limit may be a problem. Add a comment explaining why this is here. Suggested-by: Christoph Hellwig Signed-off-by: James Morse Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=822 Link: https://lore.kernel.org/r/20200519182108.13693-4-james.morse@arm.com Signed-off-by: Will Deacon --- drivers/firmware/arm_sdei.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c index b12b99a19f66..e7e36aab2386 100644 --- a/drivers/firmware/arm_sdei.c +++ b/drivers/firmware/arm_sdei.c @@ -1128,6 +1128,14 @@ int sdei_event_handler(struct pt_regs *regs, mm_segment_t orig_addr_limit; u32 event_num = arg->event_num; + /* + * Save restore 'fs'. + * The architecture's entry code save/restores 'fs' when taking an + * exception from the kernel. This ensures addr_limit isn't inherited + * if you interrupted something that allowed the uaccess routines to + * access kernel memory. + * Do the same here because this doesn't come via the same entry code. + */ orig_addr_limit = get_fs(); set_fs(USER_DS);