Re: [RFC] tcg plugin: Additional plugin interface - Min-Yih Hsu

From: Min-Yih Hsu <minyihh@uci.edu>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: Aaron Lindsay <aaron@os.amperecomputing.com>, qemu-devel@nongnu.org
Subject: Re: [RFC] tcg plugin: Additional plugin interface
Date: Mon, 26 Apr 2021 09:27:08 -0700	[thread overview]
Message-ID: <2E8FB56E-AA11-46A1-8072-C43E8A5A854E@uci.edu> (raw)
In-Reply-To: <87a6pp6lit.fsf@linaro.org>

Hi Alex,

> On Apr 23, 2021, at 8:44 AM, Alex Bennée <alex.bennee@linaro.org> wrote:
> 
> 
> Min-Yih Hsu <minyihh@uci.edu> writes:
> 
>> Hi Alex and QEMU developers,
>> 
>> Recently I was working with the TCG plugin. I found that `qemu_plugin_cb_flags` seems to reserve the functionality to
>> read / write CPU register state, I'm wondering if you can share some
>> roadmap or thoughts on this feature?
> 
> I think reading the CPU register state is certainly on the roadmap,
> writing registers presents a more philosophical question of if it opens
> the way to people attempting a GPL bypass via plugins. However reading
> registers would certainly be a worthwhile addition to the API.

Interesting…I’ve never thought about this problem before.

> 
>> Personally I see reading the CPU register state as (kind of) low-hanging fruit. The most straightforward way to implement
>> it will be adding another function that can be called by insn_exec callbacks to read (v)CPU register values. What do you
>> think about this?
> 
> It depends on your definition of low hanging fruit ;-)
> 
> Yes the implementation would be a simple helper which could be called
> from a callback - I don't think we need to limit it to just insn_exec. I
> think the challenge is proving a non-ugly API that works cleanly across
> all the architectures. I'm not keen on exposing arbitrary gdb register
> IDs to the plugins.
> 
> There has been some discussion previously on the list which is probably
> worth reviewing:
> 
>  Date: Mon, 7 Dec 2020 16:03:24 -0500
>  From: Aaron Lindsay <aaron@os.amperecomputing.com>
>  Subject: Plugin Register Accesses
>  Message-ID: <X86YnHhHMpQBr2/G@strawberry.localdomain>
> 
> But in short I think we need a new subsystem in QEMU where frontends can
> register registers (sic) and then provide a common API for various
> users. This common subsystem would then be the source of data for:
> 
>  - plugins
>  - gdbstub
>  - monitor (info registers)
>  - -d LOG_CPU logging
> 
> If you are interested in tackling such a project I'm certainly happy to
> provide pointers and review.

Thank you! Yeah I’m definitely going to scratch a prototype for this register reading plugin interface. I’ll take a look at related email discussions.

Best,
-Min

> 
>> 
>> Thank you
>> -Min
> 
> 
> -- 
> Alex Bennée