Re: PV - different behavior of pgd_offset in xen 4.6 and 4.13 for GUEST ACCESSIBLE memory area

[Charles Gonçalves]

Thanks for pointing this fix Jan. It helped me a lot.
Best!

On Fri, Oct 8, 2021, 10:30 Jan Beulich  wrote:

> On 07.10.2021 17:10, Charles Gonçalves wrote:
> > During some experiments in my PhD I've tried to reused a code from
> > Jann Horn (
> https://bugs.chromium.org/p/project-zero/issues/detail?id=1184
> > ) that used the mapping in
> >
> > ```
> > 0x8040 - 0x807f [256GB, 2^38 bytes, PML4:256]
> > Reserved for future shared info with the guest OS (GUEST ACCESSIBLE)
> > ```
> > to map some temporary page table data to be able to attack the system.
> >
> > This used to work on Xen 4.6:
> >
> > ```
> > #define MY_SECOND_AREA 0x8040ULL
> > printk("PML4 entry: 0x%lx\n", (unsigned
> > long)pgd_val(*pgd_offset(current->mm, MY_SECOND_AREA)));
> > ```
> >
> > In xen 4.6 :
> >
> > `[ 3632.620105] PML4 entry: 0x183d125067 `
> > Returns a valid PGD ( pgd_present(*pdg) == true )
> >
> > but has different behavior in Xen 4.13 (despite no change in the
> > asm-x86/config.h .
> >
> > In xen 4.13:
> >
> > `[70386.796119] PML4 entry: 0x80021a445025`
> > Return a bad PGD ( pgd_bad(*pdg) == true )
>
> There's nothing really bad in this entry afaics. The entry is r/o
> and nx, yes, but that ought to be fine (i.e. I think pgd_bad() is
> too rigid here, but may not be valid to be used on hypervisor
> controlled entries in the first place).
>
> > I could not find any reference on the branch RELEASE-4.13.0 of why
> > this happens this way.
> > Any hint of what is happening here?
> > Has Xen changed the way it handles memory from regions in range
> > 0x8040 - 0x807f  across those versions?
>
> Yes - see a5a5d1ee949d ("x86/mm: Further restrict permissions on some
> virtual mappings"). The page table arrangement underlying this VA
> range isn't part of the ABI, i.e. we're free to change it at any time.
>
> Jan
>
>

PV - different behavior of pgd_offset in xen 4.6 and 4.13 for GUEST ACCESSIBLE memory area

[Charles Gonçalves]

Hello Guys,

During some experiments in my PhD I've tried to reused a code from
Jann Horn (https://bugs.chromium.org/p/project-zero/issues/detail?id=1184
) that used the mapping in

```
0x8040 - 0x807f [256GB, 2^38 bytes, PML4:256]
Reserved for future shared info with the guest OS (GUEST ACCESSIBLE)
```
to map some temporary page table data to be able to attack the system.

This used to work on Xen 4.6:

```
#define MY_SECOND_AREA 0x8040ULL
printk("PML4 entry: 0x%lx\n", (unsigned
long)pgd_val(*pgd_offset(current->mm, MY_SECOND_AREA)));
```

In xen 4.6 :

`[ 3632.620105] PML4 entry: 0x183d125067 `
Returns a valid PGD ( pgd_present(*pdg) == true )

but has different behavior in Xen 4.13 (despite no change in the
asm-x86/config.h .

In xen 4.13:

`[70386.796119] PML4 entry: 0x80021a445025`
Return a bad PGD ( pgd_bad(*pdg) == true )

I could not find any reference on the branch RELEASE-4.13.0 of why
this happens this way.
Any hint of what is happening here?
Has Xen changed the way it handles memory from regions in range
0x8040 - 0x807f  across those versions?

I'm running on intel x64, on paravirtualization mode, the only
difference in the system is the xen version.


Atenciosamente,
Charles Ferreira Gonçalves

Re: Serial Console : SOL vs Physical Port

[Charles Gonçalves]

Thanks @Jan Beulich 

On Thu, Apr 29, 2021 at 10:35 AM Jan Beulich  wrote:

> On 28.04.2021 20:49, Charles Gonçalves wrote:
> > Is there any difference between both?
> > I'm trying to debug an issue using a SOL but the host crashes before any
> > meaningful message.
> >
> > The SOL is working properly when I can debug some crashes perfectly. But
> > for a specific case I'm wondering if I could be losing some messages.
>
> Well, without having an explanation, experience tells me that SOL in
> some cases is more fragile. Do you have "sync_console" in place?

I was missing the options  `sync_console console_to_ring`.
But this did not help either.


> Does
> the crash perhaps happen too early for the serial output to have got
> configured in Xen yet?
>
This is not the case, I trigger  intentionally the "bug" invoking an HC

But thanks for your help!


> Jan
>

Serial Console : SOL vs Physical Port

[Charles Gonçalves]

Hello Guys,

Is there any difference between both?
I'm trying to debug an issue using a SOL but the host crashes before any
meaningful message.

The SOL is working properly when I can debug some crashes perfectly. But
for a specific case I'm wondering if I could be losing some messages.

Atenciosamente,
*Charles Ferreira Gonçalves *

Re: Writing to arbritary cannonical addresses

[Charles Gonçalves]

Thanks again Andrew, ...

My initial idea was to allocate a frame on kernel space and change the
update_va_mapping to "forcibly" write the desired MFN as the l1 page table
and return the va.

You can see what I did here:
https://github.com/charlesfg/xen/blob/5755f0752bd50891942768bf99898bbc8f7eac82/xen/arch/x86/mm.c#L4539

Basically, I assume the fast path and for the UPDATE_ENTRY
https://github.com/charlesfg/xen/blob/5755f0752bd50891942768bf99898bbc8f7eac82/xen/arch/x86/mm.c#L2184


Any help on this would be greatly appreciated  :)


Atenciosamente,
*Charles Ferreira Gonçalves *




On Tue, Apr 20, 2021 at 7:05 PM Andrew Cooper 
wrote:

> On 20/04/2021 17:13, Charles Gonçalves wrote:
> > Hello Guys,
> >
> > I'm trying to reproduce old exploit behaviors in a simplistic way:
> > create an hypercall to write a buffer to a specific MFN.
> >
> > At first, I thought that updating an l1 page in a valid VA in guest
> > kernel space would do the trick.
> > But for addresses outside the  Guest-defined use (0x -
> > 0x7fff ) is a no go!
> > I get a page fault with  'reserved bit in page table' warning message.
> >
> > Now I'm trying to write to the address inside the hypervisor code, but
> > not sure how to do it.
> >
> > Any comments or tips on this?
>
> So you're looking to add a hypercall to make arbitrary unaudited changes
> to arbitrary memory, to simulate past security issues?
>
> If you're seeing "Reserved bit in page table" then you've managed to
> corrupt a pagetable entry somehow.  Xen doesn't write any reserved bits
> (which it doesn't know how to interpret).
>
> I'm afraid that if you want any further help with this specific failure,
> you're going to have to post your changes to Xen somewhere.  pastebin,
> or a pointer to a git branch, or whatever, but my divination skills
> aren't great...
>
> ~Andrew
>
>

Writing to arbritary cannonical addresses

[Charles Gonçalves]

Hello Guys,

I'm trying to reproduce old exploit behaviors in a simplistic way:  create
an hypercall to write a buffer to a specific MFN.

At first, I thought that updating an l1 page in a valid VA in guest kernel
space would do the trick.
But for addresses outside the  Guest-defined use (0x -
0x7fff ) is a no go!
I get a page fault with  'reserved bit in page table' warning message.

Now I'm trying to write to the address inside the hypervisor code, but not
sure how to do it.

Any comments or tips on this?


Atenciosamente,
*Charles Ferreira Gonçalves *

Re: Memory Layout on Dom0 in PV

[Charles Gonçalves]

Thanks @Andrew,

A LKM to dump the arch->p2m_vaddr solved the issue and answered my
questions!

Atenciosamente,
*Charles Ferreira Gonçalves *




On Fri, Apr 16, 2021 at 4:12 PM Andrew Cooper 
wrote:

> On 16/04/2021 15:58, Charles Gonçalves wrote:
>
> Hello Guys,
>
> Does memory on Dom0 also mapped to gpfn or it is mapped directly to mfn?
>
>  If mapped to gpfn, how can I access its p2m mapping?
>
> I'm trying to use the xen-mfndump but it is not working with dom0
>
> ./xen-mfndump dump-p2m 0
> xc: error: Could not map the shared info frame (MFN 0xddfe9) (3 = No such 
> process): Internal error
> xc: error: Could not map domain 0 memory information: Internal error
>
> The problem that I'm wanting to solve is:
>
> Given a va in a process on dom0, I can get its physical representation
> (mfn or gpfn depending on how this works on PV) using /proc/pid/pagemap
> and with this I can access its real mfn.
>
> This works perfectly with domU but not with dom0, why?
>
>
> There are a lot of operations you're not permitted to perform on yourself,
> to prevent problems.
>
> I think in this case, Xen is rejecting dom0's attempt to foreign map
> itself (although -EINVAL would be better than -ESRCH to fail with, IMO),
> because otherwise we get into reference counting issues IIRC.
>
> You'll probably have an easier time asking the dom0 kernel to dump the
> p2m.  After all, its a kernel-owned datastructure, not a Xen-owned
> structure.
>
> ~Andrew
>

Memory Layout on Dom0 in PV

[Charles Gonçalves]

Hello Guys,

Does memory on Dom0 also mapped to gpfn or it is mapped directly to mfn?

 If mapped to gpfn, how can I access its p2m mapping?

I'm trying to use the xen-mfndump but it is not working with dom0

./xen-mfndump dump-p2m 0
xc: error: Could not map the shared info frame (MFN 0xddfe9) (3 = No
such process): Internal error
xc: error: Could not map domain 0 memory information: Internal error

The problem that I'm wanting to solve is:

Given a va in a process on dom0, I can get its physical representation (mfn
or gpfn depending on how this works on PV) using /proc/pid/pagemap and with
this I can access its real mfn.

This works perfectly with domU but not with dom0, why?

Atenciosamente,
*Charles Ferreira Gonçalves *

Re: Failed to enable debug messages in xen 4.13

[Charles Gonçalves]

Thanks, @Jan and  @Andrew


`make -C xen menuconfig` helped a lot 
And indeed there a typo in the grub line

It's working now!

Thanks for helping with this question!




Atenciosamente,
*Charles Ferreira Gonçalves *




On Thu, Apr 15, 2021 at 3:01 PM Jan Beulich  wrote:

> On 15.04.2021 15:55, Charles Gonçalves wrote:
> > I've enabled the log_lvl=all guest_loglvl=all,
>
> The first one is mis-spelled and needs to be "loglvl=".
>
> > tried the xl debug-key +,
>
> If this didn't help, did you perhaps not do a debug build of Xen?
> Debug messages get completely compiled out of release builds.
>
> > configured the build with
> > ./configure --enable-debug
>
> This, in any event, has an effect on the tool stack build only.
> The hypervisor build gets configured via kconfig, with the settings
> tracked in xen/.config.
>
> Jan
>

Failed to enable debug messages in xen 4.13

[Charles Gonçalves]

Hello Guys,

I've enabled the log_lvl=all guest_loglvl=all, tried the xl debug-key +,
configured the build with
./configure --enable-debug

Do I miss something?

xl info

  6:15
host   : xendev
release: 4.4.0-148-generic
version: #174~14.04.1-Ubuntu SMP Thu May 9 08:17:37 UTC 2019
machine: x86_64
nr_cpus: 16
max_cpu_id : 15
nr_nodes   : 1
cores_per_socket   : 8
threads_per_core   : 2
cpu_mhz: 2994.413
hw_caps:
178bf3ff:f6d8320b:2e500800:244033ff:000f:209c01a9::0500
virt_caps  : pv hvm hvm_directio pv_directio hap shadow
total_memory   : 32699
free_memory: 28229
sharing_freed_memory   : 0
sharing_used_memory: 0
outstanding_claims : 0
free_cpus  : 0
xen_major  : 4
xen_minor  : 13
xen_extra  : .0
xen_version: 4.13.0
xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler  : credit2
xen_pagesize   : 4096
platform_params: virt_start=0x8000
xen_changeset  : Tue Dec 17 14:19:49 2019 + git:a2e84d8-dirty
xen_commandline: placeholder dom0_mem=2048M,max:2048M log_lvl=all
guest_loglvl=all dom0_max_vcpus=2 dom0_vcpus_pin
cc_compiler: gcc (Ubuntu 7.5.0-3ubuntu1~14.04.1) 7.5.0
cc_compile_by  : root
cc_compile_domain  :
cc_compile_date: Wed Apr 14 05:13:56 WEST 2021
build_id   : 428bb9223a72819e497d6b06a396034ab3b5280d
xend_config_format : 4





Atenciosamente,
*Charles Ferreira Gonçalves *

Re: Identify an specific DomU inpecting all pages in memory

[Charles Gonçalves]

Thanks Andrew,

I'll certainly follow your suggestion of getting used to coding into Xen
context.
I've just got started programming into Xen, and this will be crucial to my
goal.

Right now, my approach to detect a dom0 memory page is to walk across all
pages in memory and identify one that holds an unspecific start_info
struct, and then check the SIF_INITDOMAIN.
If I had a way to identify which domU this unspecific page referee to from
this data structure, it will ease the work.



Atenciosamente,
*Charles Ferreira Gonçalves *




On Mon, Jan 4, 2021 at 6:18 PM Andrew Cooper 
wrote:

> On 02/01/2021 19:20, Charles Gonçalves wrote:
> > Sure.
> >
> > The goal is to emulate a scenario where a compromised guest attacks
> > another
> > tenant in the same physical host reading/changing the memory content.
> > E.g., extract the RSA key.
> >
> > I'll be in the domU kernel space. I'm assuming that the guest is able
> > to exploit
> > any vulnerability possible.
> > Effectively I'll be changing Xen's code (at least possible) to
> > *emulate* a vulnerability
> > (e.g., undo a patch).
>
> Ok, so in this scenario, you've successfully exploited a privilege
> escalation vulnerability in Xen and obtained code execution in
> hypervisor context.  There are some security fixes to choose to revert
> for this purpose, but none I'm aware of which will make the attack
> payload trivial to pull off.
>
> However, I'd suggest that you first try writing a new hypercall to do
> what you want, so you can get used to coding in Xen context, before
> adding the complexity of trying to retrofit it into an attack payload.
>
> If you've already got code with works for dom0, I presume you're keying
> off the hardware_domain pointer?  Either way, you can look at the
> for_each_domain() construct for how to walk the domain list, or
> get_domain_by_id() for how to use the hashtable to look up a domain by
> its domid.
>
> ~Andrew
>

Re: Identify an specific DomU inpecting all pages in memory

[Charles Gonçalves]

Sure.

The goal is to emulate a scenario where a compromised guest attacks another
tenant in the same physical host reading/changing the memory content.
E.g., extract the RSA key.

I'll be in the domU kernel space. I'm assuming that the guest is able to
exploit
any vulnerability possible.
Effectively I'll be changing Xen's code (at least possible) to *emulate* a
vulnerability
(e.g., undo a patch).



Atenciosamente,
*Charles Ferreira Gonçalves *




On Sat, Jan 2, 2021 at 7:06 PM Andrew Cooper 
wrote:

> On 02/01/2021 17:02, Charles Gonçalves wrote:
> > Hi,
> >
> > I'm building some attack loads targeting  Xen to my PhD and need to
> > identify the pages for a specific guest.
> > Assuming that I'm able to traverse the pages in memory, how do I
> > identify a guest (by ID or Name)?
> >
> > The dom0 is easy since I can inspect the start_info looking
> > for SIF_INITDOMAIN but I have no idea to identify a specific domU.
>
> Hello,
>
> Could you provide rather more details about what exactly you're trying
> to do?
>
> In particular, what context are you in when trying to identify the pages?
>
> ~Andrew
>

Identify an specific DomU inpecting all pages in memory

[Charles Gonçalves]

Hi,

I'm building some attack loads targeting  Xen to my PhD and need to
identify the pages for a specific guest.
Assuming that I'm able to traverse the pages in memory, how do I identify a
guest (by ID or Name)?

The dom0 is easy since I can inspect the start_info looking for
SIF_INITDOMAIN but I have no idea to identify a specific domU.

Thanks!


Atenciosamente,
*Charles Ferreira Gonçalves *

[Xen-devel] Vulnerability disclosure vs discovery

[Charles Gonçalves]

Hello,

I'm a Ph.D. candidate in UC (Portugal) working with Xen's vulnerability
discovery process, right now focusing on modeling, and I'd like to
understand the process before the disclosure (by XSA or CVE/NVD).

It would be nice to have a more precise date that traces a vulnerability
(XSA) to its discovery rather than the public release date.

Currently,  I'm parsing any references from NVD/CVE and analyzing the
dates. For older XSA, this works better than from newer ones.

Is there any other place that I could find this information?

Atenciosamente,
*Charles Ferreira Gonçalves *

Re: [Xen-devel] domain_crash_sync vs "plain crash"

[Charles Gonçalves]

@Andrew,

Despite SCHED_OP, that I've blacklisted, which one came to mind?


On Mon, May 7, 2018 at 5:13 AM Andrew Cooper 
wrote:

> On 07/05/2018 08:09, Jan Beulich wrote:
>  On 07.05.18 at 03:06,  wrote:
> >> When I'm performing some hypercalls with some "unexpected" parameters
> >> (robustness test) sometimes the guest is explicitly  "killed" by xen
> >> calling the domain_crash(), but sometimes the guest just crash without
> any
> >> explicit message on dmesg or logs.
> >>
> >> Are those "plain crashes" an expected behavior by design on Xen or are
> they
> >> some untreated parameter checking or something else?
> > A silent crash is never supposed to happen, but you always need to first
> > consider whether the crashing component actually has a way to get
> > something out to wherever you monitor its logs. That is, without
> (physical
> > or virtual, depending on component) serial console you're often unlikely
> to
> > actually observe any messages connected to the crash.
> >
> > If you can track down a _truly_ silent crash to its origin, submitting a
> patch
> > to make it non-silent would be appreciated.
>
> Alternatively, if you are fuzzing the hypercalls, which it sounds like
> you are, then you need to ensure that you blacklist operations such as
> SCHEDOP_shutdown and SCHEDOP_poll to avoid the fuzzer hitting legitimate
> hypercalls which shut down or block for indefinite periods of time.
>
> ~Andrew
>
-- 
Atenciosamente,
Charles F.'. Gonçalves
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] domain_crash_sync vs "plain crash"

[Charles Gonçalves]

"That is, without (physical
or virtual, depending on component) serial console you're often unlikely to
actually observe any messages connected to the crash."

I do not have any experience with serial console interaction on linux.
Can you list some examples for both cases (virtual| physical), I'll glad to
fully report any suspicious problem.

Thanks!

-- 
Atenciosamente,
Charles F.'. Gonçalves
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] domain_crash_sync vs "plain crash"

[Charles Gonçalves]

When I'm performing some hypercalls with some "unexpected" parameters
(robustness test) sometimes the guest is explicitly  "killed" by xen
calling the domain_crash(), but sometimes the guest just crash without any
explicit message on dmesg or logs.

Are those "plain crashes" an expected behavior by design on Xen or are they
some untreated parameter checking or something else?

Can someone comment about it?

Thanks!


-- 
Atenciosamente,
Charles F.'. Gonçalves
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Getting Hypercall [op = 0x0040001a ] on trace 

[Charles Gonçalves]

Hello,

Im getting this Hypercall [op = 0x0040001a ] on xen trace  but can't figure
out which operation this is.

Using old Xen 4.4.1.
Looking at documentation  and also using grep into source code couldn't
figure out which hypercall this is.

Can someone help clarify this?
-- 
Atenciosamente,
Charles F.'. Gonçalves
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel