On 18/03/21 18:40, Lorenzo Susini wrote:
Well I'm sorry but I didn't know IDT was marked as read only by
Linux. If it is read only, how can you register any new interrupt
handler? I guess it's a way of securing stuff against malicious
attacks. I was taking for granted that the IDT was written whe
Well I'm sorry but I didn't know IDT was marked as read only by Linux. If
it is read only, how can you
register any new interrupt handler? I guess it's a way of securing stuff
against malicious attacks.
I was taking for granted that the IDT was written when registering a new
irq handler,
given that
On 18/03/21 17:07, Laszlo Ersek wrote:
However, when I try to register a new interrupt handler (for instance for
the edu device, just to try it out), it works perfectly,
meaning that the IDT is not really read-only. Do you have any idea why? Any
suggestions on how to solve the problem?
Of course
On 03/18/21 12:28, Lorenzo Susini wrote:
> Hello,
>
> Have some of you successfully used the KVM_MEM_READONLY slot flag?
I think the operation of the pflash device is based on that, yes.
One related commit is 235e8982ad39 ("kvm: support using KVM_MEM_READONLY
flag for regions", 2013-05-29).
So
Hello,
Have some of you successfully used the KVM_MEM_READONLY slot flag?
I'm working on a project and I'm trying to protect the guest's IDT by using
KVM, modifying kvm-all.c.
I'm able to correctly locate the IDT in the host by reading IDTR with
KVM_GET_SREGS,
translating it with KVM_TRANSLATE an
