Re: [Xen-devel] [PATCH v4 5/6] tools/dm_depriv: Add first cut RLIMITs
On 11/06/2018 09:22 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of George Dunlap
>> Sent: 05 November 2018 18:07
>> To: xen-devel@lists.xenproject.org
>> Cc: Anthony Perard ; Ian Jackson
>> ; Wei Liu ; George Dunlap
>>
>> Subject: [Xen-devel] [PATCH v4 5/6] tools/dm_depriv: Add first cut RLIMITs
>>
>> Limit the ability of a potentially compromised QEMU to consume system
>> resources. Key limits:
>> - RLIMIT_FSIZE (file size): 256KiB
>> - RLIMIT_NPROC (after uid changes to a unique uid)
>>
>> Probably unnecessary limits but why not:
>> - RLIMIT_CORE: 0
>> - RLIMIT_MSGQUEUE: 0
>> - RLIMIT_LOCKS: 0
>> - RLIMIT_MEMLOCK: 0
>>
>> NB that we do not yet set RLIMIT_AS (total virtual memory) or
>> RLIMIT_NOFILES (number of open files), since these require more care
>> and/or more coordination with QEMU to implement.
>>
>> Suggested-by: Ross Lagerwall
>> Signed-off-by: George Dunlap
>> ---
>> Changes since v3:
>> - Align RLIMIT_ENTRY list for easier reading
>> - Fix wrong format string specifier
>> - Get rid of some trailing whitespace
>>
>> Changes since v2:
>> - Use a macro to define rlimit entries
>> - Use RLIMIT_NLIMITS as an end-of-list marker, rather than -1
>> - Various style clean-ups
>>
>> CC: Ian Jackson
>> CC: Wei Liu
>> CC: Anthony Perard
>> ---
>> docs/designs/qemu-deprivilege.md | 12 -
>> tools/libxl/libxl_linux.c| 42 ++--
>> 2 files changed, 46 insertions(+), 8 deletions(-)
>>
>> diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-
>> deprivilege.md
>> index a461ebbadd..e984064da6 100644
>> --- a/docs/designs/qemu-deprivilege.md
>> +++ b/docs/designs/qemu-deprivilege.md
>> @@ -105,12 +105,6 @@ call:
>>
>> [qemu-namespaces]: https://lists.gnu.org/archive/html/qemu-devel/2017-
>> 10/msg04723.html
>>
>> -# Restrictions / improvements still to do
>> -
>> -This lists potential restrictions still to do. It is meant to be
>> -listed in order of ease of implementation, with low-hanging fruit
>> -first.
>> -
>> ### Basic RLIMITs
>>
>> '''Description''': A number of limits on the resources that a given
>> @@ -137,6 +131,12 @@ are specified; this does not apply to QEMU running as
>> a Xen DM.
>>
>> '''Tested''': Not tested
>>
>> +# Restrictions / improvements still to do
>> +
>> +This lists potential restrictions still to do. It is meant to be
>> +listed in order of ease of implementation, with low-hanging fruit
>> +first.
>> +
>> ### Further RLIMITs
>>
>> RLIMIT_AS limits the total amount of memory; but this includes the
>> diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
>> index c7a345f4bb..ac9526d731 100644
>> --- a/tools/libxl/libxl_linux.c
>> +++ b/tools/libxl/libxl_linux.c
>> @@ -12,11 +12,12 @@
>> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> * GNU Lesser General Public License for more details.
>> */
>> -
>> +
>
> Stray whitespace change?
Got rid of trailing witespace; I mentioned it under "Changes since v3".
>> #include "libxl_osdeps.h" /* must come before any other headers */
>>
>> #include "libxl_internal.h"
>> -
>> +#include
>> +
>
> Personally I tend to put local includes after ones from the include path. Is
> there a reason it needs to come afterwards?
No reason; just habit to add things to the end. I'll move it earlier
unless Ian objects.
>> +static struct {
>> +int resource;
>> +rlim_t limit;
>> +} rlimits[] = {
>> +#define RLIMIT_ENTRY(r, l) \
>> +{ .resource = r, .limit = l }
>> +/* Big enough for log files, not big enough for a DoS */
>> +RLIMIT_ENTRY(RLIMIT_FSIZE,256*1024),
>> +
>> +/* Shouldn't need any of these */
>> +RLIMIT_ENTRY(RLIMIT_NPROC,0),
>> +RLIMIT_ENTRY(RLIMIT_CORE, 0),
>> +RLIMIT_ENTRY(RLIMIT_MSGQUEUE, 0),
>> +RLIMIT_ENTRY(RLIMIT_LOCKS,0),
>> +RLIMIT_ENTRY(RLIMIT_MEMLOCK, 0),
>> +
>> +/* End-of-list marker */
>> +RLIMIT_ENTRY(RLIMIT_NLIMITS, 0),
>> +};
>> +#undef RLIMIT_ENTRY
>
> The undef should come before the brace to get the scoping correct.
>
Sure.
>> +
>> int libxl__local_dm_preexec_restrict(libxl__gc *gc)
>> {
>> int r;
>> +unsigned i;
>>
>> /* Unshare mount and IPC namespaces. These are unused by QEMU. */
>> r = unshare(CLONE_NEWNS | CLONE_NEWIPC);
>> @@ -318,6 +341,21 @@ int libxl__local_dm_preexec_restrict(libxl__gc *gc)
>> return ERROR_FAIL;
>> }
>>
>> +/* Set various "easy" rlimits */
>> +for (i = 0; rlimits[i].resource != RLIMIT_NLIMITS; i++) {
>> +struct rlimit rlim;
>> +
>> +rlim.rlim_cur = rlim.rlim_max = rlimits[i].limit;
>> +
>> +r = setrlimit(rlimits[i].resource, &rlim);
>> +if (r < 0) {
>> +LOGE(ERROR, "Setting rlimit %d to %llu failed\n",
>> + rlimits[i].resource,
>> + (unsigned long long)rlimits[i].limit);
>
Re: [Xen-devel] [PATCH] docs: remove ChangeLog file
On Tue, Oct 30, 2018 at 05:10:18PM +, Wei Liu wrote: > On Fri, Oct 26, 2018 at 12:38:06PM +0200, Juergen Gross wrote: > > docs/ChangeLog has been updated for Xen 3.3 last time. It seems to be > > interesting for archaeologists only today. > > > > Remove it. > > > > Signed-off-by: Juergen Gross > > I wouldn't mind removing it. Nowadays I mostly use git to do > archaeology, so: > > Acked-by: Wei Liu > > But let's wait some time in case there is objection. No one objected so I have applied this patch. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 3/6] tools/dm_restrict: Ask QEMU to chroot
On 11/06/2018 09:14 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of George Dunlap
>> Sent: 05 November 2018 18:07
>> To: xen-devel@lists.xenproject.org
>> Cc: Anthony Perard ; Ian Jackson
>> ; Wei Liu ; George Dunlap
>>
>> Subject: [Xen-devel] [PATCH v4 3/6] tools/dm_restrict: Ask QEMU to chroot
>>
>> When dm_restrict is enabled, ask QEMU to chroot into an empty directory.
>>
>> * Create /var/run/qemu/root-domid (deleting the old one if it's there)
>
> This does not appear to match the code: the path should be
> /var/run/qemu-root- AFAICT
Indeed, I forgot to update this. I can fix this up on check-in.
>> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
>> index 26eb16af34..ad3efcc783 100644
>> --- a/tools/libxl/libxl_dm.c
>> +++ b/tools/libxl/libxl_dm.c
>> @@ -1410,9 +1410,48 @@ static int
>> libxl__build_device_model_args_new(libxl__gc *gc,
>> }
>> }
>>
>> -if (libxl_defbool_val(b_info->dm_restrict))
>> +if (libxl_defbool_val(b_info->dm_restrict)) {
>> +char *chroot_dir = GCSPRINTF("%s/qemu-root-%d",
>> + libxl__run_dir_path(),
>> guest_domid);
>> +int r;
>> +
>> flexarray_append(dm_args, "-xen-domid-restrict");
>>
>> +/*
>> + * Run QEMU in a chroot at XEN_RUN_DIR/qemu-root-%d
>
> Maybe '' in the comment rather than '%d'?
Maybe. :-)
>> + *
>> + * There is no library function to do the equivalent of `rm
>> + * -rf`. However deprivileged QEMU in theory shouldn't be
>> + * able to write any files, as the chroot would be owned by
>> + * root, but it would be running as an unprivileged process.
>> + * So in theory, old chroots should always be empty.
>
> How does logging work if QEMU can't write to the chroot? I assume we are
> relying on stderr? Does using syslog still work?
Everything QEMU needs access to (including vnc sockets, qmp sockets, &c)
must either be opened before the chroot happens, or passed to QEMU as an
fd via qmp. In the case of logging, this happens through stderr; but if
you search for 'chroot' in the design document you'll get a couple of
examples of different issues that need to be addressed (including
inserting a cd-rom and dealing with migration).
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 4/6] tools/dm_restrict: Unshare mount and IPC namespaces on Linux
On 11/06/2018 09:16 AM, Paul Durrant wrote:
>> diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
>> index 2edfb00641..dce3f1fdce 100644
>> --- a/tools/libxl/libxl_netbsd.c
>> +++ b/tools/libxl/libxl_netbsd.c
>> @@ -124,3 +124,8 @@ int libxl__pci_topology_init(libxl__gc *gc,
>> {
>> return ERROR_NI;
>> }
>> +
>> +void libxl__local_dm_preexec_restrict(libxl__gc *gc, int stderrfd)
>> +{
>> +return;
>> +}
>
> This is a void function whereas the caller always appears to expect an int
> return value, regardless of OS.
Indeed, this would probably break the build on NetBSD. Good catch.
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 03/24] hw: acpi: The RSDP build API can return void
On 05/11/2018 02:40, Samuel Ortiz wrote:
> /* RSDP */
> -static GArray *
> +static void
> build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned xsdt_tbl_offset)
> {
> AcpiRsdpDescriptor *rsdp = acpi_data_push(rsdp_table, sizeof *rsdp);
> @@ -392,8 +392,6 @@ build_rsdp(GArray *rsdp_table, BIOSLinker *linker,
> unsigned xsdt_tbl_offset)
> bios_linker_loader_add_checksum(linker, ACPI_BUILD_RSDP_FILE,
> (char *)rsdp - rsdp_table->data, sizeof *rsdp,
> (char *)&rsdp->checksum - rsdp_table->data);
> -
> -return rsdp_table;
> }
>
Better than v4. :)
Paolo
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/3] tools: ipxe: Correct download error handling
On Mon, Nov 05, 2018 at 06:42:34PM +, Ian Jackson wrote: > This shell fragment lacked set -e. So, eg if the download failed a > broken ipxe.tar.gz would be left behind. > > Signed-off-by: Ian Jackson Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/3] tools: No longer advertise GIT_HTTP env var
On Mon, Nov 05, 2018 at 06:42:33PM +, Ian Jackson wrote: > In "build: add autoconf to replace custom checks in tools/check" > --enable-githttp was introduced. But we missed this comment where it > was advertised. > > Signed-off-by: Ian Jackson Whether you squash this patch into previous one or not: Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/3] tools: Once again honour GIT_HTTP env var
On Mon, Nov 05, 2018 at 06:42:32PM +, Ian Jackson wrote: > In "build: add autoconf to replace custom checks in tools/check" > --enable-githttp was introduced. But that had the effect of > uncondtionally setting GIT_HTTP from the configure variable. > > But the env var is advertised in some places as the way to specify > this behaviour, and overriding it is just unfriendly. > > Signed-off-by: Ian Jackson Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Dom0 kernel 4.14 with SMP randomly crashing
On Mon, Nov 5, 2018 at 6:32 PM Rishi <2rushike...@gmail.com> wrote: > > > On Mon, Nov 5, 2018 at 6:29 PM Rishi <2rushike...@gmail.com> wrote: > >> Yes, I'm taking out patches from 4.4 and actually do have a working 4.9 >> kernel along with blktap. Tested networking and disk IO in it. >> >> There are roughly 415 patches to 4.4 out of which some ~210+ are already >> applied in 4.9 and ~220+ are already applied in 4.14. I dont have numbers >> for 4.19 yet. >> >> Essentially I'm down to single digit number of patches atm to have a >> working setup for kernel 4.9. I know there would be mishaps since I'm not >> applying all patches but my experiment is to see how close can we stay near >> mainline kernel + what can be the patches that kernel.org can accept. >> >> >> >> On Mon, Nov 5, 2018 at 6:19 PM Wei Liu wrote: >> >>> I forgot to say: please don't top-post. >>> >>> On Mon, Nov 05, 2018 at 06:00:10PM +0530, Rishi wrote: >>> > I'm using a XenServer Host and XCP-NG on it as HVM. I used xencons=tty >>> > console=ttyS0 on XCP-NG dom0 kernel line, to obtain serial console. >>> > I'm working on to build a more recent dom0 kernel for improved support >>> of >>> > Ceph in XenServer/XCP-NG. >>> >>> This is an interesting setup. I don't think you can expect to just drop >>> in a new kernel to XenServer/XCP-NG and then it works flawlessly. What >>> did you do to the patch queue XenServer carries for 4.4? >>> >>> Also, have you got a working baseline? I.e. did the stock 4.4 kernel >>> work? >>> >>> Wei. >>> >>> > >>> > >>> > >>> > On Mon, Nov 5, 2018 at 5:28 PM Wei Liu wrote: >>> > >>> > > On Mon, Nov 05, 2018 at 05:18:43PM +0530, Rishi wrote: >>> > > > Yes, I'm running it in a HVM domU for development purpose. >>> > > >>> > > What is your exact setup? >>> > > >>> > > Wei. >>> > > >>> > > > >>> > > > On Mon, Nov 5, 2018 at 5:11 PM Wei Liu >>> wrote: >>> > > > >>> > > > > On Mon, Nov 05, 2018 at 04:58:35PM +0530, Rishi wrote: >>> > > > > > Alright, I got the serial console and following is the crash >>> log. >>> > > Thank >>> > > > > you >>> > > > > > for pointing that out. >>> > > > > > >>> > > > > > [ 133.594852] watchdog: BUG: soft lockup - CPU#2 stuck for >>> 22s! >>> > > > > > [ksoftirqd/2:22] >>> > > > > > >>> > > > > > [ 133.599232] Kernel panic - not syncing: softlockup: hung >>> tasks >>> > > > > > >>> > > > > > [ 133.602275] CPU: 2 PID: 22 Comm: ksoftirqd/2 Tainted: G >>> > > > > > L4.19.1 >>> > > > > > #1 >>> > > > > > >>> > > > > > [ 133.606620] Hardware name: Xen HVM domU, BIOS 4.4.1-xs132257 >>> > > > > 12/12/2016 >>> > > > > >>> > > > > Is this serial log from the host? It says it is running as a HVM >>> DomU. >>> > > > > Maybe you have mistaken guest serial log with host serial log? >>> > > > > >>> > > > > This indicates your machine runs XenServer, which has its own >>> patch >>> > > > > queues on top of upstream Xen. You may also want to report to >>> xs-devel >>> > > > > mailing list. >>> > > > > >>> > > > > Wei. >>> > > > > >>> > > >>> >> > > Sorry, I'll take care of top post from onwards. > So after knowing the stack trace, it appears that the CPU was getting stuck for xen_hypercall_xen_version watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [swapper/0:0] [30569.582740] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [swapper/0:0] [30569.588186] Kernel panic - not syncing: softlockup: hung tasks [30569.591307] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G L4.19.1 #1 [30569.595110] Hardware name: Xen HVM domU, BIOS 4.4.1-xs132257 12/12/2016 [30569.598356] Call Trace: [30569.599597] [30569.600920] dump_stack+0x5a/0x73 [30569.602998] panic+0xe8/0x249 [30569.604806] watchdog_timer_fn+0x200/0x230 [30569.607029] ? softlockup_fn+0x40/0x40 [30569.609246] __hrtimer_run_queues+0x133/0x270 [30569.611712] hrtimer_interrupt+0xfb/0x260 [30569.613800] xen_timer_interrupt+0x1b/0x30 [30569.616972] __handle_irq_event_percpu+0x69/0x1a0 [30569.619831] handle_irq_event_percpu+0x30/0x70 [30569.622382] handle_percpu_irq+0x34/0x50 [30569.625048] generic_handle_irq+0x1e/0x30 [30569.627216] __evtchn_fifo_handle_events+0x163/0x1a0 [30569.629955] __xen_evtchn_do_upcall+0x41/0x70 [30569.632612] xen_evtchn_do_upcall+0x27/0x50 [30569.635136] xen_do_hypervisor_callback+0x29/0x40 [30569.638181] RIP: e030:xen_hypercall_xen_version+0xa/0x20 [30569.641302] Code: 51 41 53 b8 10 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 11 00 00 00 0f 05 <41> 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc [30569.651998] RSP: e02b:8800b6203e10 EFLAGS: 0246 [30569.655077] RAX: 00040007 RBX: 8800ae41a898 RCX: 8100122a [30569.659226] RDX: c900400080ff RSI: RDI: [30569.663480] RBP: 8800ae41a890 R08: R09: [30569.667943] R10: R11: 0246 R12: 8600 [30569.672057] R13: 001
Re: [Xen-devel] [PATCH 8/8] tools/libvchan: libxenvchan_client_init: use ENOENT for no server
On Fri, Nov 02, 2018 at 05:01:13PM +, Ian Jackson wrote: > * Promise that we will set errno to ENOENT if the server is not > yet set up. > * Arrange that all ENOENT returns other than from the read of ring-ref > are turned into EIO, logging when we do so. This sounds reasonable to me, but I would like to hear from Marek that this doesn't break Qubes. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 7/8] tools/libvchan: libxenvchan_*_init: Promise an errno
On Fri, Nov 02, 2018 at 05:01:12PM +, Ian Jackson wrote: > Thse functiosn do in fact leave errno set. We are going to want to > use this. > > Signed-off-by: Ian Jackson Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 6/8] tools/libvchan: Add xentoollog to direct dependencies
On Fri, Nov 02, 2018 at 05:01:11PM +, Ian Jackson wrote: > We are going to add a call to xtl_log. > > Signed-off-by: Ian Jackson Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 4/8] tools/libvchan: init_xs_srv: Simplify error handling (2)
On Fri, Nov 02, 2018 at 05:01:09PM +, Ian Jackson wrote: > * Abolish fail_xs_open which is now exactly the same as fail. > > * Change all gotos to refer to fail instead. > > No functional change. > Oh here it is. > Signed-off-by: Ian Jackson Acked-by: Wei Liu Feel free to add my ack to your previous patch. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 5/8] tools/libvchan: init_xs_srv: Turn xs retry from goto into for (; ; )
On Fri, Nov 02, 2018 at 05:01:10PM +, Ian Jackson wrote: > No functional change. > > Signed-off-by: Ian Jackson Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/8] tools/libvchan: init_xs_srv: Simplify error handling (1)
On Fri, Nov 02, 2018 at 05:01:08PM +, Ian Jackson wrote:
> * Use xs_close instead of the deprecated xs_daemon_close.
>
> * Initialise xs to NULL.That means xs_close can now be called in
> all cases. Move it to the fail clause.
>
> * free(domid_str) is already safe in all cases since domid_str is
> initialised to NULL. Move it to the fail clause.
>
> No overall functional change: xs_close is the same as xs_daemon_close;
> and it and free are now sometimes called on NULL, but those are no-ops.
>
> Signed-off-by: Ian Jackson
> ---
> tools/libvchan/init.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c
> index 180833dc2f..9c61c720d1 100644
> --- a/tools/libvchan/init.c
> +++ b/tools/libvchan/init.c
> @@ -245,7 +245,7 @@ fail:
> static int init_xs_srv(struct libxenvchan *ctrl, int domain, const char*
> xs_base, int ring_ref)
> {
> int ret = -1;
> - struct xs_handle *xs;
> + struct xs_handle *xs = NULL;
> struct xs_permissions perms[2];
> char buf[64];
> char ref[16];
> @@ -292,9 +292,9 @@ retry_transaction:
> ret = 0;
> }
> fail_xs_open:
This label can be deleted now.
> - free(domid_str);
> - xs_daemon_close(xs);
> fail:
> + free(domid_str);
> + xs_close(xs);
> return ret;
> }
>
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/8] tools/xenstore: Document that xs_close(0) is OK.
On Fri, Nov 02, 2018 at 05:01:07PM +, Ian Jackson wrote: > Signed-off-by: Ian Jackson Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/8] tools/libvchan: Initialise xs_transaction_t to XBT_NULL, not NULL
On Fri, Nov 02, 2018 at 05:01:06PM +, Ian Jackson wrote: > This is an integer type, not a pointer. > > Signed-off-by: Ian Jackson Good catch. Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xen-blkfront: fix kernel panic with negotiate_mq error path
On 30/10/2018 17:49, Manjunath Patil wrote:
> info->nr_rings isn't adjusted in case of ENOMEM error from
> negotiate_mq(). This leads to kernel panic in error path.
>
> Typical call stack involving panic -
> #8 page_fault at 8175936f
> [exception RIP: blkif_free_ring+33]
> RIP: a0149491 RSP: 8804f7673c08 RFLAGS: 00010292
> ...
> #9 blkif_free at a0149aaa [xen_blkfront]
> #10 talk_to_blkback at a014c8cd [xen_blkfront]
> #11 blkback_changed at a014ea8b [xen_blkfront]
> #12 xenbus_otherend_changed at 81424670
> #13 backend_changed at 81426dc3
> #14 xenwatch_thread at 81422f29
> #15 kthread at 810abe6a
> #16 ret_from_fork at 81754078
>
> Cc: sta...@vger.kernel.org
> Fixes: 7ed8ce1c5fc7 ("xen-blkfront: move negotiate_mq to cover all cases of
> new VBDs")
> Signed-off-by: Manjunath Patil
Pushed to xen.git for-linus-4.20a
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/grant-table: Fix incorrect gnttab_dma_free_pages() pr_debug message
On 02/11/2018 15:04, Liam Merwick wrote:
> If a call to xenmem_reservation_increase() in gnttab_dma_free_pages()
> fails it triggers a message "Failed to decrease reservation..." which
> should be "Failed to increase reservation..."
>
> Fixes: 9bdc7304f536 ('xen/grant-table: Allow allocating buffers suitable for
> DMA')
> Reported-by: Ross Philipson
> Signed-off-by: Liam Merwick
> Reviewed-by: Mark Kanda
Pushed to xen.git for-linus-4.20a
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] CONFIG_XEN_PV breaks xen_create_contiguous_region on ARM
On 01/11/2018 00:11, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> xen_create_contiguous_region has now only an implementation if
> CONFIG_XEN_PV is defined. However, on ARM we never set CONFIG_XEN_PV but
> we do have an implementation of xen_create_contiguous_region which is
> required for swiotlb-xen to work correctly (although it just sets
> *dma_handle).
>
> Fixes: 16624390816c ("xen: create xen_create/destroy_contiguous_region()
> stubs for PVHVM only builds")
> Signed-off-by: Stefano Stabellini
Pushed to xen.git for-linus-4.20a
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 6/6] RFC: test/depriv: Add a tool to check process-level depriv
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of George Dunlap
> Sent: 05 November 2018 18:07
> To: xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Wei Liu
> ; George Dunlap ; Ross
> Lagerwall ; Anthony Perard
> ; Ian Jackson
> Subject: [Xen-devel] [PATCH v4 6/6] RFC: test/depriv: Add a tool to check
> process-level depriv
>
> Add a tool to check whether the various process-level deprivileging
> operations have actually taken place on the process.
>
> The tool takes a domname or domid, and returns success or failure.
>
> Signed-off-by: George Dunlap
> ---
> Changes since v3:
> - Use xen-qemuuser-range-base's gid rather than hard-coding `nobody`
> - Change FIXME about not handling other userid schemes into an NB.
>
> Changes since v2:
> - Make grep for Uid line more strict
> - Fix Gid grep, make more strict
> - Match strictly more than one space
> - Look up the group ID for `nobody` rather than hard-coding it
> - Move tests from other patches into one patch
> - Remove suffix (in case we change the language)
> - Install in the path
>
> NB this patch is included for reference only, while I consider whether
> to leave this as a stand-alone script, or whether to merge osstest's
> fd checker functionality into it (perhaps changing the language to
> perl at the same time). Reviews of the general detection algorithm
> are welcome, but there's no need for a detailed review of the code
> until the script is in its final form.
>
> CC: Ian Jackson
> CC: Wei Liu
> CC: Stefano Stabellini
> CC: Anthony Perard
> CC: Ross Lagerwall
> ---
> tools/tests/depriv/Makefile | 2 +-
> tools/tests/depriv/depriv-process-checker | 148 ++
> 2 files changed, 149 insertions(+), 1 deletion(-)
> create mode 100755 tools/tests/depriv/depriv-process-checker
>
> diff --git a/tools/tests/depriv/Makefile b/tools/tests/depriv/Makefile
> index 3cba28da25..1b3d09e97d 100644
> --- a/tools/tests/depriv/Makefile
> +++ b/tools/tests/depriv/Makefile
> @@ -23,7 +23,7 @@ LDLIBS += $(LDLIBS_libxendevicemodel)
> LDLIBS += $(LDLIBS_libxentoolcore)
> LDLIBS += $(LDLIBS_libxentoollog)
>
> -INSTALL_PRIVBIN-y += depriv-fd-checker
> +INSTALL_PRIVBIN-y += depriv-fd-checker depriv-process-checker
> INSTALL_PRIVBIN := $(INSTALL_PRIVBIN-y)
> TARGETS += $(INSTALL_PRIVBIN)
>
> diff --git a/tools/tests/depriv/depriv-process-checker
> b/tools/tests/depriv/depriv-process-checker
> new file mode 100755
> index 00..4f9f0d7fbc
> --- /dev/null
> +++ b/tools/tests/depriv/depriv-process-checker
> @@ -0,0 +1,148 @@
> +#!/bin/bash
> +
> +domain="$1"
> +
> +if [[ "$domain" =~ ^[0-9]+$ ]] ; then
> +domid="$domain"
> +else
> +domid=$(xl domid "$domain")
> +fi
> +
> +dmpid=$(xenstore-read /local/domain/$domid/image/device-model-pid
> 2>/dev/null)
> +if [[ -z "$dmpid" ]] ; then
> +echo "xenstore-read failed"
> +exit 1
> +fi
> +
> +failed="false"
> +
> +# TEST: Process / group id
> +#
> +# Read /proc//status, checking Uid and Gid lines
> +#
> +# Uid should be xen-qemuuser-range-base+$domid
> +# Gid should be gid for xen-qemuuser-range-base
> +#
> +# NB this doesn't handle other configurations (e.g.,
> +# xen-qemuuser-shared).
> +echo -n "Process UID: "
> +tgt_uid=$(id -u xen-qemuuser-range-base)
> +tgt_uid=$(( $tgt_uid + $domid ))
> +
> +# Example input:
> +# Uid: 1193119311931193
> +input=$(grep ^Uid: /proc/$dmpid/status)
> +if [[ "$input" =~ ^Uid:[[:space:]]+([0-9]+)[[:space:]]+([0-
> 9]+)[[:space:]]+([0-9]+)[[:space:]]+([0-9]+)$ ]] ; then
> +result="PASSED"
> +for i in {1..4}; do
> + if [[ "${BASH_REMATCH[$i]}" != "$tgt_uid" ]] ; then
> + result="FAILED"
> + failed="true"
This patter occurs many times. Could you not just have a boolean 'failed' value
and a supporting 'reason' (which might be empty) then you can just test
'reason' at the end to decide what to echo?
> + break
> + fi
> +done
> +else
> +result="FAILED"
> +failed="true"
> +fi
> +echo $result
> +
> +# Example input:
> +# Gid: 10020 10020 10020 10020
> +echo -n "Process GID: "
> +tgt_gid=$(id -g xen-qemuuser-range-base)
> +input=$(grep ^Gid: /proc/$dmpid/status)
> +if [[ "$input" =~ ^Gid:[[:space:]]+([0-9]+)[[:space:]]+([0-
> 9]+)[[:space:]]+([0-9]+)[[:space:]]+([0-9]+)$ ]] ; then
> +result="PASSED"
> +for i in {1..4}; do
> + if [[ "${BASH_REMATCH[$i]}" != "$tgt_gid" ]] ; then
> + result="FAILED"
> + failed="true"
> + break
> + fi
> +done
> +else
> +result="FAILED"
> +failed="true"
> +fi
> +echo $result
> +
> +# TEST: chroot
> +#
> +# Read /proc//root to see if it's correct.
> +echo -n "Chroot: "
> +if [[ -n "$XEN_RUN_DIR" ]] ; then
> +tgt_chroot=$XEN_RUN_DIR/qemu-root-$domid
> +root=$(readlink /proc/$dmpid/root)
> +if [[ "$root" != "$tgt_chroot" ]] ; then
> + echo "FAILED"
You are using hard tabs here but 4 spaces i
Re: [Xen-devel] [OSSTEST PATCH] ts-xen-build: Force reliance on ipxe tarball
On Mon, Nov 05, 2018 at 06:35:54PM +, Ian Jackson wrote: > xen.git/tools/firmware/etherboot/Makefile tries to get a tarball from > xen-extfiles first and if that fails, tries cloning from ipxe.org. > > ipxe.org is sometimes down (or half-down) and when that happens > without a tarball the build breaks and is hard to fix. > > We would like, therefore, to ensure that the tarball is always made > before the commit which refers to it is in xen.git#master. > > osstest has no knowledge of ipxe as a separate thing and just lets > xen.git have whatever version is in Config.mk. So osstest never needs > to specify particular ipxe version by hash, or the like. > > So simply make osstest rely on the tarball existing, by having it > specify a completely invalid URL for the git clone. This will detect > attempts to update IPXE_GIT_TAG without making a corresponding > tarball. > Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 5/6] tools/dm_depriv: Add first cut RLIMITs
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of George Dunlap
> Sent: 05 November 2018 18:07
> To: xen-devel@lists.xenproject.org
> Cc: Anthony Perard ; Ian Jackson
> ; Wei Liu ; George Dunlap
>
> Subject: [Xen-devel] [PATCH v4 5/6] tools/dm_depriv: Add first cut RLIMITs
>
> Limit the ability of a potentially compromised QEMU to consume system
> resources. Key limits:
> - RLIMIT_FSIZE (file size): 256KiB
> - RLIMIT_NPROC (after uid changes to a unique uid)
>
> Probably unnecessary limits but why not:
> - RLIMIT_CORE: 0
> - RLIMIT_MSGQUEUE: 0
> - RLIMIT_LOCKS: 0
> - RLIMIT_MEMLOCK: 0
>
> NB that we do not yet set RLIMIT_AS (total virtual memory) or
> RLIMIT_NOFILES (number of open files), since these require more care
> and/or more coordination with QEMU to implement.
>
> Suggested-by: Ross Lagerwall
> Signed-off-by: George Dunlap
> ---
> Changes since v3:
> - Align RLIMIT_ENTRY list for easier reading
> - Fix wrong format string specifier
> - Get rid of some trailing whitespace
>
> Changes since v2:
> - Use a macro to define rlimit entries
> - Use RLIMIT_NLIMITS as an end-of-list marker, rather than -1
> - Various style clean-ups
>
> CC: Ian Jackson
> CC: Wei Liu
> CC: Anthony Perard
> ---
> docs/designs/qemu-deprivilege.md | 12 -
> tools/libxl/libxl_linux.c| 42 ++--
> 2 files changed, 46 insertions(+), 8 deletions(-)
>
> diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-
> deprivilege.md
> index a461ebbadd..e984064da6 100644
> --- a/docs/designs/qemu-deprivilege.md
> +++ b/docs/designs/qemu-deprivilege.md
> @@ -105,12 +105,6 @@ call:
>
> [qemu-namespaces]: https://lists.gnu.org/archive/html/qemu-devel/2017-
> 10/msg04723.html
>
> -# Restrictions / improvements still to do
> -
> -This lists potential restrictions still to do. It is meant to be
> -listed in order of ease of implementation, with low-hanging fruit
> -first.
> -
> ### Basic RLIMITs
>
> '''Description''': A number of limits on the resources that a given
> @@ -137,6 +131,12 @@ are specified; this does not apply to QEMU running as
> a Xen DM.
>
> '''Tested''': Not tested
>
> +# Restrictions / improvements still to do
> +
> +This lists potential restrictions still to do. It is meant to be
> +listed in order of ease of implementation, with low-hanging fruit
> +first.
> +
> ### Further RLIMITs
>
> RLIMIT_AS limits the total amount of memory; but this includes the
> diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
> index c7a345f4bb..ac9526d731 100644
> --- a/tools/libxl/libxl_linux.c
> +++ b/tools/libxl/libxl_linux.c
> @@ -12,11 +12,12 @@
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> * GNU Lesser General Public License for more details.
> */
> -
> +
Stray whitespace change?
> #include "libxl_osdeps.h" /* must come before any other headers */
>
> #include "libxl_internal.h"
> -
> +#include
> +
Personally I tend to put local includes after ones from the include path. Is
there a reason it needs to come afterwards?
> int libxl__try_phy_backend(mode_t st_mode)
> {
> if (S_ISBLK(st_mode) || S_ISREG(st_mode)) {
> @@ -307,9 +308,31 @@ int libxl__pci_topology_init(libxl__gc *gc,
> return err;
> }
>
> +static struct {
> +int resource;
> +rlim_t limit;
> +} rlimits[] = {
> +#define RLIMIT_ENTRY(r, l) \
> +{ .resource = r, .limit = l }
> +/* Big enough for log files, not big enough for a DoS */
> +RLIMIT_ENTRY(RLIMIT_FSIZE,256*1024),
> +
> +/* Shouldn't need any of these */
> +RLIMIT_ENTRY(RLIMIT_NPROC,0),
> +RLIMIT_ENTRY(RLIMIT_CORE, 0),
> +RLIMIT_ENTRY(RLIMIT_MSGQUEUE, 0),
> +RLIMIT_ENTRY(RLIMIT_LOCKS,0),
> +RLIMIT_ENTRY(RLIMIT_MEMLOCK, 0),
> +
> +/* End-of-list marker */
> +RLIMIT_ENTRY(RLIMIT_NLIMITS, 0),
> +};
> +#undef RLIMIT_ENTRY
The undef should come before the brace to get the scoping correct.
> +
> int libxl__local_dm_preexec_restrict(libxl__gc *gc)
> {
> int r;
> +unsigned i;
>
> /* Unshare mount and IPC namespaces. These are unused by QEMU. */
> r = unshare(CLONE_NEWNS | CLONE_NEWIPC);
> @@ -318,6 +341,21 @@ int libxl__local_dm_preexec_restrict(libxl__gc *gc)
> return ERROR_FAIL;
> }
>
> +/* Set various "easy" rlimits */
> +for (i = 0; rlimits[i].resource != RLIMIT_NLIMITS; i++) {
> +struct rlimit rlim;
> +
> +rlim.rlim_cur = rlim.rlim_max = rlimits[i].limit;
> +
> +r = setrlimit(rlimits[i].resource, &rlim);
> +if (r < 0) {
> +LOGE(ERROR, "Setting rlimit %d to %llu failed\n",
> + rlimits[i].resource,
> + (unsigned long long)rlimits[i].limit);
Indentation of the continuation lines looks odd (although libxl's coding style
is a mystery to me so they may be correct).
Paul
> +return ER
Re: [Xen-devel] [PATCH v4 4/6] tools/dm_restrict: Unshare mount and IPC namespaces on Linux
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of George Dunlap
> Sent: 05 November 2018 18:07
> To: xen-devel@lists.xenproject.org
> Cc: Anthony Perard ; Ian Jackson
> ; Wei Liu ; George Dunlap
>
> Subject: [Xen-devel] [PATCH v4 4/6] tools/dm_restrict: Unshare mount and
> IPC namespaces on Linux
>
> QEMU running under Xen doesn't need mount or IPC functionality.
> Create and enter separate namespaces for each of these before
> executing QEMU, so that in the event that other restrictions fail, the
> process won't be able to even name system mount points or exsting
> non-file-based IPC descriptors to attempt to attack them.
>
> Unsharing is something a process can only do to itself (it would
> seem); so add an os-specific "dm_preexec_restrict()" hook just before
> we exec() the device model.
>
> Also add checks to depriv-process-checker.sh to verify that dm is
> running in a new namespace (or at least, a different one than the
> caller).
>
> Suggested-by: Ross Lagerwall
> Signed-off-by: George Dunlap
> Acked-by: Ian Jackson
> ---
> Changes since v3:
> - Fix some more style issues
>
> Changes since v2:
> - Return an error rather than calling exit()
> - Use LOGE() and print to the current stderr fd, rather than
> printing to the new stderr fd via write()
> - Use r for external return values rather than rc.
>
> CC: Ian Jackson
> CC: Wei Liu
> CC: Anthony Perard
> ---
> docs/designs/qemu-deprivilege.md | 12 ++--
> tools/libxl/libxl_dm.c | 5 +
> tools/libxl/libxl_freebsd.c | 5 +
> tools/libxl/libxl_internal.h | 5 +
> tools/libxl/libxl_linux.c| 14 ++
> tools/libxl/libxl_netbsd.c | 5 +
> 6 files changed, 40 insertions(+), 6 deletions(-)
>
> diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-
> deprivilege.md
> index 039540..a461ebbadd 100644
> --- a/docs/designs/qemu-deprivilege.md
> +++ b/docs/designs/qemu-deprivilege.md
> @@ -78,12 +78,6 @@ Then adds the following to the qemu command-line:
>
> '''Tested''': Not tested
>
> -## Restrictions / improvements still to do
> -
> -This lists potential restrictions still to do. It is meant to be
> -listed in order of ease of implementation, with low-hanging fruit
> -first.
> -
> ## Namespaces for unused functionality (Linux only)
>
> '''Description''': QEMU doesn't use the functionality associated with
> @@ -111,6 +105,12 @@ call:
>
> [qemu-namespaces]: https://lists.gnu.org/archive/html/qemu-devel/2017-
> 10/msg04723.html
>
> +# Restrictions / improvements still to do
> +
> +This lists potential restrictions still to do. It is meant to be
> +listed in order of ease of implementation, with low-hanging fruit
> +first.
> +
> ### Basic RLIMITs
>
> '''Description''': A number of limits on the resources that a given
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index ad3efcc783..278cfd6e6e 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -2393,6 +2393,11 @@ retry_transaction:
> goto out_close;
> if (!rc) { /* inner child */
> setsid();
> +if (libxl_defbool_val(b_info->dm_restrict)) {
> +rc = libxl__local_dm_preexec_restrict(gc);
> +if (rc)
> +_exit(-1);
> +}
> libxl__exec(gc, null, logfile_w, logfile_w, dm, args, envs);
> }
>
> diff --git a/tools/libxl/libxl_freebsd.c b/tools/libxl/libxl_freebsd.c
> index 6442ccec72..f7ef4a8910 100644
> --- a/tools/libxl/libxl_freebsd.c
> +++ b/tools/libxl/libxl_freebsd.c
> @@ -245,3 +245,8 @@ int libxl__pci_topology_init(libxl__gc *gc,
> {
> return ERROR_NI;
> }
> +
> +int libxl__local_dm_preexec_restrict(libxl__gc *gc)
> +{
> +return 0;
> +}
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index ff889385fe..e498435e16 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -3774,6 +3774,11 @@ struct libxl__dm_spawn_state {
>
> _hidden void libxl__spawn_local_dm(libxl__egc *egc,
> libxl__dm_spawn_state*);
>
> +/*
> + * Called after forking but before executing the local devicemodel.
> + */
> +_hidden int libxl__local_dm_preexec_restrict(libxl__gc *gc);
> +
> /* Stubdom device models. */
>
> typedef struct {
> diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
> index 6ef0abc693..c7a345f4bb 100644
> --- a/tools/libxl/libxl_linux.c
> +++ b/tools/libxl/libxl_linux.c
> @@ -307,6 +307,20 @@ int libxl__pci_topology_init(libxl__gc *gc,
> return err;
> }
>
> +int libxl__local_dm_preexec_restrict(libxl__gc *gc)
> +{
> +int r;
> +
> +/* Unshare mount and IPC namespaces. These are unused by QEMU. */
> +r = unshare(CLONE_NEWNS | CLONE_NEWIPC);
> +if (r) {
> +LOGE(ERROR, "libxl: Mount and IPC namespace unfailed");
> +return ERROR_FAIL;
> +}
> +
> +return 0;
> +}
> +
> /*
> * Local variables:
>
Re: [Xen-devel] [PATCH v4 3/6] tools/dm_restrict: Ask QEMU to chroot
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of George Dunlap
> Sent: 05 November 2018 18:07
> To: xen-devel@lists.xenproject.org
> Cc: Anthony Perard ; Ian Jackson
> ; Wei Liu ; George Dunlap
>
> Subject: [Xen-devel] [PATCH v4 3/6] tools/dm_restrict: Ask QEMU to chroot
>
> When dm_restrict is enabled, ask QEMU to chroot into an empty directory.
>
> * Create /var/run/qemu/root-domid (deleting the old one if it's there)
This does not appear to match the code: the path should be
/var/run/qemu-root- AFAICT
> * Pass the -chroot option to QEMU
>
> Rather than running `rm -rf` on the directory before creating it
> (since there is no library function to do this), simply rmdir the
> directory, relying on the fact that the previous QEMU instance, if
> properly restricted, shouldn't have been able to write anything
> anyway.
>
> Suggested-by: Ross Lagerwall
> Signed-off-by: George Dunlap
> Acked-by: Ian Jackson
> ---
> Changes since v2:
> - Style fixes
> - Testing moved to a different patch
>
> CC: Ian Jackson
> CC: Wei Liu
> CC: Anthony Perard
> ---
> docs/designs/qemu-deprivilege.md | 12 +-
> tools/libxl/libxl_dm.c | 41 +++-
> 2 files changed, 46 insertions(+), 7 deletions(-)
>
> diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-
> deprivilege.md
> index 787ae1ac7c..039540 100644
> --- a/docs/designs/qemu-deprivilege.md
> +++ b/docs/designs/qemu-deprivilege.md
> @@ -61,12 +61,6 @@ source tree.)
>
> '''Testing status''': Tested
>
> -# Restrictions / improvements still to do
> -
> -This lists potential restrictions still to do. It is meant to be
> -listed in order of ease of implementation, with low-hanging fruit
> -first.
> -
> ## Chroot
>
> '''Description''': Qemu runs in its own chroot, such that even if it
> @@ -84,6 +78,12 @@ Then adds the following to the qemu command-line:
>
> '''Tested''': Not tested
>
> +## Restrictions / improvements still to do
> +
> +This lists potential restrictions still to do. It is meant to be
> +listed in order of ease of implementation, with low-hanging fruit
> +first.
> +
> ## Namespaces for unused functionality (Linux only)
>
> '''Description''': QEMU doesn't use the functionality associated with
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 26eb16af34..ad3efcc783 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -1410,9 +1410,48 @@ static int
> libxl__build_device_model_args_new(libxl__gc *gc,
> }
> }
>
> -if (libxl_defbool_val(b_info->dm_restrict))
> +if (libxl_defbool_val(b_info->dm_restrict)) {
> +char *chroot_dir = GCSPRINTF("%s/qemu-root-%d",
> + libxl__run_dir_path(),
> guest_domid);
> +int r;
> +
> flexarray_append(dm_args, "-xen-domid-restrict");
>
> +/*
> + * Run QEMU in a chroot at XEN_RUN_DIR/qemu-root-%d
Maybe '' in the comment rather than '%d'?
> + *
> + * There is no library function to do the equivalent of `rm
> + * -rf`. However deprivileged QEMU in theory shouldn't be
> + * able to write any files, as the chroot would be owned by
> + * root, but it would be running as an unprivileged process.
> + * So in theory, old chroots should always be empty.
How does logging work if QEMU can't write to the chroot? I assume we are
relying on stderr? Does using syslog still work?
Paul
> + *
> + * rmdir the directory before attempting to create
> + * it; if it returns anything other than ENOENT, fail domain
> + * creation.
> + */
> +r = rmdir(chroot_dir);
> +if (r != 0 && errno != ENOENT) {
> +LOGED(ERROR, guest_domid,
> + "failed to remove existing chroot dir %s", chroot_dir);
> +return ERROR_FAIL;
> +}
> +
> +for (;;) {
> +r = mkdir(chroot_dir, );
> +if (!r)
> +break;
> +if (errno == EINTR) continue;
> +LOGED(ERROR, guest_domid,
> + "failed to create chroot dir %s", chroot_dir);
> +return ERROR_FAIL;
> +}
> +
> +/* Add "-chroot [dir]" to command-line */
> +flexarray_append(dm_args, "-chroot");
> +flexarray_append(dm_args, chroot_dir);
> +}
> +
> if (state->saved_state) {
> /* This file descriptor is meant to be used by QEMU */
> *dm_state_fd = open(state->saved_state, O_RDONLY);
> --
> 2.19.1
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 2/6] SUPPORT.md: Add qemu-depriv section
> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of George Dunlap > Sent: 05 November 2018 18:07 > To: xen-devel@lists.xenproject.org > Cc: Stefano Stabellini ; Wei Liu > ; Konrad Wilk ; Andrew Cooper > ; Tim (Xen.org) ; George Dunlap > ; Ross Lagerwall ; > Julien Grall ; Jan Beulich ; > Anthony Perard ; Ian Jackson > > Subject: [Xen-devel] [PATCH v4 2/6] SUPPORT.md: Add qemu-depriv section > > Signed-off-by: George Dunlap > --- > Changes since v3: > - Moved from the qemu-depriv doc patches. > - Reword to include the possibility of having a non-dom0 "devicemodel" > domain which may want to be protected > - Specify `Linux dom0` as the currently-tech-supported window > > CC: Ian Jackson > CC: Wei Liu > CC: Andrew Cooper > CC: Jan Beulich > CC: Tim Deegan > CC: Konrad Wilk > CC: Stefano Stabellini > CC: Julien Grall > CC: Anthony Perard > CC: Ross Lagerwall > --- > SUPPORT.md | 20 > 1 file changed, 20 insertions(+) > > diff --git a/SUPPORT.md b/SUPPORT.md > index 4f203da84a..1f0f5857a7 100644 > --- a/SUPPORT.md > +++ b/SUPPORT.md > @@ -525,6 +525,26 @@ Vulnerabilities of a device model stub domain > to a hostile driver domain (either compromised or untrusted) > are excluded from security support. > > +### Device Model Deprivileging > + > +Status, Linux dom0: Tech Preview, with limited support > + > +This means adding extra restrictions to a device model in order to > +prevent a compromised device model from attack the rest of the domain s/attack/attacking/ Paul > +it's running in (normally dom0). > + > +"Tech preview with limited support" means we will not issue XSAs for > +the _additional_ functionality provided by the feature; but we will > +issue XSAs in the event that enabling this feature opens up a security > +hole that would not be present without the feature disabled. > + > +For example, while this is classified as tech preview, a bug in libxl > +which failed to change the user ID of QEMU would not receive an XSA, > +since without this feature the user ID wouldn't be changed. But a > +change which made it possible for a compromised guest to read > +arbitrary files on the host filesystem without compromising QEMU would > +be issued an XSA, since that does weaken security. > + > ### KCONFIG Expert > > Status: Experimental > -- > 2.19.1 > > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 1/6] docs/qemu-deprivilege: Revise and update with status and future plans
> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of George Dunlap > Sent: 05 November 2018 18:07 > To: xen-devel@lists.xenproject.org > Cc: Stefano Stabellini ; Wei Liu > ; Konrad Wilk ; Andrew Cooper > ; Tim (Xen.org) ; George Dunlap > ; Ross Lagerwall ; > Julien Grall ; Jan Beulich ; > Anthony Perard ; Ian Jackson > > Subject: [Xen-devel] [PATCH v4 1/6] docs/qemu-deprivilege: Revise and > update with status and future plans > > docs/qemu-deprivilege.txt had some basic instructions for using > dm_restrict, but it was incomplete, misleading, and stale. > > Update the docs in a number of ways. > > First, separate user-facing documentation and technical description > into docs/features and docs/design, respectively. > > In the feature doc: > > * Introduce a section mentioning minimim versions of Linux, Xen, and > qemu required (TBD) > > * Fix the discussion of qemu userid. Mention xen-qemuuser-range-base, > and provide example shell code that actually has some hope of working > (instead of failing out after creating 900 userids). > > * Describe how to enable restrictions, as well as features which > probably don't or definitely don't work. > > In the design doc, introduce a "Technical Details" section which > describes specifically what restrictions are currently done, and also > what restrictions we are looking at doing in the future. > > The idea here is that as we implement the various items for the > future, we move them from "Restrictions still to do" to "Restrictions > done". This can also act as a design document -- a place for public > discussion of what can or should be done and how. > > Also add an entry to SUPPORT.md. > > Signed-off-by: George Dunlap > --- > Changes since v3: > - Fix typo (32->16) > - Use an example value not close to the `nobody` uids, but still a > multiple of 2^16. > - Mention that using a multiple of 2^16 may have advantages. > - Have the example create a group as well > - Reorganize two comments on the "range-base" method for clarity > > Changes since v2: > - Extraneous privcmd / evtchn instances aren't closed > - Expand description of how to test fd deprivileging > - Rework and clarify two namespace sections, give reference for QEMU NAK > - Add more information about migration technical challenges > - In UID section, mention possibility of container ID collisions. > - Fix name of design document. > - Add SUPPORT.md statement. Specify Linux, to make sure that FreeBSD is > evaluated separately. > - Mention that `-sandbox` is a blacklist and why > > Changes since v1: > - Break into two, and move into appropriate directories (rather than > 'misc') > - Updated version requirements > - Distinguish between features which "don't yet work" and features which > we never expect to work > - Update description of xen-restrict functionality > - Reorder and expand further restrictions > - Make it more clear which restrictions are available on Linux only > - Include detailed description of how to kill a process > - Add RLIMIT_NPROC as something we can do without further changes to qemu > - Document the need to check for the sandbox feature before using it > > Thank you to Ross Lagerwall, whose description of what XenServer is > doing formed much of the basis for the text here. > > CC: Ian Jackson > CC: Wei Liu > CC: Andrew Cooper > CC: Jan Beulich > CC: Tim Deegan > CC: Konrad Wilk > CC: Stefano Stabellini > CC: Julien Grall > CC: Anthony Perard > CC: Ross Lagerwall > --- > docs/designs/qemu-deprivilege.md | 322 ++ > docs/features/qemu-deprivilege.pandoc | 101 > docs/misc/qemu-deprivilege.txt| 36 --- > 3 files changed, 423 insertions(+), 36 deletions(-) > create mode 100644 docs/designs/qemu-deprivilege.md > create mode 100644 docs/features/qemu-deprivilege.pandoc > delete mode 100644 docs/misc/qemu-deprivilege.txt > > diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu- > deprivilege.md > new file mode 100644 > index 00..787ae1ac7c > --- /dev/null > +++ b/docs/designs/qemu-deprivilege.md > @@ -0,0 +1,322 @@ > +# Introduction > + > +The goal of deprilvileging qemu is this: Even if there is a bug (for > +example in qemu) which permits a domain to gain control of the device > +model, the compromised device model process is prevented from > +violating the system's overall security properties. Ie, a guest > +cannot "escape" from the virtualisation by using a qemu bug. > + > +This document lists the various technical measures which we either > +have taken, or plan to take to effect this goal. Some of them are > +required to be considered secure (that is, there are known attack > +vectors which they close); others are "just in case" (that is, there > +are no known attack vectors, but we perform the restrictions to reduce > +the possibility of unknown attack vectors). > + > +# Restrictions done > + > +The following restrictions a
Re: [Xen-devel] [PATCH 3/3] tools: ipxe: Correct download error handling
> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Paul Durrant > Sent: 06 November 2018 08:44 > To: Ian Jackson ; xen-devel@lists.xenproject.org > Cc: Ian Jackson ; Wei Liu > Subject: Re: [Xen-devel] [PATCH 3/3] tools: ipxe: Correct download error > handling > > > -Original Message- > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > > Sent: 05 November 2018 18:43 > > To: xen-devel@lists.xenproject.org > > Cc: Ian Jackson ; Paul Durrant > > ; Wei Liu > > Subject: [PATCH 3/3] tools: ipxe: Correct download error handling > > > > This shell fragment lacked set -e. So, eg if the download failed a > > broken ipxe.tar.gz would be left behind. > > > > Signed-off-by: Ian Jackson > > CC: Paul Durrant > > CC: Wei Liu > > Reviewed-by: Paul Durrant Also... Tested-by: Paul Durrant (using a poisoned tarball name and the fact that ipxe still can't be accessed via git://) > > > --- > > tools/firmware/etherboot/Makefile | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/tools/firmware/etherboot/Makefile > > b/tools/firmware/etherboot/Makefile > > index 3868f876ea..fd8dfdf5a7 100644 > > --- a/tools/firmware/etherboot/Makefile > > +++ b/tools/firmware/etherboot/Makefile > > @@ -33,7 +33,7 @@ $(ROM): $(ROMS) > > $(MAKE) -C $D/src bin/$(*F).rom > > > > $T: > > - if ! $(FETCHER) _$T $(IPXE_TARBALL_URL); then \ > > + set -e; if ! $(FETCHER) _$T $(IPXE_TARBALL_URL); then \ > > $(GIT) clone $(IPXE_GIT_URL) $D.git; \ > > (cd $D.git && $(GIT) archive --format=tar --prefix=$D/ \ > > $(IPXE_GIT_TAG) | gzip -n >../_$T); \ > > -- > > 2.11.0 > > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 75574: tolerable FAIL
This run is configured for baseline tests only. flight 75574 ovmf real [real] http://osstest.xensource.com/osstest/logs/75574/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75573 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75573 version targeted for testing: ovmf e40f8efb8b06e023689120452e7ed5db199363de baseline version: ovmf e048ce883c8e9f746a655ca5a4c8c0ce34198999 Last test of basis75573 2018-11-05 11:25:33 Z0 days Testing same since75574 2018-11-06 06:31:58 Z0 days1 attempts People who touched revisions under test: Bob Feng BobCF Fu Siyuan Jim Dailey jim.dai...@dell.com Liming Gao shenglei Shenglei Zhang Sumit Garg jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit e40f8efb8b06e023689120452e7ed5db199363de Author: Sumit Garg Date: Fri Nov 2 12:23:14 2018 +0530 ArmPkg/OpteeLib: Fix compilation issues for ARM (32-bit) Correct usage of EFI_PHYSICAL_ADDRESS (always 64-bit) vs. pointers (depending on architecture). Reported-by: Leif Lindholm Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Sumit Garg Reviewed-by: Ard Biesheuvel commit 6cf3aeaeb1b242ff3bb076ba4c93248b5f387c7f Author: Fu Siyuan Date: Tue Oct 30 14:47:33 2018 +0800 EmulatorPkg: Replace obsoleted network drivers from platform DSC/FDF. This patch replaces the MdeModulePkg TCP, PXE and iSCSI driver with those ones in NetworkPkg. These 3 drivers in MdeModulePkg are not being actively maintained and will be removed from edk2 master soon. Cc: Jordan Justen Cc: Andrew Fish Cc: Ruiyu Ni Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Fu Siyuan Reviewed-by: Ruiyu Ni commit 2eee9d65815e779c7ccd09b92957bc701ba0a796 Author: Fu Siyuan Date: Tue Oct 30 14:43:37 2018 +0800 Nt32Pkg: Replace obsoleted network drivers from NT32 platform DSC/FDF. This patch replaces the MdeModulePkg TCP, PXE and iSCSI driver with those ones in NetworkPkg. These 3 drivers in MdeModulePkg are not being actively maintained and will be removed from edk2 master soon. Cc: Ruiyu Ni Cc: Hao Wu Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Fu Siyuan Reviewed-by: Ruiyu Ni commit 806c28ef50d3108c5dc5bb509390bf3e1ecd673f Author: shenglei Date: Mon Nov 5 11:08:07 2018 +0800 CorebootPayloadPkg: Remove EdkShellBinPkg in FDF Remove EdkShellBinPkg in CorebootPayloadPkg.fdf. https://bugzilla.tianocore.org/show_bug.cgi?id=1108 v3:Remove FULL_BIN and change SHELL_TYPE from FULL_BIN to UEFI_BIN. Cc: Maurice Ma Cc: Prince Agyeman Cc: Benjamin You Change-Id: I4db7068a3a1f68a1f6303079b73dc548c9feb2e3 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Shenglei Zhang Reviewed-by: Benjamin You commit c95f600e937ac4b48f75b950351f7a149f31e055 Author: BobCF Date: Fri Nov 2 13:56:38 2018 +0800 BaseTools: Use common cc flag for building PcdValueInit. V3: Update the patch to avoid "reduce" function fail. V2: Support to extract the common cc flag from a combined cc flag string. For example MSFT:*_*_IA32_CC_FLAGS = /D DISABLE_NEW_DEPRECATED_INTERFACES /DDEF_IA32 MSFT:*_*_X64_CC_FLAGS = /DDEF_X64 /D DISABLE_NEW_DEPRECATED_INTERFACES V1: Use common cc flags for building PcdValueInit. The common cc flags include the cc flag which is under common arch and under all build arches. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-b
Re: [Xen-devel] [PATCH 3/3] tools: ipxe: Correct download error handling
> -Original Message- > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > Sent: 05 November 2018 18:43 > To: xen-devel@lists.xenproject.org > Cc: Ian Jackson ; Paul Durrant > ; Wei Liu > Subject: [PATCH 3/3] tools: ipxe: Correct download error handling > > This shell fragment lacked set -e. So, eg if the download failed a > broken ipxe.tar.gz would be left behind. > > Signed-off-by: Ian Jackson > CC: Paul Durrant > CC: Wei Liu Reviewed-by: Paul Durrant > --- > tools/firmware/etherboot/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/firmware/etherboot/Makefile > b/tools/firmware/etherboot/Makefile > index 3868f876ea..fd8dfdf5a7 100644 > --- a/tools/firmware/etherboot/Makefile > +++ b/tools/firmware/etherboot/Makefile > @@ -33,7 +33,7 @@ $(ROM): $(ROMS) > $(MAKE) -C $D/src bin/$(*F).rom > > $T: > - if ! $(FETCHER) _$T $(IPXE_TARBALL_URL); then \ > + set -e; if ! $(FETCHER) _$T $(IPXE_TARBALL_URL); then \ > $(GIT) clone $(IPXE_GIT_URL) $D.git; \ > (cd $D.git && $(GIT) archive --format=tar --prefix=$D/ \ > $(IPXE_GIT_TAG) | gzip -n >../_$T); \ > -- > 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/3] tools: No longer advertise GIT_HTTP env var
> -Original Message- > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > Sent: 05 November 2018 18:43 > To: xen-devel@lists.xenproject.org > Cc: Ian Jackson ; Paul Durrant > ; Wei Liu > Subject: [PATCH 2/3] tools: No longer advertise GIT_HTTP env var > > In "build: add autoconf to replace custom checks in tools/check" > --enable-githttp was introduced. But we missed this comment where it > was advertised. > > Signed-off-by: Ian Jackson > CC: Paul Durrant > CC: Wei Liu TBH I'd squash this into the previous patch. I think it's better to modify the comment at the same time as the behaviour. Paul > --- > config/Tools.mk.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/config/Tools.mk.in b/config/Tools.mk.in > index d5985c0d09..98245f63c9 100644 > --- a/config/Tools.mk.in > +++ b/config/Tools.mk.in > @@ -40,7 +40,7 @@ XEN_TOOLS_RPATH := @rpath@ > # Download GIT repositories via HTTP or GIT's own protocol? > # GIT's protocol is faster and more robust, when it works at all > (firewalls > # may block it). We make it the default, but if your GIT repository > downloads > -# fail or hang, please specify GIT_HTTP=y in your environment. > +# fail or hang, please pass --enable-githttp to configure. > GIT_HTTP?= @githttp@ > > # Optional components > -- > 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/3] tools: Once again honour GIT_HTTP env var
> -Original Message- > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > Sent: 05 November 2018 18:43 > To: xen-devel@lists.xenproject.org > Cc: Ian Jackson ; Paul Durrant > ; Wei Liu > Subject: [PATCH 1/3] tools: Once again honour GIT_HTTP env var > > In "build: add autoconf to replace custom checks in tools/check" > --enable-githttp was introduced. But that had the effect of > uncondtionally setting GIT_HTTP from the configure variable. > > But the env var is advertised in some places as the way to specify > this behaviour, and overriding it is just unfriendly. > > Signed-off-by: Ian Jackson > CC: Paul Durrant > CC: Wei Liu Reviewed-by: Paul Durrant > --- > config/Tools.mk.in| 2 +- > config/Toplevel.mk.in | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/config/Tools.mk.in b/config/Tools.mk.in > index 1e5cc20bf7..d5985c0d09 100644 > --- a/config/Tools.mk.in > +++ b/config/Tools.mk.in > @@ -41,7 +41,7 @@ XEN_TOOLS_RPATH := @rpath@ > # GIT's protocol is faster and more robust, when it works at all > (firewalls > # may block it). We make it the default, but if your GIT repository > downloads > # fail or hang, please specify GIT_HTTP=y in your environment. > -GIT_HTTP:= @githttp@ > +GIT_HTTP?= @githttp@ > > # Optional components > XENSTAT_XENTOP := @monitors@ > diff --git a/config/Toplevel.mk.in b/config/Toplevel.mk.in > index 1d991895ea..4ecacbb37d 100644 > --- a/config/Toplevel.mk.in > +++ b/config/Toplevel.mk.in > @@ -1,2 +1,2 @@ > SUBSYSTEMS := @SUBSYSTEMS@ > -GIT_HTTP := @githttp@ > +GIT_HTTP ?= @githttp@ > -- > 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] ts-xen-build: Force reliance on ipxe tarball
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 05 November 2018 18:36
> To: xen-devel@lists.xenproject.org
> Cc: Ian Jackson ; Paul Durrant
> ; Wei Liu
> Subject: [OSSTEST PATCH] ts-xen-build: Force reliance on ipxe tarball
>
> xen.git/tools/firmware/etherboot/Makefile tries to get a tarball from
> xen-extfiles first and if that fails, tries cloning from ipxe.org.
>
> ipxe.org is sometimes down (or half-down) and when that happens
> without a tarball the build breaks and is hard to fix.
>
> We would like, therefore, to ensure that the tarball is always made
> before the commit which refers to it is in xen.git#master.
>
> osstest has no knowledge of ipxe as a separate thing and just lets
> xen.git have whatever version is in Config.mk. So osstest never needs
> to specify particular ipxe version by hash, or the like.
>
> So simply make osstest rely on the tarball existing, by having it
> specify a completely invalid URL for the git clone. This will detect
> attempts to update IPXE_GIT_TAG without making a corresponding
> tarball.
>
> CC: Paul Durrant
> CC: Wei Liu
> ---
> ts-xen-build | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/ts-xen-build b/ts-xen-build
> index 48bf062f..6ddfc533 100755
> --- a/ts-xen-build
> +++ b/ts-xen-build
> @@ -95,6 +95,7 @@ sub checkout () {
> echo >>.config debug=$debug_build
> echo >>.config GIT_HTTP=y
> echo >>.config LIBLEAFDIR_x86_64=lib
> + echo >>.config IPXE_GIT_URL=file:osstest/IPXE-GIT-FORBIDDEN
Do you really need four '/'? I thought three would be enough for a FQPN. Since
it's supposed to be an invalid URL though it doesn't really matter...
Reviewed-by: Paul Durrant
> echo >>.config KERNELS=''
> END
> (${enable_livepatch} ? < --
> 2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Does XEN ARM support RTC in domu?
Hi Julien, > -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of > Peng Fan > Sent: 2018年11月5日 10:11 > To: Julien Grall ; xen-devel@lists.xenproject.org; > Stefano Stabellini > Subject: Re: [Xen-devel] Does XEN ARM support RTC in domu? > > Hi Julien, > > > >> > > >>> > > >>> Just have a question, does XEN ARM support RTC in domu? To support > > >>> Android > > >> in DomU, RTC is needed for alarm, but I did not find information > > >> about RTC on xen for domu. So this need a new RTC paravirtualization > driver? > > Any suggestions? > > >> > > >> By RTC, do you mean Real-Time Clock? Something like PL031? Or do > > >> you have something else in mind? > > > > > > Yes, Real Time Clock like PL031 in DomU. I do not have a good idea > > > support RTC in ARM DomU, KVM and XEN x86 seems use emulated RTC in > > > qemu. Thinking of paravirtual RTC, and dom0 control the expire time > > > for > > alarm. > > > > The PL031 is quite small (based on the QEMU version). So I think it > > would be fine to provide an emulation in the hypervisor. > > Ok. Just like the hvm x86, implement emulate PL031 inside XEN. I'll give a > try. Just a follow up question, emulating PL031 in xen, do you have idea how to inject virtual interrupt to domu? The interrupt should be only cpu interface interrupt, I think. Thanks, Peng. > > Thanks, > Peng. > > > > > Cheers, > > > > -- > > Julien Grall > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.xe > nproject.org%2Fmailman%2Flistinfo%2Fxen-devel&data=02%7C01%7Cpen > g.fan%40nxp.com%7Cebdd8890e51a4cc7bdd208d642c40879%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636769807056922708&sdata=vhT > Z7lIEJXdmkW5R88zk9eUrk%2BfmuozgtCTIUzt7smk%3D&reserved=0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
