linux-kernel - Re: [PATCH 2/2] MIPS: make kgdb depend on FPU support

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] [day] [month] [year] [list]

Message-ID: <20210210170500.3osd7agp4kpmygwk@maple.lan>
Date:   Wed, 10 Feb 2021 17:05:00 +0000
From:   Daniel Thompson <daniel.thompson@...aro.org>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
Cc:     Arnd Bergmann <arnd@...nel.org>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Arnd Bergmann <arnd@...db.de>,
        kernel test robot <lkp@...el.com>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        Paul Cercueil <paul@...pouillou.net>,
        Paul Burton <paulburton@...nel.org>,
        linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] MIPS: make kgdb depend on FPU support

On Wed, Feb 10, 2021 at 03:15:10PM +0100, Maciej W. Rozycki wrote:
> On Wed, 10 Feb 2021, Daniel Thompson wrote:
> 
> > >  NB if GDB sees a register padded out (FAOD it means all-x's rather than a 
> > > hex string placed throughout the respective slot) in a `g' packet, then it 
> > > will mark the register internally as "unavailable" and present it to the 
> > > receiver of the information as such rather than giving any specific value.  
> > > I don't remember offhand what the syntax for the `G' packet is in that 
> > > case; possibly GDB just sends all-zeros, and in any case you can't make 
> > > GDB write any specific value to such a register via any user
> > > interface.
> > 
> > kgdb doesn't track register validity and adding would be a fairly big
> > change. Everything internally (including some of the interactions with
> > arch code) is based on updating a binary shadow of register state which
> > is only bin2hex'ed just before transmitting a packet.
> 
>  I've had a peek and it doesn't appear to me it would be a big deal.
> 
>  We have `gdb_regs' defined as an array of longs.  We'd just need a second 
> array for a register validity bitmap, which could for simplicity just have 
> a single bit per each byte of `gdb_regs'.  It would then be updated in 
> `pt_regs_to_gdb_regs' according to the result of `dbg_get_reg' across the 
> number of bits given by `dbg_reg_def[i].size'.  And then `kgdb_mem2hex' 
> would interpret the bitmap given as an extra argument accordingly.
> 
>  It looks to me like a couple of lines of extra code really.

Agree, the core changes aren't too bad.

I was more concerned about whether the validity bits would leak into the
arch specific code via sleeping_thread_to_gdb_regs() and also noted the
effort needed to review each architectures dbg_get_reg() implementation
if we are going to react differently to it's return value.

It is still not an infeasible amount of work though if someone
does want to go in this direction.


Daniel.