Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp935479imm; Fri, 22 Jun 2018 07:45:28 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLNOjz6tlm13PnWKINrGgj8PB5JAnDZiJwT1mU5eyba/BbzIjeeJM7gK3Sq+zxo26IIPxFg X-Received: by 2002:a17:902:205:: with SMTP id 5-v6mr1977571plc.301.1529678728369; Fri, 22 Jun 2018 07:45:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529678728; cv=none; d=google.com; s=arc-20160816; b=ruwdcBjUpv/wEm7W9MyCgmAJlqt6tBp8F7pEEd2Ostqrx4vI0TtLz2r9OAT4WGMsZu V6zZt3nJ0WTfB9OyVihfPqXve56IBGCFUqdSMLsaq93JZhy6/nBCC3pCuybrbfydOfOW MO+oTX7u09uVIdzQOmeQsB1uxgo8pJugKYQwHbs9xLqXNms6/2VnUxvRuvMBA6yiKwk5 mfl882o5TTfco6BdTsUkc+TlDFbk/Np1WNkArGgmWdURl4vgwDcL5E8k8ZEKk3btpiZE WExqKkuPA75lbLGVIoeCv0c9IU1efOUGw4bUWyiL8N8VY+zvHjncKvFePvzgtLYOEFal o5vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=c4Jxbko1QDy+3lyjN2CEMTXnJiVvjQVVXQRAiJIHCxA=; b=spdUnX8pionHnn89Ko007NfLZsCmN2pfCbkTuIb00l0MjbVbmnifPQ7GIDml+zCUoB Dy+51oKkTeq8vLnN4/marsOdqUkcSELz+5FM3oY2RF2yRsC0f0lTtK4v/0pT0IOyM8In mBSdDBtnWx9t8G5QRKAgCyqvjS6CxCpvzoVMMfawnf7doeHdTg4vkwdGsaXQk9NB+L0a AcH1JndN7JpQmSiR6a/wCYOgrCNUAK21bt/P2Pf+DfvM6kdh3MaIVxAyZoKc/uwENHrw RRhS7vGkzTeGNVfiHi9c1pKmFdvyW4G1N/8GR9OgN0jheyxFug1Bs0w1IkRZjSgXdVoQ +9uQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="CFW/MGmM"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b2-v6si7407167plx.88.2018.06.22.07.45.13; Fri, 22 Jun 2018 07:45:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="CFW/MGmM"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933628AbeFVOoC (ORCPT + 99 others); Fri, 22 Jun 2018 10:44:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:45862 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932752AbeFVOoB (ORCPT ); Fri, 22 Jun 2018 10:44:01 -0400 Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F0504243EA for ; Fri, 22 Jun 2018 14:44:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1529678641; bh=ZkLqmeu2Y1QB+HsnAWu68umZ11V/oCejOZjq3XE7gFE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=CFW/MGmMzWw5EkeNWEKn2kPpDm5ahT5zRpxxSBOzUS5xKkO/MR6qURpYk432TcjyD 3Q//MbNQu5bbrLUBxXPiXnUO9vZ7y0rdG8OorbkHqGh5oRQKwdFqOR3aIggSP5gGO5 6zuscTds+gG/OdbIBINxPIBcK2X1YARYMcKB7mkw= Received: by mail-wm0-f41.google.com with SMTP id v16-v6so2494764wmh.5 for ; Fri, 22 Jun 2018 07:44:00 -0700 (PDT) X-Gm-Message-State: APt69E2zOO8zYlgHxVp8F9F2ixkIdB2FyrwF3+GBxEa9Q5S/Cb9j6Ylj iN+NF4od1pbnGRKGB3jHX2UktLP5JGfIbnwxMyopWg== X-Received: by 2002:a1c:f30f:: with SMTP id q15-v6mr1880126wmq.36.1529678639477; Fri, 22 Jun 2018 07:43:59 -0700 (PDT) MIME-Version: 1.0 References: <20180621211754.12757-1-h.peter.anvin@intel.com> <20180621211754.12757-7-h.peter.anvin@intel.com> In-Reply-To: <20180621211754.12757-7-h.peter.anvin@intel.com> From: Andy Lutomirski Date: Fri, 22 Jun 2018 07:43:47 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 6/7] x86/tls,ptrace: provide regset access to the GDT To: "H. Peter Anvin" Cc: LKML , "H. Peter Anvin" , "H. Peter Anvin" , Ingo Molnar , Thomas Gleixner , Andrew Lutomirski , "Bae, Chang Seok" , "Metzger, Markus T" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 21, 2018 at 2:18 PM H. Peter Anvin, Intel wrote: > > From: "H. Peter Anvin" > > Provide access to the user-visible part of the GDT via a regset in > ptrace(). Note that we already provide a regset for the TLS area part > of the GDT; these can trivially be unified by looking at the contents > of the regset structure, especially since the TLS area is the only > user-modifiable part of the GDT. This seems reasonable, although I'm not sure I see the point of making REGSET_GDT writable. (I see the point of making the LDT writable, but that's a different story.) > +static int gdt_get(struct task_struct *target, > + const struct user_regset *regset, > + unsigned int pos, unsigned int count, > + void *kbuf, void __user *ubuf) > +{ > + struct desc_struct gdt_copy[GDT_LAST_USER + 1]; > + const struct desc_struct *p; > + struct user_desc udesc; > + unsigned int index, endindex; > + int err; > + > + if (pos % sizeof(struct user_desc)) > + return -EINVAL; > + > + /* Get a snapshot of the GDT from an arbitrary CPU */ > + memcpy(gdt_copy, get_current_gdt_ro(), sizeof(gdt_copy)); > + > + /* Copy over the TLS area */ > + memcpy(&gdt_copy[GDT_ENTRY_TLS_MIN], target->thread.tls_array, > + sizeof(target->thread.tls_array)); > + > + /* Descriptor zero is never accessible */ > + memset(&gdt_copy[0], 0, sizeof(gdt_copy[0])); I think you should also mask out all system segments and all RPL != 3 segments. > +static int gdt_active(struct task_struct *target, > + const struct user_regset *regset) > +{ > + (void)target; > + return GDT_LAST_USER + 1; > +} I can't find the code, if any, that calls ->active. But, if it exists, is the result exposed to user space at all? If so, I think this should return the maximum theoretical size of the GDT. > + [REGSET_GDT] = { > + .core_note_type = NT_X86_GDT, > + .n = LDT_ENTRIES, /* Theoretical maximum */ > + .size = sizeof(struct user_desc), > + .align = sizeof(struct user_desc), > + .active = gdt_active, > + .get = gdt_get, .set = regset_gdt_set As above, barring a reason why it's useful, I think that removing .set would make sense. --Andy