linux-kernel - Re: [V6,1/9] elf: Add new powerpc specifc core note sections

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <OFCDE0430E.A5CD2FAF-ONC1257E23.003813C4-C1257E23.0039F950@de.ibm.com>
Date:	Fri, 10 Apr 2015 12:33:13 +0200
From:	Ulrich Weigand <Ulrich.Weigand@...ibm.com>
To:	Anshuman Khandual <khandual@...ux.vnet.ibm.com>
Cc:	akpm@...ux-foundation.org, avagin@...nvz.org, davej@...hat.com,
	davem@...emloft.net, dhowells@...hat.com,
	Edjunior Barbosa Machado <emachado@...ux.vnet.ibm.com>,
	james.hogan@...tec.com, kirjanov@...il.com,
	linux-kernel@...r.kernel.org, linuxppc-dev@...abs.org,
	Michael Neuling <mikey@...ling.org>, oleg@...hat.com,
	palves@...hat.com, Paul.Clothier@...tec.com, peterz@...radead.org,
	sam.bobroff@....ibm.com, shuahkh@....samsung.com,
	sukadev@...ux.vnet.ibm.com, tglx@...utronix.de
Subject: Re: [V6,1/9] elf: Add new powerpc specifc core note sections

Anshuman Khandual <khandual@...ux.vnet.ibm.com> wrote on 10.04.2015
11:10:35:

> I had posted a newer version [V7] of this patch series couple of months
back
> which got ignored while the discussion continued in this version.
>
> V7: https://lkml.org/lkml/2015/1/14/19

Ah, with all the back-and-forth on the checkpointed state, I never looked
at this.  Unfortunately, there's still a number of issues with this, I
think:

- You provide checkpointed FPR and VMX registers, but there doesn't seem
  to be any way to get at the checkpointed *VSX* registers (i.e. the part
  that is neither covered by FPR or VMX, corresponding to NT_PPC_VSX).

- We may have had this discussion in the past, but I still do not like the
  notion of a "misc" register set, in particular since the three registers
  in it are available at different architecture levels and categories.

  I would much prefer three separate regsets (e.g. NT_PPC_DSCR, NT_PPC_PPR,
  and NT_PPC_TAR), each of which is available and valid if and only if the
  current processor actually has the register in question.

  If we do have a single regset, at the very least a "get" operation should
  set registers unvailable on the machine to a defined state (zero?)
  instead of simply leaving memory uninitialized.

- Similarly, the NT_PPC_TM_SPR regset as currently defined mixes and
matches
  registers with different "lifetimes".  The transactional memory registers
  (TFHAR, TEXASR, TFIAR) are available *always* on machines that support
  transactions.  But the other registers in that regset are checkpointed
  versions that are only available/valid within a transaction.  I think a
  better way to faithfully represent this would be to have the
NT_PPC_TM_SPR
  regset only contain the transcational memory registers, and use separate
  regsets for the checkpointed registers -- those should parallel the non-
  checkpointed register regset.

  For example, if we have NT_PPC_DSCR, there should be a NT_PPC_CDSCR for
  the checkpointed version etc.  (If we do stay with MISC, there should
then
  be a CMISC).

- Particularly confusing to me is the "checkpointed original MSR" which
  currently also resides in NT_PPC_TM_SPR.  What exactly is this?  How
  does that differ from the MSR slot in the NT_PPC_TM_CGPR regset?

  I may be misreading kernel code, but it seems the kernel does not
actually
  use the ckpt_regs.msr slot at all, and therefore the corresponding slot
of
  the NT_PPC_TM_CGPR regset is likewise undefined/unused.  Would it not be
  more consistent to use that slot to pass the checkpointed MSR?

  In any case, it seems the ptrace set-register case currently allows user
  space to restore *any* arbitrary value into the checkpointed MSR, which
  would presumably get restored into the real MSR at some point, unless I'm
  missing something here.  Do we not need a check that only safe bits are
  modified, just like with ptrace access to the real MSR?

Bye,
Ulrich

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/