* Re: [PATCH] virtio_balloon: fix deadlock on OOM
From: Michal Hocko @ 2017-10-13 13:44 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Tetsuo Handa, linux-kernel, virtualization, linux-mm
In-Reply-To: <1507900754-32239-1-git-send-email-mst@redhat.com>
On Fri 13-10-17 16:21:22, Michael S. Tsirkin wrote:
> fill_balloon doing memory allocations under balloon_lock
> can cause a deadlock when leak_balloon is called from
> virtballoon_oom_notify and tries to take same lock.
>
> To fix, split page allocation and enqueue and do allocations outside the lock.
OK, that sounds like a better fix. As long as there are no other
allocations or indirect waiting for an allocation this should work
correctly. Thanks!
> Here's a detailed analysis of the deadlock by Tetsuo Handa:
>
> In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to
> serialize against fill_balloon(). But in fill_balloon(),
> alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is
> called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE]
> implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY
> is specified, this allocation attempt might indirectly depend on somebody
> else's __GFP_DIRECT_RECLAIM memory allocation. And such indirect
> __GFP_DIRECT_RECLAIM memory allocation might call leak_balloon() via
> virtballoon_oom_notify() via blocking_notifier_call_chain() callback via
> out_of_memory() when it reached __alloc_pages_may_oom() and held oom_lock
> mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it
> will cause OOM lockup. Thus, do not wait for vb->balloon_lock mutex if
> leak_balloon() is called from out_of_memory().
>
> Thread1 Thread2
> fill_balloon()
> takes a balloon_lock
> balloon_page_enqueue()
> alloc_page(GFP_HIGHUSER_MOVABLE)
> direct reclaim (__GFP_FS context) takes a fs lock
> waits for that fs lock alloc_page(GFP_NOFS)
> __alloc_pages_may_oom()
> takes the oom_lock
> out_of_memory()
> blocking_notifier_call_chain()
> leak_balloon()
> tries to take that balloon_lock and deadlocks
>
> Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Wei Wang <wei.w.wang@intel.com>
> ---
>
> This is a replacement for
> [PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
> but unlike that patch it actually deflates on oom even in presence of
> lock contention.
>
> drivers/virtio/virtio_balloon.c | 30 ++++++++++++++++++++++--------
> include/linux/balloon_compaction.h | 38 +++++++++++++++++++++++++++++++++++++-
> mm/balloon_compaction.c | 27 +++++++++++++++++++++------
> 3 files changed, 80 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index f0b3a0b..725e366 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -143,16 +143,14 @@ static void set_page_pfns(struct virtio_balloon *vb,
>
> static unsigned fill_balloon(struct virtio_balloon *vb, size_t num)
> {
> - struct balloon_dev_info *vb_dev_info = &vb->vb_dev_info;
> unsigned num_allocated_pages;
> + unsigned num_pfns;
> + struct page *page;
> + LIST_HEAD(pages);
>
> - /* We can only do one array worth at a time. */
> - num = min(num, ARRAY_SIZE(vb->pfns));
> -
> - mutex_lock(&vb->balloon_lock);
> - for (vb->num_pfns = 0; vb->num_pfns < num;
> - vb->num_pfns += VIRTIO_BALLOON_PAGES_PER_PAGE) {
> - struct page *page = balloon_page_enqueue(vb_dev_info);
> + for (num_pfns = 0; num_pfns < num;
> + num_pfns += VIRTIO_BALLOON_PAGES_PER_PAGE) {
> + struct page *page = balloon_page_alloc();
>
> if (!page) {
> dev_info_ratelimited(&vb->vdev->dev,
> @@ -162,6 +160,22 @@ static unsigned fill_balloon(struct virtio_balloon *vb, size_t num)
> msleep(200);
> break;
> }
> +
> + balloon_page_push(&pages, page);
> + }
> +
> + /* We can only do one array worth at a time. */
> + num = min(num, ARRAY_SIZE(vb->pfns));
> +
> + mutex_lock(&vb->balloon_lock);
> +
> + vb->num_pfns = 0;
> +
> + while ((page = balloon_page_pop(&pages))) {
> + balloon_page_enqueue(&vb->vb_dev_info, page);
> +
> + vb->num_pfns += VIRTIO_BALLOON_PAGES_PER_PAGE;
> +
> set_page_pfns(vb, vb->pfns + vb->num_pfns, page);
> vb->num_pages += VIRTIO_BALLOON_PAGES_PER_PAGE;
> if (!virtio_has_feature(vb->vdev,
> diff --git a/include/linux/balloon_compaction.h b/include/linux/balloon_compaction.h
> index 79542b2..88cfac4 100644
> --- a/include/linux/balloon_compaction.h
> +++ b/include/linux/balloon_compaction.h
> @@ -49,6 +49,7 @@
> #include <linux/gfp.h>
> #include <linux/err.h>
> #include <linux/fs.h>
> +#include <linux/list.h>
>
> /*
> * Balloon device information descriptor.
> @@ -66,9 +67,14 @@ struct balloon_dev_info {
> struct inode *inode;
> };
>
> -extern struct page *balloon_page_enqueue(struct balloon_dev_info *b_dev_info);
> +extern struct page *balloon_page_alloc(void);
> +extern void balloon_page_enqueue(struct balloon_dev_info *b_dev_info,
> + struct page *page);
> extern struct page *balloon_page_dequeue(struct balloon_dev_info *b_dev_info);
>
> +extern void balloon_devinfo_splice(struct balloon_dev_info *to_add,
> + struct balloon_dev_info *b_dev_info);
> +
> static inline void balloon_devinfo_init(struct balloon_dev_info *balloon)
> {
> balloon->isolated_pages = 0;
> @@ -88,6 +94,36 @@ extern int balloon_page_migrate(struct address_space *mapping,
> struct page *page, enum migrate_mode mode);
>
> /*
> + * balloon_page_push - insert a page into a page list.
> + * @head : pointer to list
> + * @page : page to be added
> + *
> + * Caller must ensure the page is private and protect the list.
> + */
> +static inline void balloon_page_push(struct list_head *pages, struct page *page)
> +{
> + list_add(&page->lru, pages);
> +}
> +
> +/*
> + * balloon_page_pop - remove a page from a page list.
> + * @head : pointer to list
> + * @page : page to be added
> + *
> + * Caller must ensure the page is private and protect the list.
> + */
> +static inline struct page *balloon_page_pop(struct list_head *pages)
> +{
> + struct page *page = list_first_entry_or_null(pages, struct page, lru);
> +
> + if (!page)
> + return NULL;
> +
> + list_del(&page->lru);
> + return page;
> +}
> +
> +/*
> * balloon_page_insert - insert a page into the balloon's page list and make
> * the page->private assignment accordingly.
> * @balloon : pointer to balloon device
> diff --git a/mm/balloon_compaction.c b/mm/balloon_compaction.c
> index b06d9fe..cd605bf 100644
> --- a/mm/balloon_compaction.c
> +++ b/mm/balloon_compaction.c
> @@ -11,22 +11,37 @@
> #include <linux/balloon_compaction.h>
>
> /*
> + * balloon_page_alloc - allocates a new page for insertion into the balloon
> + * page list.
> + *
> + * Driver must call it to properly allocate a new enlisted balloon page.
> + * Driver must call balloon_page_enqueue before definitively removing it from
> + * the guest system. This function returns the page address for the recently
> + * allocated page or NULL in the case we fail to allocate a new page this turn.
> + */
> +struct page *balloon_page_alloc(void)
> +{
> + struct page *page = alloc_page(balloon_mapping_gfp_mask() |
> + __GFP_NOMEMALLOC | __GFP_NORETRY);
> + return page;
> +}
> +EXPORT_SYMBOL_GPL(balloon_page_alloc);
> +
> +/*
> * balloon_page_enqueue - allocates a new page and inserts it into the balloon
> * page list.
> * @b_dev_info: balloon device descriptor where we will insert a new page to
> + * @page: new page to enqueue - allocated using balloon_page_alloc.
> *
> - * Driver must call it to properly allocate a new enlisted balloon page
> + * Driver must call it to properly enqueue a new allocated balloon page
> * before definitively removing it from the guest system.
> * This function returns the page address for the recently enqueued page or
> * NULL in the case we fail to allocate a new page this turn.
> */
> -struct page *balloon_page_enqueue(struct balloon_dev_info *b_dev_info)
> +void balloon_page_enqueue(struct balloon_dev_info *b_dev_info,
> + struct page *page)
> {
> unsigned long flags;
> - struct page *page = alloc_page(balloon_mapping_gfp_mask() |
> - __GFP_NOMEMALLOC | __GFP_NORETRY);
> - if (!page)
> - return NULL;
>
> /*
> * Block others from accessing the 'page' when we get around to
> --
> MST
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH v16 5/5] virtio-balloon: VIRTIO_BALLOON_F_CTRL_VQ
From: Michael S. Tsirkin @ 2017-10-13 13:38 UTC (permalink / raw)
To: Wei Wang
Cc: aarcange@redhat.com, virtio-dev@lists.oasis-open.org,
kvm@vger.kernel.org, mawilcox@microsoft.com,
qemu-devel@nongnu.org, amit.shah@redhat.com,
liliang.opensource@gmail.com, linux-kernel@vger.kernel.org,
willy@infradead.org, virtualization@lists.linux-foundation.org,
linux-mm@kvack.org, yang.zhang.wz@gmail.com, quan.xu@aliyun.com,
cornelia.huck@de.ibm.com, pbonzini@redhat.com,
akpm@linux-foundation.org, mhocko
In-Reply-To: <59DEE790.5040809@intel.com>
On Thu, Oct 12, 2017 at 11:54:56AM +0800, Wei Wang wrote:
> > But I think flushing is very fragile. You will easily run into races
> > if one of the actors gets out of sync and keeps adding data.
> > I think adding an ID in the free vq stream is a more robust
> > approach.
> >
>
> Adding ID to the free vq would need the device to distinguish whether it
> receives an ID or a free page hint,
Not really. It's pretty simple: a 64 bit buffer is an ID. A 4K and bigger one
is a page.
> so an extra protocol is needed for the two sides to talk. Currently, we
> directly assign the free page
> address to desc->addr. With ID support, we would need to first allocate
> buffer for the protocol header,
> and add the free page address to the header, then desc->addr = &header.
I do not think you should add ID on each page. What would be the point?
Add it each time you detect a new start command.
> How about putting the ID to the command path? This would avoid the above
> trouble.
>
> For example, using the 32-bit config registers:
> first 16-bit: Command field
> send 16-bit: ID field
>
> Then, the working flow would look like this:
>
> 1) Host writes "Start, 1" to the Host2Guest register and notify;
>
> 2) Guest reads Host2Guest register, and ACKs by writing "Start, 1" to
> Guest2Host register;
>
> 3) Guest starts report free pages;
>
> 4) Each time when the host receives a free page hint from the free_page_vq,
> it compares the ID fields of
> the Host2Guest and Guest2Host register. If matching, then filter out the
> free page from the migration dirty bitmap,
> otherwise, simply push back without doing the filtering.
>
>
> Best,
> Wei
All fine but config and vq ops are asynchronous. Host has no idea when
were entries added to vq. So the ID sent to host needs to be through vq.
And I would make it a 64 or at least 32 bit ID, not a 16 bit one,
to avoid wrap-around.
--
MST
^ permalink raw reply
* Re: [PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
From: Michael S. Tsirkin @ 2017-10-13 13:23 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: linux-mm, virtualization, mhocko
In-Reply-To: <1507632457-4611-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
On Tue, Oct 10, 2017 at 07:47:37PM +0900, Tetsuo Handa wrote:
> In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to
> serialize against fill_balloon(). But in fill_balloon(),
> alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is
> called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE]
> implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY
> is specified, this allocation attempt might indirectly depend on somebody
> else's __GFP_DIRECT_RECLAIM memory allocation. And such indirect
> __GFP_DIRECT_RECLAIM memory allocation might call leak_balloon() via
> virtballoon_oom_notify() via blocking_notifier_call_chain() callback via
> out_of_memory() when it reached __alloc_pages_may_oom() and held oom_lock
> mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it
> will cause OOM lockup. Thus, do not wait for vb->balloon_lock mutex if
> leak_balloon() is called from out_of_memory().
>
> Thread1 Thread2
> fill_balloon()
> takes a balloon_lock
> balloon_page_enqueue()
> alloc_page(GFP_HIGHUSER_MOVABLE)
> direct reclaim (__GFP_FS context) takes a fs lock
> waits for that fs lock alloc_page(GFP_NOFS)
> __alloc_pages_may_oom()
> takes the oom_lock
> out_of_memory()
> blocking_notifier_call_chain()
> leak_balloon()
> tries to take that balloon_lock and deadlocks
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
This doesn't deflate on oom if lock is contended, and we acked
DEFLATE_ON_OOM so host actually expects us to.
The proper fix isn't that hard - just avoid allocations under lock.
Patch posted, pls take a look.
> ---
> drivers/virtio/virtio_balloon.c | 16 +++++++++++-----
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index f0b3a0b..03e6078 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -192,7 +192,7 @@ static void release_pages_balloon(struct virtio_balloon *vb,
> }
> }
>
> -static unsigned leak_balloon(struct virtio_balloon *vb, size_t num)
> +static unsigned leak_balloon(struct virtio_balloon *vb, size_t num, bool wait)
> {
> unsigned num_freed_pages;
> struct page *page;
> @@ -202,7 +202,13 @@ static unsigned leak_balloon(struct virtio_balloon *vb, size_t num)
> /* We can only do one array worth at a time. */
> num = min(num, ARRAY_SIZE(vb->pfns));
>
> - mutex_lock(&vb->balloon_lock);
> + if (wait)
> + mutex_lock(&vb->balloon_lock);
> + else if (!mutex_trylock(&vb->balloon_lock)) {
> + pr_info("virtio_balloon: Unable to release %lu pages due to lock contention.\n",
> + (unsigned long) min(num, (size_t)vb->num_pages));
> + return 0;
> + }
> /* We can't release more pages than taken */
> num = min(num, (size_t)vb->num_pages);
> for (vb->num_pfns = 0; vb->num_pfns < num;
> @@ -367,7 +373,7 @@ static int virtballoon_oom_notify(struct notifier_block *self,
> return NOTIFY_OK;
>
> freed = parm;
> - num_freed_pages = leak_balloon(vb, oom_pages);
> + num_freed_pages = leak_balloon(vb, oom_pages, false);
> update_balloon_size(vb);
> *freed += num_freed_pages;
>
> @@ -395,7 +401,7 @@ static void update_balloon_size_func(struct work_struct *work)
> if (diff > 0)
> diff -= fill_balloon(vb, diff);
> else if (diff < 0)
> - diff += leak_balloon(vb, -diff);
> + diff += leak_balloon(vb, -diff, true);
> update_balloon_size(vb);
>
> if (diff)
> @@ -597,7 +603,7 @@ static void remove_common(struct virtio_balloon *vb)
> {
> /* There might be pages left in the balloon: free them. */
> while (vb->num_pages)
> - leak_balloon(vb, vb->num_pages);
> + leak_balloon(vb, vb->num_pages, true);
> update_balloon_size(vb);
>
> /* Now we reset the device so we can clean up the queues. */
> --
> 1.8.3.1
^ permalink raw reply
* [PATCH] virtio_balloon: fix deadlock on OOM
From: Michael S. Tsirkin @ 2017-10-13 13:21 UTC (permalink / raw)
To: linux-kernel; +Cc: Michal Hocko, Tetsuo Handa, virtualization, linux-mm
fill_balloon doing memory allocations under balloon_lock
can cause a deadlock when leak_balloon is called from
virtballoon_oom_notify and tries to take same lock.
To fix, split page allocation and enqueue and do allocations outside the lock.
Here's a detailed analysis of the deadlock by Tetsuo Handa:
In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to
serialize against fill_balloon(). But in fill_balloon(),
alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is
called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE]
implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY
is specified, this allocation attempt might indirectly depend on somebody
else's __GFP_DIRECT_RECLAIM memory allocation. And such indirect
__GFP_DIRECT_RECLAIM memory allocation might call leak_balloon() via
virtballoon_oom_notify() via blocking_notifier_call_chain() callback via
out_of_memory() when it reached __alloc_pages_may_oom() and held oom_lock
mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it
will cause OOM lockup. Thus, do not wait for vb->balloon_lock mutex if
leak_balloon() is called from out_of_memory().
Thread1 Thread2
fill_balloon()
takes a balloon_lock
balloon_page_enqueue()
alloc_page(GFP_HIGHUSER_MOVABLE)
direct reclaim (__GFP_FS context) takes a fs lock
waits for that fs lock alloc_page(GFP_NOFS)
__alloc_pages_may_oom()
takes the oom_lock
out_of_memory()
blocking_notifier_call_chain()
leak_balloon()
tries to take that balloon_lock and deadlocks
Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Wei Wang <wei.w.wang@intel.com>
---
This is a replacement for
[PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
but unlike that patch it actually deflates on oom even in presence of
lock contention.
drivers/virtio/virtio_balloon.c | 30 ++++++++++++++++++++++--------
include/linux/balloon_compaction.h | 38 +++++++++++++++++++++++++++++++++++++-
mm/balloon_compaction.c | 27 +++++++++++++++++++++------
3 files changed, 80 insertions(+), 15 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index f0b3a0b..725e366 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -143,16 +143,14 @@ static void set_page_pfns(struct virtio_balloon *vb,
static unsigned fill_balloon(struct virtio_balloon *vb, size_t num)
{
- struct balloon_dev_info *vb_dev_info = &vb->vb_dev_info;
unsigned num_allocated_pages;
+ unsigned num_pfns;
+ struct page *page;
+ LIST_HEAD(pages);
- /* We can only do one array worth at a time. */
- num = min(num, ARRAY_SIZE(vb->pfns));
-
- mutex_lock(&vb->balloon_lock);
- for (vb->num_pfns = 0; vb->num_pfns < num;
- vb->num_pfns += VIRTIO_BALLOON_PAGES_PER_PAGE) {
- struct page *page = balloon_page_enqueue(vb_dev_info);
+ for (num_pfns = 0; num_pfns < num;
+ num_pfns += VIRTIO_BALLOON_PAGES_PER_PAGE) {
+ struct page *page = balloon_page_alloc();
if (!page) {
dev_info_ratelimited(&vb->vdev->dev,
@@ -162,6 +160,22 @@ static unsigned fill_balloon(struct virtio_balloon *vb, size_t num)
msleep(200);
break;
}
+
+ balloon_page_push(&pages, page);
+ }
+
+ /* We can only do one array worth at a time. */
+ num = min(num, ARRAY_SIZE(vb->pfns));
+
+ mutex_lock(&vb->balloon_lock);
+
+ vb->num_pfns = 0;
+
+ while ((page = balloon_page_pop(&pages))) {
+ balloon_page_enqueue(&vb->vb_dev_info, page);
+
+ vb->num_pfns += VIRTIO_BALLOON_PAGES_PER_PAGE;
+
set_page_pfns(vb, vb->pfns + vb->num_pfns, page);
vb->num_pages += VIRTIO_BALLOON_PAGES_PER_PAGE;
if (!virtio_has_feature(vb->vdev,
diff --git a/include/linux/balloon_compaction.h b/include/linux/balloon_compaction.h
index 79542b2..88cfac4 100644
--- a/include/linux/balloon_compaction.h
+++ b/include/linux/balloon_compaction.h
@@ -49,6 +49,7 @@
#include <linux/gfp.h>
#include <linux/err.h>
#include <linux/fs.h>
+#include <linux/list.h>
/*
* Balloon device information descriptor.
@@ -66,9 +67,14 @@ struct balloon_dev_info {
struct inode *inode;
};
-extern struct page *balloon_page_enqueue(struct balloon_dev_info *b_dev_info);
+extern struct page *balloon_page_alloc(void);
+extern void balloon_page_enqueue(struct balloon_dev_info *b_dev_info,
+ struct page *page);
extern struct page *balloon_page_dequeue(struct balloon_dev_info *b_dev_info);
+extern void balloon_devinfo_splice(struct balloon_dev_info *to_add,
+ struct balloon_dev_info *b_dev_info);
+
static inline void balloon_devinfo_init(struct balloon_dev_info *balloon)
{
balloon->isolated_pages = 0;
@@ -88,6 +94,36 @@ extern int balloon_page_migrate(struct address_space *mapping,
struct page *page, enum migrate_mode mode);
/*
+ * balloon_page_push - insert a page into a page list.
+ * @head : pointer to list
+ * @page : page to be added
+ *
+ * Caller must ensure the page is private and protect the list.
+ */
+static inline void balloon_page_push(struct list_head *pages, struct page *page)
+{
+ list_add(&page->lru, pages);
+}
+
+/*
+ * balloon_page_pop - remove a page from a page list.
+ * @head : pointer to list
+ * @page : page to be added
+ *
+ * Caller must ensure the page is private and protect the list.
+ */
+static inline struct page *balloon_page_pop(struct list_head *pages)
+{
+ struct page *page = list_first_entry_or_null(pages, struct page, lru);
+
+ if (!page)
+ return NULL;
+
+ list_del(&page->lru);
+ return page;
+}
+
+/*
* balloon_page_insert - insert a page into the balloon's page list and make
* the page->private assignment accordingly.
* @balloon : pointer to balloon device
diff --git a/mm/balloon_compaction.c b/mm/balloon_compaction.c
index b06d9fe..cd605bf 100644
--- a/mm/balloon_compaction.c
+++ b/mm/balloon_compaction.c
@@ -11,22 +11,37 @@
#include <linux/balloon_compaction.h>
/*
+ * balloon_page_alloc - allocates a new page for insertion into the balloon
+ * page list.
+ *
+ * Driver must call it to properly allocate a new enlisted balloon page.
+ * Driver must call balloon_page_enqueue before definitively removing it from
+ * the guest system. This function returns the page address for the recently
+ * allocated page or NULL in the case we fail to allocate a new page this turn.
+ */
+struct page *balloon_page_alloc(void)
+{
+ struct page *page = alloc_page(balloon_mapping_gfp_mask() |
+ __GFP_NOMEMALLOC | __GFP_NORETRY);
+ return page;
+}
+EXPORT_SYMBOL_GPL(balloon_page_alloc);
+
+/*
* balloon_page_enqueue - allocates a new page and inserts it into the balloon
* page list.
* @b_dev_info: balloon device descriptor where we will insert a new page to
+ * @page: new page to enqueue - allocated using balloon_page_alloc.
*
- * Driver must call it to properly allocate a new enlisted balloon page
+ * Driver must call it to properly enqueue a new allocated balloon page
* before definitively removing it from the guest system.
* This function returns the page address for the recently enqueued page or
* NULL in the case we fail to allocate a new page this turn.
*/
-struct page *balloon_page_enqueue(struct balloon_dev_info *b_dev_info)
+void balloon_page_enqueue(struct balloon_dev_info *b_dev_info,
+ struct page *page)
{
unsigned long flags;
- struct page *page = alloc_page(balloon_mapping_gfp_mask() |
- __GFP_NOMEMALLOC | __GFP_NORETRY);
- if (!page)
- return NULL;
/*
* Block others from accessing the 'page' when we get around to
--
MST
^ permalink raw reply related
* Re: [PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
From: Michael S. Tsirkin @ 2017-10-13 13:19 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: linux-mm, virtualization
In-Reply-To: <201710132028.EHI23713.MJLHOFFOOVtFQS@I-love.SAKURA.ne.jp>
On Fri, Oct 13, 2017 at 08:28:37PM +0900, Tetsuo Handa wrote:
> Michael, will you pick up this patch?
> ----------
> >From 210dba24134e54cd470e79712c5cb8bb255566c0 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Tue, 10 Oct 2017 19:28:20 +0900
> Subject: [PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
>
> In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to
> serialize against fill_balloon(). But in fill_balloon(),
> alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is
> called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE]
> implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY
> is specified, this allocation attempt might indirectly depend on somebody
> else's __GFP_DIRECT_RECLAIM memory allocation. And such indirect
> __GFP_DIRECT_RECLAIM memory allocation might call leak_balloon() via
> virtballoon_oom_notify() via blocking_notifier_call_chain() callback via
> out_of_memory() when it reached __alloc_pages_may_oom() and held oom_lock
> mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it
> will cause OOM lockup. Thus, do not wait for vb->balloon_lock mutex if
> leak_balloon() is called from out_of_memory().
>
> Thread1 Thread2
> fill_balloon()
> takes a balloon_lock
> balloon_page_enqueue()
> alloc_page(GFP_HIGHUSER_MOVABLE)
> direct reclaim (__GFP_FS context) takes a fs lock
> waits for that fs lock alloc_page(GFP_NOFS)
> __alloc_pages_may_oom()
> takes the oom_lock
> out_of_memory()
> blocking_notifier_call_chain()
> leak_balloon()
> tries to take that balloon_lock and deadlocks
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Reviewed-by: Michal Hocko <mhocko@suse.com>
> Reviewed-by: Wei Wang <wei.w.wang@intel.com>
I won't since it does not deflate on OOM as we have promised host to do.
Will post a patch to fix the issue shortly.
> ---
> drivers/virtio/virtio_balloon.c | 16 +++++++++++-----
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index f0b3a0b..03e6078 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -192,7 +192,7 @@ static void release_pages_balloon(struct virtio_balloon *vb,
> }
> }
>
> -static unsigned leak_balloon(struct virtio_balloon *vb, size_t num)
> +static unsigned leak_balloon(struct virtio_balloon *vb, size_t num, bool wait)
> {
> unsigned num_freed_pages;
> struct page *page;
> @@ -202,7 +202,13 @@ static unsigned leak_balloon(struct virtio_balloon *vb, size_t num)
> /* We can only do one array worth at a time. */
> num = min(num, ARRAY_SIZE(vb->pfns));
>
> - mutex_lock(&vb->balloon_lock);
> + if (wait)
> + mutex_lock(&vb->balloon_lock);
> + else if (!mutex_trylock(&vb->balloon_lock)) {
> + pr_info("virtio_balloon: Unable to release %lu pages due to lock contention.\n",
> + (unsigned long) min(num, (size_t)vb->num_pages));
> + return 0;
> + }
> /* We can't release more pages than taken */
> num = min(num, (size_t)vb->num_pages);
> for (vb->num_pfns = 0; vb->num_pfns < num;
> @@ -367,7 +373,7 @@ static int virtballoon_oom_notify(struct notifier_block *self,
> return NOTIFY_OK;
>
> freed = parm;
> - num_freed_pages = leak_balloon(vb, oom_pages);
> + num_freed_pages = leak_balloon(vb, oom_pages, false);
> update_balloon_size(vb);
> *freed += num_freed_pages;
>
> @@ -395,7 +401,7 @@ static void update_balloon_size_func(struct work_struct *work)
> if (diff > 0)
> diff -= fill_balloon(vb, diff);
> else if (diff < 0)
> - diff += leak_balloon(vb, -diff);
> + diff += leak_balloon(vb, -diff, true);
> update_balloon_size(vb);
>
> if (diff)
> @@ -597,7 +603,7 @@ static void remove_common(struct virtio_balloon *vb)
> {
> /* There might be pages left in the balloon: free them. */
> while (vb->num_pages)
> - leak_balloon(vb, vb->num_pages);
> + leak_balloon(vb, vb->num_pages, true);
> update_balloon_size(vb);
>
> /* Now we reset the device so we can clean up the queues. */
> --
> 1.8.3.1
^ permalink raw reply
* Re: [PATCH v1 15/27] compiler: Option to default to hidden symbols
From: Luis R. Rodriguez @ 2017-10-12 20:02 UTC (permalink / raw)
To: Thomas Garnier, Guenter Roeck, Nicholas Piggin
Cc: Nicolas Pitre, Michal Hocko, Radim Krčmář,
linux-doc, Daniel Micay, Len Brown, Peter Zijlstra,
Christopher Li, Jan H . Schönherr, Alexei Starovoitov,
virtualization, David Howells, Paul Gortmaker, Waiman Long,
Pavel Machek, H . Peter Anvin, kernel-hardening,
Christoph Lameter, Thomas Gleixner, x86, Herbert Xu,
Daniel Borkmann, Jonathan Corbet
In-Reply-To: <20171011203027.11248-16-thgarnie@google.com>
On Wed, Oct 11, 2017 at 01:30:15PM -0700, Thomas Garnier wrote:
> Provide an option to default visibility to hidden except for key
> symbols. This option is disabled by default and will be used by x86_64
> PIE support to remove errors between compilation units.
>
> The default visibility is also enabled for external symbols that are
> compared as they maybe equals (start/end of sections). In this case,
> older versions of GCC will remove the comparison if the symbols are
> hidden. This issue exists at least on gcc 4.9 and before.
>
> Signed-off-by: Thomas Garnier <thgarnie@google.com>
<-- snip -->
> diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
> index 86e8f0b2537b..8f021783a929 100644
> --- a/arch/x86/kernel/cpu/microcode/core.c
> +++ b/arch/x86/kernel/cpu/microcode/core.c
> @@ -144,8 +144,8 @@ static bool __init check_loader_disabled_bsp(void)
> return *res;
> }
>
> -extern struct builtin_fw __start_builtin_fw[];
> -extern struct builtin_fw __end_builtin_fw[];
> +extern struct builtin_fw __start_builtin_fw[] __default_visibility;
> +extern struct builtin_fw __end_builtin_fw[] __default_visibility;
>
> bool get_builtin_firmware(struct cpio_data *cd, const char *name)
> {
<-- snip -->
> diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
> index e5da44eddd2f..1aa5d6dac9e1 100644
> --- a/include/asm-generic/sections.h
> +++ b/include/asm-generic/sections.h
> @@ -30,6 +30,9 @@
> * __irqentry_text_start, __irqentry_text_end
> * __softirqentry_text_start, __softirqentry_text_end
> */
> +#ifdef CONFIG_DEFAULT_HIDDEN
> +#pragma GCC visibility push(default)
> +#endif
> extern char _text[], _stext[], _etext[];
> extern char _data[], _sdata[], _edata[];
> extern char __bss_start[], __bss_stop[];
> @@ -46,6 +49,9 @@ extern char __softirqentry_text_start[], __softirqentry_text_end[];
>
> /* Start and end of .ctors section - used for constructor calls. */
> extern char __ctors_start[], __ctors_end[];
> +#ifdef CONFIG_DEFAULT_HIDDEN
> +#pragma GCC visibility pop
> +#endif
>
> extern __visible const void __nosave_begin, __nosave_end;
>
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index e95a2631e545..6997716f73bf 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -78,6 +78,14 @@ extern void __chk_io_ptr(const volatile void __iomem *);
> #include <linux/compiler-clang.h>
> #endif
>
> +/* Useful for Position Independent Code to reduce global references */
> +#ifdef CONFIG_DEFAULT_HIDDEN
> +#pragma GCC visibility push(hidden)
> +#define __default_visibility __attribute__((visibility ("default")))
Does this still work with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION ?
> +#else
> +#define __default_visibility
> +#endif
> +
> /*
> * Generic compiler-dependent macros required for kernel
> * build go below this comment. Actual compiler/compiler version
> diff --git a/init/Kconfig b/init/Kconfig
> index ccb1d8daf241..b640201fcff7 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1649,6 +1649,13 @@ config PROFILING
> config TRACEPOINTS
> bool
>
> +#
> +# Default to hidden visibility for all symbols.
> +# Useful for Position Independent Code to reduce global references.
> +#
> +config DEFAULT_HIDDEN
> + bool
Note it is default.
Has 0-day ran through this git tree? It should be easy to get it added for
testing. Also, even though most changes are x86 based there are some generic
changes and I'd love a warm fuzzy this won't break odd / random builds.
Although 0-day does cover a lot of test cases, it only has limited run time
tests. There are some other test beds which also cover some more obscure
architectures. Having a test pass on Guenter's test bed would be nice to
see. For that please coordinate with Guenter if he's willing to run this
a test for you.
Luis
^ permalink raw reply
* Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
From: Boris Ostrovsky @ 2017-10-12 19:53 UTC (permalink / raw)
To: Andrew Cooper, Josh Poimboeuf
Cc: Juergen Gross, Mike Galbraith, Peter Zijlstra, Linus Torvalds,
Rusty Russell, virtualization, x86, linux-kernel, Chris Wright,
live-patching, Ingo Molnar, Borislav Petkov, Andy Lutomirski,
H. Peter Anvin, xen-devel, Thomas Gleixner, Sasha Levin,
Jiri Slaby, Alok Kataria
In-Reply-To: <ed30216f-4b9e-2bc3-b1d2-36135b29d746@citrix.com>
On 10/12/2017 03:27 PM, Andrew Cooper wrote:
> On 12/10/17 20:11, Boris Ostrovsky wrote:
>> On 10/06/2017 10:32 AM, Josh Poimboeuf wrote:
>>> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote:
>>>>> #ifdef CONFIG_PARAVIRT
>>>>> +/*
>>>>> + * Paravirt alternatives are applied much earlier than normal alternatives.
>>>>> + * They are only applied when running on a hypervisor. They replace some
>>>>> + * native instructions with calls to pv ops.
>>>>> + */
>>>>> +void __init apply_pv_alternatives(void)
>>>>> +{
>>>>> + setup_force_cpu_cap(X86_FEATURE_PV_OPS);
>>>> Not for Xen HVM guests.
>>> From what I can tell, HVM guests still use pv_time_ops and
>>> pv_mmu_ops.exit_mmap, right?
>>>
>>>>> + apply_alternatives(__pv_alt_instructions, __pv_alt_instructions_end);
>>>>> +}
>>>> This is a problem (at least for Xen PV guests):
>>>> apply_alternatives()->text_poke_early()->local_irq_save()->...'cli'->death.
>>> Ah, right.
>>>
>>>> It might be possible not to turn off/on the interrupts in this
>>>> particular case since the guest probably won't be able to handle an
>>>> interrupt at this point anyway.
>>> Yeah, that should work. For Xen and for the other hypervisors, this is
>>> called well before irq init, so interrupts can't be handled yet anyway.
>> There is also another problem:
>>
>> [ 1.312425] general protection fault: 0000 [#1] SMP
>> [ 1.312901] Modules linked in:
>> [ 1.313389] CPU: 0 PID: 1 Comm: init Not tainted 4.14.0-rc4+ #6
>> [ 1.313878] task: ffff88003e2c0000 task.stack: ffffc9000038c000
>> [ 1.314360] RIP: 10000e030:entry_SYSCALL_64_fastpath+0x1/0xa5
>> [ 1.314854] RSP: e02b:ffffc9000038ff50 EFLAGS: 00010046
>> [ 1.315336] RAX: 000000000000000c RBX: 000055f550168040 RCX:
>> 00007fcfc959f59a
>> [ 1.315827] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
>> 0000000000000000
>> [ 1.316315] RBP: 000000000000000a R08: 000000000000037f R09:
>> 0000000000000064
>> [ 1.316805] R10: 000000001f89cbf5 R11: ffff88003e2c0000 R12:
>> 00007fcfc958ad60
>> [ 1.317300] R13: 0000000000000000 R14: 000055f550185954 R15:
>> 0000000000001000
>> [ 1.317801] FS: 0000000000000000(0000) GS:ffff88003f800000(0000)
>> knlGS:0000000000000000
>> [ 1.318267] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [ 1.318750] CR2: 00007fcfc97ab218 CR3: 000000003c88e000 CR4:
>> 0000000000042660
>> [ 1.319235] Call Trace:
>> [ 1.319700] Code: 51 50 57 56 52 51 6a da 41 50 41 51 41 52 41 53 48
>> 83 ec 30 65 4c 8b 1c 25 c0 d2 00 00 41 f7 03 df 39 08 90 0f 85 a5 00 00
>> 00 50 <ff> 15 9c 95 d0 ff 58 48 3d 4c 01 00 00 77 0f 4c 89 d1 ff 14 c5
>> [ 1.321161] RIP: entry_SYSCALL_64_fastpath+0x1/0xa5 RSP: ffffc9000038ff50
>> [ 1.344255] ---[ end trace d7cb8cd6cd7c294c ]---
>> [ 1.345009] Kernel panic - not syncing: Attempted to kill init!
>> exitcode=0x0000000b
>>
>>
>> All code
>> ========
>> 0: 51 push %rcx
>> 1: 50 push %rax
>> 2: 57 push %rdi
>> 3: 56 push %rsi
>> 4: 52 push %rdx
>> 5: 51 push %rcx
>> 6: 6a da pushq $0xffffffffffffffda
>> 8: 41 50 push %r8
>> a: 41 51 push %r9
>> c: 41 52 push %r10
>> e: 41 53 push %r11
>> 10: 48 83 ec 30 sub $0x30,%rsp
>> 14: 65 4c 8b 1c 25 c0 d2 mov %gs:0xd2c0,%r11
>> 1b: 00 00
>> 1d: 41 f7 03 df 39 08 90 testl $0x900839df,(%r11)
>> 24: 0f 85 a5 00 00 00 jne 0xcf
>> 2a: 50 push %rax
>> 2b:* ff 15 9c 95 d0 ff callq *-0x2f6a64(%rip) #
>> 0xffffffffffd095cd <-- trapping instruction
>> 31: 58 pop %rax
>> 32: 48 3d 4c 01 00 00 cmp $0x14c,%rax
>> 38: 77 0f ja 0x49
>> 3a: 4c 89 d1 mov %r10,%rcx
>> 3d: ff .byte 0xff
>> 3e: 14 c5 adc $0xc5,%al
>>
>>
>> so the original 'cli' was replaced with the pv call but to me the offset
>> looks a bit off, no? Shouldn't it always be positive?
> callq takes a 32bit signed displacement, so jumping back by up to 2G is
> perfectly legitimate.
Yes, but
ostr@workbase> nm vmlinux | grep entry_SYSCALL_64_fastpath
ffffffff817365dd t entry_SYSCALL_64_fastpath
ostr@workbase> nm vmlinux | grep " pv_irq_ops"
ffffffff81c2dbc0 D pv_irq_ops
ostr@workbase>
so pv_irq_ops.irq_disable is about 5MB ahead of where we are now. (I
didn't mean that x86 instruction set doesn't allow negative
displacement, I was trying to say that pv_irq_ops always live further down)
>
> The #GP[0] however means that whatever 8 byte value was found at
> -0x2f6a64(%rip) was a non-canonical address.
>
> One option is that the pvops structure hasn't been initialised properly,
It was, I did check that. And just to make sure I re-initialized it
before alt instructions were rewritten.
> but an alternative is that the relocation wasn't processed correctly,
> and the code is trying to reference something which isn't a function
> pointer.
Let me see if I can poke at what's there.
-boris
^ permalink raw reply
* Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
From: Andrew Cooper @ 2017-10-12 19:27 UTC (permalink / raw)
To: Boris Ostrovsky, Josh Poimboeuf
Cc: Juergen Gross, Mike Galbraith, Peter Zijlstra, Linus Torvalds,
Rusty Russell, virtualization, x86, linux-kernel, Chris Wright,
live-patching, Ingo Molnar, Borislav Petkov, Andy Lutomirski,
H. Peter Anvin, xen-devel, Thomas Gleixner, Sasha Levin,
Jiri Slaby, Alok Kataria
In-Reply-To: <5a49e43a-8d6b-512a-ec5a-641be7bae41d@oracle.com>
On 12/10/17 20:11, Boris Ostrovsky wrote:
> On 10/06/2017 10:32 AM, Josh Poimboeuf wrote:
>> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote:
>>>> #ifdef CONFIG_PARAVIRT
>>>> +/*
>>>> + * Paravirt alternatives are applied much earlier than normal alternatives.
>>>> + * They are only applied when running on a hypervisor. They replace some
>>>> + * native instructions with calls to pv ops.
>>>> + */
>>>> +void __init apply_pv_alternatives(void)
>>>> +{
>>>> + setup_force_cpu_cap(X86_FEATURE_PV_OPS);
>>> Not for Xen HVM guests.
>> From what I can tell, HVM guests still use pv_time_ops and
>> pv_mmu_ops.exit_mmap, right?
>>
>>>> + apply_alternatives(__pv_alt_instructions, __pv_alt_instructions_end);
>>>> +}
>>> This is a problem (at least for Xen PV guests):
>>> apply_alternatives()->text_poke_early()->local_irq_save()->...'cli'->death.
>> Ah, right.
>>
>>> It might be possible not to turn off/on the interrupts in this
>>> particular case since the guest probably won't be able to handle an
>>> interrupt at this point anyway.
>> Yeah, that should work. For Xen and for the other hypervisors, this is
>> called well before irq init, so interrupts can't be handled yet anyway.
> There is also another problem:
>
> [ 1.312425] general protection fault: 0000 [#1] SMP
> [ 1.312901] Modules linked in:
> [ 1.313389] CPU: 0 PID: 1 Comm: init Not tainted 4.14.0-rc4+ #6
> [ 1.313878] task: ffff88003e2c0000 task.stack: ffffc9000038c000
> [ 1.314360] RIP: 10000e030:entry_SYSCALL_64_fastpath+0x1/0xa5
> [ 1.314854] RSP: e02b:ffffc9000038ff50 EFLAGS: 00010046
> [ 1.315336] RAX: 000000000000000c RBX: 000055f550168040 RCX:
> 00007fcfc959f59a
> [ 1.315827] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
> 0000000000000000
> [ 1.316315] RBP: 000000000000000a R08: 000000000000037f R09:
> 0000000000000064
> [ 1.316805] R10: 000000001f89cbf5 R11: ffff88003e2c0000 R12:
> 00007fcfc958ad60
> [ 1.317300] R13: 0000000000000000 R14: 000055f550185954 R15:
> 0000000000001000
> [ 1.317801] FS: 0000000000000000(0000) GS:ffff88003f800000(0000)
> knlGS:0000000000000000
> [ 1.318267] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 1.318750] CR2: 00007fcfc97ab218 CR3: 000000003c88e000 CR4:
> 0000000000042660
> [ 1.319235] Call Trace:
> [ 1.319700] Code: 51 50 57 56 52 51 6a da 41 50 41 51 41 52 41 53 48
> 83 ec 30 65 4c 8b 1c 25 c0 d2 00 00 41 f7 03 df 39 08 90 0f 85 a5 00 00
> 00 50 <ff> 15 9c 95 d0 ff 58 48 3d 4c 01 00 00 77 0f 4c 89 d1 ff 14 c5
> [ 1.321161] RIP: entry_SYSCALL_64_fastpath+0x1/0xa5 RSP: ffffc9000038ff50
> [ 1.344255] ---[ end trace d7cb8cd6cd7c294c ]---
> [ 1.345009] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0000000b
>
>
> All code
> ========
> 0: 51 push %rcx
> 1: 50 push %rax
> 2: 57 push %rdi
> 3: 56 push %rsi
> 4: 52 push %rdx
> 5: 51 push %rcx
> 6: 6a da pushq $0xffffffffffffffda
> 8: 41 50 push %r8
> a: 41 51 push %r9
> c: 41 52 push %r10
> e: 41 53 push %r11
> 10: 48 83 ec 30 sub $0x30,%rsp
> 14: 65 4c 8b 1c 25 c0 d2 mov %gs:0xd2c0,%r11
> 1b: 00 00
> 1d: 41 f7 03 df 39 08 90 testl $0x900839df,(%r11)
> 24: 0f 85 a5 00 00 00 jne 0xcf
> 2a: 50 push %rax
> 2b:* ff 15 9c 95 d0 ff callq *-0x2f6a64(%rip) #
> 0xffffffffffd095cd <-- trapping instruction
> 31: 58 pop %rax
> 32: 48 3d 4c 01 00 00 cmp $0x14c,%rax
> 38: 77 0f ja 0x49
> 3a: 4c 89 d1 mov %r10,%rcx
> 3d: ff .byte 0xff
> 3e: 14 c5 adc $0xc5,%al
>
>
> so the original 'cli' was replaced with the pv call but to me the offset
> looks a bit off, no? Shouldn't it always be positive?
callq takes a 32bit signed displacement, so jumping back by up to 2G is
perfectly legitimate.
The #GP[0] however means that whatever 8 byte value was found at
-0x2f6a64(%rip) was a non-canonical address.
One option is that the pvops structure hasn't been initialised properly,
but an alternative is that the relocation wasn't processed correctly,
and the code is trying to reference something which isn't a function
pointer.
~Andrew
^ permalink raw reply
* Re: [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure
From: Boris Ostrovsky @ 2017-10-12 19:11 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Juergen Gross, Rusty Russell, Mike Galbraith, xen-devel,
Peter Zijlstra, Jiri Slaby, x86, linux-kernel, Sasha Levin,
Chris Wright, Thomas Gleixner, Andy Lutomirski, H. Peter Anvin,
Borislav Petkov, live-patching, Alok Kataria, virtualization,
Linus Torvalds, Ingo Molnar
In-Reply-To: <20171006143259.rs3zh7k5tmsgesqy@treble>
On 10/06/2017 10:32 AM, Josh Poimboeuf wrote:
> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote:
>>> #ifdef CONFIG_PARAVIRT
>>> +/*
>>> + * Paravirt alternatives are applied much earlier than normal alternatives.
>>> + * They are only applied when running on a hypervisor. They replace some
>>> + * native instructions with calls to pv ops.
>>> + */
>>> +void __init apply_pv_alternatives(void)
>>> +{
>>> + setup_force_cpu_cap(X86_FEATURE_PV_OPS);
>> Not for Xen HVM guests.
> From what I can tell, HVM guests still use pv_time_ops and
> pv_mmu_ops.exit_mmap, right?
>
>>> + apply_alternatives(__pv_alt_instructions, __pv_alt_instructions_end);
>>> +}
>>
>> This is a problem (at least for Xen PV guests):
>> apply_alternatives()->text_poke_early()->local_irq_save()->...'cli'->death.
> Ah, right.
>
>> It might be possible not to turn off/on the interrupts in this
>> particular case since the guest probably won't be able to handle an
>> interrupt at this point anyway.
> Yeah, that should work. For Xen and for the other hypervisors, this is
> called well before irq init, so interrupts can't be handled yet anyway.
There is also another problem:
[ 1.312425] general protection fault: 0000 [#1] SMP
[ 1.312901] Modules linked in:
[ 1.313389] CPU: 0 PID: 1 Comm: init Not tainted 4.14.0-rc4+ #6
[ 1.313878] task: ffff88003e2c0000 task.stack: ffffc9000038c000
[ 1.314360] RIP: 10000e030:entry_SYSCALL_64_fastpath+0x1/0xa5
[ 1.314854] RSP: e02b:ffffc9000038ff50 EFLAGS: 00010046
[ 1.315336] RAX: 000000000000000c RBX: 000055f550168040 RCX:
00007fcfc959f59a
[ 1.315827] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
0000000000000000
[ 1.316315] RBP: 000000000000000a R08: 000000000000037f R09:
0000000000000064
[ 1.316805] R10: 000000001f89cbf5 R11: ffff88003e2c0000 R12:
00007fcfc958ad60
[ 1.317300] R13: 0000000000000000 R14: 000055f550185954 R15:
0000000000001000
[ 1.317801] FS: 0000000000000000(0000) GS:ffff88003f800000(0000)
knlGS:0000000000000000
[ 1.318267] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1.318750] CR2: 00007fcfc97ab218 CR3: 000000003c88e000 CR4:
0000000000042660
[ 1.319235] Call Trace:
[ 1.319700] Code: 51 50 57 56 52 51 6a da 41 50 41 51 41 52 41 53 48
83 ec 30 65 4c 8b 1c 25 c0 d2 00 00 41 f7 03 df 39 08 90 0f 85 a5 00 00
00 50 <ff> 15 9c 95 d0 ff 58 48 3d 4c 01 00 00 77 0f 4c 89 d1 ff 14 c5
[ 1.321161] RIP: entry_SYSCALL_64_fastpath+0x1/0xa5 RSP: ffffc9000038ff50
[ 1.344255] ---[ end trace d7cb8cd6cd7c294c ]---
[ 1.345009] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
All code
========
0: 51 push %rcx
1: 50 push %rax
2: 57 push %rdi
3: 56 push %rsi
4: 52 push %rdx
5: 51 push %rcx
6: 6a da pushq $0xffffffffffffffda
8: 41 50 push %r8
a: 41 51 push %r9
c: 41 52 push %r10
e: 41 53 push %r11
10: 48 83 ec 30 sub $0x30,%rsp
14: 65 4c 8b 1c 25 c0 d2 mov %gs:0xd2c0,%r11
1b: 00 00
1d: 41 f7 03 df 39 08 90 testl $0x900839df,(%r11)
24: 0f 85 a5 00 00 00 jne 0xcf
2a: 50 push %rax
2b:* ff 15 9c 95 d0 ff callq *-0x2f6a64(%rip) #
0xffffffffffd095cd <-- trapping instruction
31: 58 pop %rax
32: 48 3d 4c 01 00 00 cmp $0x14c,%rax
38: 77 0f ja 0x49
3a: 4c 89 d1 mov %r10,%rcx
3d: ff .byte 0xff
3e: 14 c5 adc $0xc5,%al
so the original 'cli' was replaced with the pv call but to me the offset
looks a bit off, no? Shouldn't it always be positive?
-boris
^ permalink raw reply
* Re: [PATCH v1 00/27] x86: PIE support and option to extend KASLR randomization
From: Tom Lendacky @ 2017-10-12 16:28 UTC (permalink / raw)
To: Thomas Garnier
Cc: Nicolas Pitre, Michal Hocko, linux-doc, Daniel Micay,
Radim Krčmář, Peter Zijlstra, Christopher Li,
Jan H . Schönherr, Alexei Starovoitov, virtualization,
David Howells, Paul Gortmaker, Waiman Long, Pavel Machek,
H . Peter Anvin, Kernel Hardening, Christoph Lameter,
Thomas Gleixner, the arch/x86 maintainers, Herbert Xu,
Daniel Borkmann, Jonathan Corbet
In-Reply-To: <CAJcbSZEzEGuby155zQZJqEbi1EO1v2bue+DB1oAXZfwMVOoySg@mail.gmail.com>
On 10/12/2017 10:34 AM, Thomas Garnier wrote:
> On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky <thomas.lendacky@amd.com> wrote:
>> On 10/11/2017 3:30 PM, Thomas Garnier wrote:
>>> Changes:
>>> - patch v1:
>>> - Simplify ftrace implementation.
>>> - Use gcc mstack-protector-guard-reg=%gs with PIE when possible.
>>> - rfc v3:
>>> - Use --emit-relocs instead of -pie to reduce dynamic relocation space on
>>> mapped memory. It also simplifies the relocation process.
>>> - Move the start the module section next to the kernel. Remove the need for
>>> -mcmodel=large on modules. Extends module space from 1 to 2G maximum.
>>> - Support for XEN PVH as 32-bit relocations can be ignored with
>>> --emit-relocs.
>>> - Support for GOT relocations previously done automatically with -pie.
>>> - Remove need for dynamic PLT in modules.
>>> - Support dymamic GOT for modules.
>>> - rfc v2:
>>> - Add support for global stack cookie while compiler default to fs without
>>> mcmodel=kernel
>>> - Change patch 7 to correctly jump out of the identity mapping on kexec load
>>> preserve.
>>>
>>> These patches make the changes necessary to build the kernel as Position
>>> Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
>>> the top 2G of the virtual address space. It allows to optionally extend the
>>> KASLR randomization range from 1G to 3G.
>>
>> Hi Thomas,
>>
>> I've applied your patches so that I can verify that SME works with PIE.
>> Unfortunately, I'm running into build warnings and errors when I enable
>> PIE.
>>
>> With CONFIG_STACK_VALIDATION=y I receive lots of messages like this:
>>
>> drivers/scsi/libfc/fc_exch.o: warning: objtool: fc_destroy_exch_mgr()+0x0: call without frame pointer save/setup
>>
>> Disabling CONFIG_STACK_VALIDATION suppresses those.
>
> I ran into that, I plan to fix it in the next iteration.
>
>>
>> But near the end of the build, I receive errors like this:
>>
>> arch/x86/kernel/setup.o: In function `dump_kernel_offset':
>> .../arch/x86/kernel/setup.c:801:(.text+0x32): relocation truncated to fit: R_X86_64_32S against symbol `_text' defined in .text section in .tmp_vmlinux1
>> .
>> . about 10 more of the above type messages
>> .
>> make: *** [vmlinux] Error 1
>> Error building kernel, exiting
>>
>> Are there any config options that should or should not be enabled when
>> building with PIE enabled? Is there a compiler requirement for PIE (I'm
>> using gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5))?
>
> I never ran into these ones and I tested compilers older and newer.
> What was your exact configuration?
I'll send you the config in a separate email.
Thanks,
Tom
>
>>
>> Thanks,
>> Tom
>>
>>>
>>> Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler
>>> changes, PIE support and KASLR in general. Thanks to Roland McGrath on his
>>> feedback for using -pie versus --emit-relocs and details on compiler code
>>> generation.
>>>
>>> The patches:
>>> - 1-3, 5-1#, 17-18: Change in assembly code to be PIE compliant.
>>> - 4: Add a new _ASM_GET_PTR macro to fetch a symbol address generically.
>>> - 14: Adapt percpu design to work correctly when PIE is enabled.
>>> - 15: Provide an option to default visibility to hidden except for key symbols.
>>> It removes errors between compilation units.
>>> - 16: Adapt relocation tool to handle PIE binary correctly.
>>> - 19: Add support for global cookie.
>>> - 20: Support ftrace with PIE (used on Ubuntu config).
>>> - 21: Fix incorrect address marker on dump_pagetables.
>>> - 22: Add option to move the module section just after the kernel.
>>> - 23: Adapt module loading to support PIE with dynamic GOT.
>>> - 24: Make the GOT read-only.
>>> - 25: Add the CONFIG_X86_PIE option (off by default).
>>> - 26: Adapt relocation tool to generate a 64-bit relocation table.
>>> - 27: Add the CONFIG_RANDOMIZE_BASE_LARGE option to increase relocation range
>>> from 1G to 3G (off by default).
>>>
>>> Performance/Size impact:
>>>
>>> Size of vmlinux (Default configuration):
>>> File size:
>>> - PIE disabled: +0.000031%
>>> - PIE enabled: -3.210% (less relocations)
>>> .text section:
>>> - PIE disabled: +0.000644%
>>> - PIE enabled: +0.837%
>>>
>>> Size of vmlinux (Ubuntu configuration):
>>> File size:
>>> - PIE disabled: -0.201%
>>> - PIE enabled: -0.082%
>>> .text section:
>>> - PIE disabled: same
>>> - PIE enabled: +1.319%
>>>
>>> Size of vmlinux (Default configuration + ORC):
>>> File size:
>>> - PIE enabled: -3.167%
>>> .text section:
>>> - PIE enabled: +0.814%
>>>
>>> Size of vmlinux (Ubuntu configuration + ORC):
>>> File size:
>>> - PIE enabled: -3.167%
>>> .text section:
>>> - PIE enabled: +1.26%
>>>
>>> The size increase is mainly due to not having access to the 32-bit signed
>>> relocation that can be used with mcmodel=kernel. A small part is due to reduced
>>> optimization for PIE code. This bug [1] was opened with gcc to provide a better
>>> code generation for kernel PIE.
>>>
>>> Hackbench (50% and 1600% on thread/process for pipe/sockets):
>>> - PIE disabled: no significant change (avg +0.1% on latest test).
>>> - PIE enabled: between -0.50% to +0.86% in average (default and Ubuntu config).
>>>
>>> slab_test (average of 10 runs):
>>> - PIE disabled: no significant change (-2% on latest run, likely noise).
>>> - PIE enabled: between -1% and +0.8% on latest runs.
>>>
>>> Kernbench (average of 10 Half and Optimal runs):
>>> Elapsed Time:
>>> - PIE disabled: no significant change (avg -0.239%)
>>> - PIE enabled: average +0.07%
>>> System Time:
>>> - PIE disabled: no significant change (avg -0.277%)
>>> - PIE enabled: average +0.7%
>>>
>>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303
>>>
>>> diffstat:
>>> Documentation/x86/x86_64/mm.txt | 3
>>> arch/x86/Kconfig | 43 ++++++
>>> arch/x86/Makefile | 40 +++++
>>> arch/x86/boot/boot.h | 2
>>> arch/x86/boot/compressed/Makefile | 5
>>> arch/x86/boot/compressed/misc.c | 10 +
>>> arch/x86/crypto/aes-x86_64-asm_64.S | 45 ++++--
>>> arch/x86/crypto/aesni-intel_asm.S | 14 +-
>>> arch/x86/crypto/aesni-intel_avx-x86_64.S | 6
>>> arch/x86/crypto/camellia-aesni-avx-asm_64.S | 42 +++---
>>> arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 44 +++---
>>> arch/x86/crypto/camellia-x86_64-asm_64.S | 8 -
>>> arch/x86/crypto/cast5-avx-x86_64-asm_64.S | 50 ++++---
>>> arch/x86/crypto/cast6-avx-x86_64-asm_64.S | 44 +++---
>>> arch/x86/crypto/des3_ede-asm_64.S | 96 +++++++++-----
>>> arch/x86/crypto/ghash-clmulni-intel_asm.S | 4
>>> arch/x86/crypto/glue_helper-asm-avx.S | 4
>>> arch/x86/crypto/glue_helper-asm-avx2.S | 6
>>> arch/x86/entry/entry_32.S | 3
>>> arch/x86/entry/entry_64.S | 29 ++--
>>> arch/x86/include/asm/asm.h | 13 +
>>> arch/x86/include/asm/bug.h | 2
>>> arch/x86/include/asm/ftrace.h | 6
>>> arch/x86/include/asm/jump_label.h | 8 -
>>> arch/x86/include/asm/kvm_host.h | 6
>>> arch/x86/include/asm/module.h | 11 +
>>> arch/x86/include/asm/page_64_types.h | 9 +
>>> arch/x86/include/asm/paravirt_types.h | 12 +
>>> arch/x86/include/asm/percpu.h | 25 ++-
>>> arch/x86/include/asm/pgtable_64_types.h | 6
>>> arch/x86/include/asm/pm-trace.h | 2
>>> arch/x86/include/asm/processor.h | 12 +
>>> arch/x86/include/asm/sections.h | 8 +
>>> arch/x86/include/asm/setup.h | 2
>>> arch/x86/include/asm/stackprotector.h | 19 ++
>>> arch/x86/kernel/acpi/wakeup_64.S | 31 ++--
>>> arch/x86/kernel/asm-offsets.c | 3
>>> arch/x86/kernel/asm-offsets_32.c | 3
>>> arch/x86/kernel/asm-offsets_64.c | 3
>>> arch/x86/kernel/cpu/common.c | 7 -
>>> arch/x86/kernel/cpu/microcode/core.c | 4
>>> arch/x86/kernel/ftrace.c | 42 +++++-
>>> arch/x86/kernel/head64.c | 32 +++-
>>> arch/x86/kernel/head_32.S | 3
>>> arch/x86/kernel/head_64.S | 41 +++++-
>>> arch/x86/kernel/kvm.c | 6
>>> arch/x86/kernel/module.c | 182 ++++++++++++++++++++++++++-
>>> arch/x86/kernel/module.lds | 3
>>> arch/x86/kernel/process.c | 5
>>> arch/x86/kernel/relocate_kernel_64.S | 8 -
>>> arch/x86/kernel/setup_percpu.c | 2
>>> arch/x86/kernel/vmlinux.lds.S | 13 +
>>> arch/x86/kvm/svm.c | 4
>>> arch/x86/lib/cmpxchg16b_emu.S | 8 -
>>> arch/x86/mm/dump_pagetables.c | 11 +
>>> arch/x86/power/hibernate_asm_64.S | 4
>>> arch/x86/tools/relocs.c | 170 +++++++++++++++++++++++--
>>> arch/x86/tools/relocs.h | 4
>>> arch/x86/tools/relocs_common.c | 15 +-
>>> arch/x86/xen/xen-asm.S | 12 -
>>> arch/x86/xen/xen-head.S | 9 -
>>> arch/x86/xen/xen-pvh.S | 13 +
>>> drivers/base/firmware_class.c | 4
>>> include/asm-generic/sections.h | 6
>>> include/asm-generic/vmlinux.lds.h | 12 +
>>> include/linux/compiler.h | 8 +
>>> init/Kconfig | 9 +
>>> kernel/kallsyms.c | 16 +-
>>> kernel/trace/trace.h | 4
>>> lib/dynamic_debug.c | 4
>>> 70 files changed, 1032 insertions(+), 308 deletions(-)
>>>
>
>
>
^ permalink raw reply
* Re: [PATCH v1 00/27] x86: PIE support and option to extend KASLR randomization
From: Markus Trippelsdorf @ 2017-10-12 15:51 UTC (permalink / raw)
To: Thomas Garnier
Cc: Nicolas Pitre, Michal Hocko, Radim Krčmář,
linux-doc, Daniel Micay, Len Brown, Peter Zijlstra,
Christopher Li, Jan H . Schönherr, Alexei Starovoitov,
virtualization, David Howells, Paul Gortmaker, Waiman Long,
Pavel Machek, H . Peter Anvin, Kernel Hardening,
Christoph Lameter, Thomas Gleixner, the arch/x86 maintainers,
Herbert Xu, Daniel Borkmann
In-Reply-To: <CAJcbSZEzEGuby155zQZJqEbi1EO1v2bue+DB1oAXZfwMVOoySg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4354 bytes --]
On 2017.10.12 at 08:34 -0700, Thomas Garnier wrote:
> On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky <thomas.lendacky@amd.com> wrote:
> > On 10/11/2017 3:30 PM, Thomas Garnier wrote:
> >> Changes:
> >> - patch v1:
> >> - Simplify ftrace implementation.
> >> - Use gcc mstack-protector-guard-reg=%gs with PIE when possible.
> >> - rfc v3:
> >> - Use --emit-relocs instead of -pie to reduce dynamic relocation space on
> >> mapped memory. It also simplifies the relocation process.
> >> - Move the start the module section next to the kernel. Remove the need for
> >> -mcmodel=large on modules. Extends module space from 1 to 2G maximum.
> >> - Support for XEN PVH as 32-bit relocations can be ignored with
> >> --emit-relocs.
> >> - Support for GOT relocations previously done automatically with -pie.
> >> - Remove need for dynamic PLT in modules.
> >> - Support dymamic GOT for modules.
> >> - rfc v2:
> >> - Add support for global stack cookie while compiler default to fs without
> >> mcmodel=kernel
> >> - Change patch 7 to correctly jump out of the identity mapping on kexec load
> >> preserve.
> >>
> >> These patches make the changes necessary to build the kernel as Position
> >> Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
> >> the top 2G of the virtual address space. It allows to optionally extend the
> >> KASLR randomization range from 1G to 3G.
> >
> > Hi Thomas,
> >
> > I've applied your patches so that I can verify that SME works with PIE.
> > Unfortunately, I'm running into build warnings and errors when I enable
> > PIE.
> >
> > With CONFIG_STACK_VALIDATION=y I receive lots of messages like this:
> >
> > drivers/scsi/libfc/fc_exch.o: warning: objtool: fc_destroy_exch_mgr()+0x0: call without frame pointer save/setup
> >
> > Disabling CONFIG_STACK_VALIDATION suppresses those.
>
> I ran into that, I plan to fix it in the next iteration.
>
> >
> > But near the end of the build, I receive errors like this:
> >
> > arch/x86/kernel/setup.o: In function `dump_kernel_offset':
> > .../arch/x86/kernel/setup.c:801:(.text+0x32): relocation truncated to fit: R_X86_64_32S against symbol `_text' defined in .text section in .tmp_vmlinux1
> > .
> > . about 10 more of the above type messages
> > .
> > make: *** [vmlinux] Error 1
> > Error building kernel, exiting
> >
> > Are there any config options that should or should not be enabled when
> > building with PIE enabled? Is there a compiler requirement for PIE (I'm
> > using gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5))?
>
> I never ran into these ones and I tested compilers older and newer.
> What was your exact configuration?
I get with gcc trunk and CONFIG_RANDOMIZE_BASE_LARGE=y:
...
MODPOST vmlinux.o
ld: failed to convert GOTPCREL relocation; relink with --no-relax
and after adding --no-relax to vmlinux_link() in scripts/link-vmlinux.sh:
MODPOST vmlinux.o
virt/kvm/vfio.o: In function `kvm_vfio_update_coherency.isra.4':
vfio.c:(.text+0x63): relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `vfio_external_check_extension'
virt/kvm/vfio.o: In function `kvm_vfio_destroy':
vfio.c:(.text+0xf7): relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `vfio_group_set_kvm'
vfio.c:(.text+0x10a): relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `vfio_group_put_external_user'
virt/kvm/vfio.o: In function `kvm_vfio_set_attr':
vfio.c:(.text+0x2bc): relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `vfio_external_group_match_file'
vfio.c:(.text+0x307): relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `vfio_group_set_kvm'
vfio.c:(.text+0x31a): relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `vfio_group_put_external_user'
vfio.c:(.text+0x3b9): relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `vfio_group_get_external_user'
vfio.c:(.text+0x462): relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `vfio_group_set_kvm'
vfio.c:(.text+0x4bd): relocation truncated to fit: R_X86_64_PLT32 against undefined symbol `vfio_group_put_external_user'
make: *** [Makefile:1000: vmlinux] Error 1
Works fine with CONFIG_RANDOMIZE_BASE_LARGE unset.
--
Markus
[-- Attachment #2: config.gz --]
[-- Type: application/x-gunzip, Size: 19847 bytes --]
[-- Attachment #3: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v1 00/27] x86: PIE support and option to extend KASLR randomization
From: Thomas Garnier via Virtualization @ 2017-10-12 15:34 UTC (permalink / raw)
To: Tom Lendacky
Cc: Nicolas Pitre, Michal Hocko, linux-doc, Daniel Micay,
Radim Krčmář, Peter Zijlstra, Christopher Li,
Jan H . Schönherr, Alexei Starovoitov, virtualization,
David Howells, Paul Gortmaker, Waiman Long, Pavel Machek,
H . Peter Anvin, Kernel Hardening, Christoph Lameter,
Thomas Gleixner, the arch/x86 maintainers, Herbert Xu,
Daniel Borkmann, Jonathan Corbet
In-Reply-To: <22e56a56-978a-738f-52b9-2d0c17839c9e@amd.com>
On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky <thomas.lendacky@amd.com> wrote:
> On 10/11/2017 3:30 PM, Thomas Garnier wrote:
>> Changes:
>> - patch v1:
>> - Simplify ftrace implementation.
>> - Use gcc mstack-protector-guard-reg=%gs with PIE when possible.
>> - rfc v3:
>> - Use --emit-relocs instead of -pie to reduce dynamic relocation space on
>> mapped memory. It also simplifies the relocation process.
>> - Move the start the module section next to the kernel. Remove the need for
>> -mcmodel=large on modules. Extends module space from 1 to 2G maximum.
>> - Support for XEN PVH as 32-bit relocations can be ignored with
>> --emit-relocs.
>> - Support for GOT relocations previously done automatically with -pie.
>> - Remove need for dynamic PLT in modules.
>> - Support dymamic GOT for modules.
>> - rfc v2:
>> - Add support for global stack cookie while compiler default to fs without
>> mcmodel=kernel
>> - Change patch 7 to correctly jump out of the identity mapping on kexec load
>> preserve.
>>
>> These patches make the changes necessary to build the kernel as Position
>> Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
>> the top 2G of the virtual address space. It allows to optionally extend the
>> KASLR randomization range from 1G to 3G.
>
> Hi Thomas,
>
> I've applied your patches so that I can verify that SME works with PIE.
> Unfortunately, I'm running into build warnings and errors when I enable
> PIE.
>
> With CONFIG_STACK_VALIDATION=y I receive lots of messages like this:
>
> drivers/scsi/libfc/fc_exch.o: warning: objtool: fc_destroy_exch_mgr()+0x0: call without frame pointer save/setup
>
> Disabling CONFIG_STACK_VALIDATION suppresses those.
I ran into that, I plan to fix it in the next iteration.
>
> But near the end of the build, I receive errors like this:
>
> arch/x86/kernel/setup.o: In function `dump_kernel_offset':
> .../arch/x86/kernel/setup.c:801:(.text+0x32): relocation truncated to fit: R_X86_64_32S against symbol `_text' defined in .text section in .tmp_vmlinux1
> .
> . about 10 more of the above type messages
> .
> make: *** [vmlinux] Error 1
> Error building kernel, exiting
>
> Are there any config options that should or should not be enabled when
> building with PIE enabled? Is there a compiler requirement for PIE (I'm
> using gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5))?
I never ran into these ones and I tested compilers older and newer.
What was your exact configuration?
>
> Thanks,
> Tom
>
>>
>> Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler
>> changes, PIE support and KASLR in general. Thanks to Roland McGrath on his
>> feedback for using -pie versus --emit-relocs and details on compiler code
>> generation.
>>
>> The patches:
>> - 1-3, 5-1#, 17-18: Change in assembly code to be PIE compliant.
>> - 4: Add a new _ASM_GET_PTR macro to fetch a symbol address generically.
>> - 14: Adapt percpu design to work correctly when PIE is enabled.
>> - 15: Provide an option to default visibility to hidden except for key symbols.
>> It removes errors between compilation units.
>> - 16: Adapt relocation tool to handle PIE binary correctly.
>> - 19: Add support for global cookie.
>> - 20: Support ftrace with PIE (used on Ubuntu config).
>> - 21: Fix incorrect address marker on dump_pagetables.
>> - 22: Add option to move the module section just after the kernel.
>> - 23: Adapt module loading to support PIE with dynamic GOT.
>> - 24: Make the GOT read-only.
>> - 25: Add the CONFIG_X86_PIE option (off by default).
>> - 26: Adapt relocation tool to generate a 64-bit relocation table.
>> - 27: Add the CONFIG_RANDOMIZE_BASE_LARGE option to increase relocation range
>> from 1G to 3G (off by default).
>>
>> Performance/Size impact:
>>
>> Size of vmlinux (Default configuration):
>> File size:
>> - PIE disabled: +0.000031%
>> - PIE enabled: -3.210% (less relocations)
>> .text section:
>> - PIE disabled: +0.000644%
>> - PIE enabled: +0.837%
>>
>> Size of vmlinux (Ubuntu configuration):
>> File size:
>> - PIE disabled: -0.201%
>> - PIE enabled: -0.082%
>> .text section:
>> - PIE disabled: same
>> - PIE enabled: +1.319%
>>
>> Size of vmlinux (Default configuration + ORC):
>> File size:
>> - PIE enabled: -3.167%
>> .text section:
>> - PIE enabled: +0.814%
>>
>> Size of vmlinux (Ubuntu configuration + ORC):
>> File size:
>> - PIE enabled: -3.167%
>> .text section:
>> - PIE enabled: +1.26%
>>
>> The size increase is mainly due to not having access to the 32-bit signed
>> relocation that can be used with mcmodel=kernel. A small part is due to reduced
>> optimization for PIE code. This bug [1] was opened with gcc to provide a better
>> code generation for kernel PIE.
>>
>> Hackbench (50% and 1600% on thread/process for pipe/sockets):
>> - PIE disabled: no significant change (avg +0.1% on latest test).
>> - PIE enabled: between -0.50% to +0.86% in average (default and Ubuntu config).
>>
>> slab_test (average of 10 runs):
>> - PIE disabled: no significant change (-2% on latest run, likely noise).
>> - PIE enabled: between -1% and +0.8% on latest runs.
>>
>> Kernbench (average of 10 Half and Optimal runs):
>> Elapsed Time:
>> - PIE disabled: no significant change (avg -0.239%)
>> - PIE enabled: average +0.07%
>> System Time:
>> - PIE disabled: no significant change (avg -0.277%)
>> - PIE enabled: average +0.7%
>>
>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303
>>
>> diffstat:
>> Documentation/x86/x86_64/mm.txt | 3
>> arch/x86/Kconfig | 43 ++++++
>> arch/x86/Makefile | 40 +++++
>> arch/x86/boot/boot.h | 2
>> arch/x86/boot/compressed/Makefile | 5
>> arch/x86/boot/compressed/misc.c | 10 +
>> arch/x86/crypto/aes-x86_64-asm_64.S | 45 ++++--
>> arch/x86/crypto/aesni-intel_asm.S | 14 +-
>> arch/x86/crypto/aesni-intel_avx-x86_64.S | 6
>> arch/x86/crypto/camellia-aesni-avx-asm_64.S | 42 +++---
>> arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 44 +++---
>> arch/x86/crypto/camellia-x86_64-asm_64.S | 8 -
>> arch/x86/crypto/cast5-avx-x86_64-asm_64.S | 50 ++++---
>> arch/x86/crypto/cast6-avx-x86_64-asm_64.S | 44 +++---
>> arch/x86/crypto/des3_ede-asm_64.S | 96 +++++++++-----
>> arch/x86/crypto/ghash-clmulni-intel_asm.S | 4
>> arch/x86/crypto/glue_helper-asm-avx.S | 4
>> arch/x86/crypto/glue_helper-asm-avx2.S | 6
>> arch/x86/entry/entry_32.S | 3
>> arch/x86/entry/entry_64.S | 29 ++--
>> arch/x86/include/asm/asm.h | 13 +
>> arch/x86/include/asm/bug.h | 2
>> arch/x86/include/asm/ftrace.h | 6
>> arch/x86/include/asm/jump_label.h | 8 -
>> arch/x86/include/asm/kvm_host.h | 6
>> arch/x86/include/asm/module.h | 11 +
>> arch/x86/include/asm/page_64_types.h | 9 +
>> arch/x86/include/asm/paravirt_types.h | 12 +
>> arch/x86/include/asm/percpu.h | 25 ++-
>> arch/x86/include/asm/pgtable_64_types.h | 6
>> arch/x86/include/asm/pm-trace.h | 2
>> arch/x86/include/asm/processor.h | 12 +
>> arch/x86/include/asm/sections.h | 8 +
>> arch/x86/include/asm/setup.h | 2
>> arch/x86/include/asm/stackprotector.h | 19 ++
>> arch/x86/kernel/acpi/wakeup_64.S | 31 ++--
>> arch/x86/kernel/asm-offsets.c | 3
>> arch/x86/kernel/asm-offsets_32.c | 3
>> arch/x86/kernel/asm-offsets_64.c | 3
>> arch/x86/kernel/cpu/common.c | 7 -
>> arch/x86/kernel/cpu/microcode/core.c | 4
>> arch/x86/kernel/ftrace.c | 42 +++++-
>> arch/x86/kernel/head64.c | 32 +++-
>> arch/x86/kernel/head_32.S | 3
>> arch/x86/kernel/head_64.S | 41 +++++-
>> arch/x86/kernel/kvm.c | 6
>> arch/x86/kernel/module.c | 182 ++++++++++++++++++++++++++-
>> arch/x86/kernel/module.lds | 3
>> arch/x86/kernel/process.c | 5
>> arch/x86/kernel/relocate_kernel_64.S | 8 -
>> arch/x86/kernel/setup_percpu.c | 2
>> arch/x86/kernel/vmlinux.lds.S | 13 +
>> arch/x86/kvm/svm.c | 4
>> arch/x86/lib/cmpxchg16b_emu.S | 8 -
>> arch/x86/mm/dump_pagetables.c | 11 +
>> arch/x86/power/hibernate_asm_64.S | 4
>> arch/x86/tools/relocs.c | 170 +++++++++++++++++++++++--
>> arch/x86/tools/relocs.h | 4
>> arch/x86/tools/relocs_common.c | 15 +-
>> arch/x86/xen/xen-asm.S | 12 -
>> arch/x86/xen/xen-head.S | 9 -
>> arch/x86/xen/xen-pvh.S | 13 +
>> drivers/base/firmware_class.c | 4
>> include/asm-generic/sections.h | 6
>> include/asm-generic/vmlinux.lds.h | 12 +
>> include/linux/compiler.h | 8 +
>> init/Kconfig | 9 +
>> kernel/kallsyms.c | 16 +-
>> kernel/trace/trace.h | 4
>> lib/dynamic_debug.c | 4
>> 70 files changed, 1032 insertions(+), 308 deletions(-)
>>
--
Thomas
^ permalink raw reply
* Re: [PATCH v16 5/5] virtio-balloon: VIRTIO_BALLOON_F_CTRL_VQ
From: Wei Wang @ 2017-10-12 3:54 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: aarcange@redhat.com, virtio-dev@lists.oasis-open.org,
kvm@vger.kernel.org, mawilcox@microsoft.com,
qemu-devel@nongnu.org, amit.shah@redhat.com,
liliang.opensource@gmail.com, linux-kernel@vger.kernel.org,
willy@infradead.org, virtualization@lists.linux-foundation.org,
linux-mm@kvack.org, yang.zhang.wz@gmail.com, quan.xu@aliyun.com,
cornelia.huck@de.ibm.com, pbonzini@redhat.com,
akpm@linux-foundation.org, mhocko
In-Reply-To: <20171011161912-mutt-send-email-mst@kernel.org>
On 10/11/2017 09:49 PM, Michael S. Tsirkin wrote:
> On Wed, Oct 11, 2017 at 02:03:20PM +0800, Wei Wang wrote:
>> On 10/10/2017 11:15 PM, Michael S. Tsirkin wrote:
>>> On Mon, Oct 02, 2017 at 04:38:01PM +0000, Wang, Wei W wrote:
>>>> On Sunday, October 1, 2017 11:19 AM, Michael S. Tsirkin wrote:
>>>>> On Sat, Sep 30, 2017 at 12:05:54PM +0800, Wei Wang wrote:
>>>>>> +static void ctrlq_send_cmd(struct virtio_balloon *vb,
>>>>>> + struct virtio_balloon_ctrlq_cmd *cmd,
>>>>>> + bool inbuf)
>>>>>> +{
>>>>>> + struct virtqueue *vq = vb->ctrl_vq;
>>>>>> +
>>>>>> + ctrlq_add_cmd(vq, cmd, inbuf);
>>>>>> + if (!inbuf) {
>>>>>> + /*
>>>>>> + * All the input cmd buffers are replenished here.
>>>>>> + * This is necessary because the input cmd buffers are lost
>>>>>> + * after live migration. The device needs to rewind all of
>>>>>> + * them from the ctrl_vq.
>>>>> Confused. Live migration somehow loses state? Why is that and why is it a good
>>>>> idea? And how do you know this is migration even?
>>>>> Looks like all you know is you got free page end. Could be any reason for this.
>>>> I think this would be something that the current live migration lacks - what the
>>>> device read from the vq is not transferred during live migration, an example is the
>>>> stat_vq_elem:
>>>> Line 476 at https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c
>>> This does not touch guest memory though it just manipulates
>>> internal state to make it easier to migrate.
>>> It's transparent to guest as migration should be.
>>>
>>>> For all the things that are added to the vq and need to be held by the device
>>>> to use later need to consider the situation that live migration might happen at any
>>>> time and they need to be re-taken from the vq by the device on the destination
>>>> machine.
>>>>
>>>> So, even without this live migration optimization feature, I think all the things that are
>>>> added to the vq for the device to hold, need a way for the device to rewind back from
>>>> the vq - re-adding all the elements to the vq is a trick to keep a record of all of them
>>>> on the vq so that the device side rewinding can work.
>>>>
>>>> Please let me know if anything is missed or if you have other suggestions.
>>> IMO migration should pass enough data source to destination for
>>> destination to continue where source left off without guest help.
>>>
>> I'm afraid it would be difficult to pass the entire VirtQueueElement to the
>> destination. I think
>> that would also be the reason that stats_vq_elem chose to rewind from the
>> guest vq, which re-do the
>> virtqueue_pop() --> virtqueue_map_desc() steps (the QEMU virtual address to
>> the guest physical
>> address relationship may be changed on the destination).
> Yes but note how that rewind does not involve modifying the ring.
> It just rolls back some indices.
Yes, it rolls back the indices, then the following
virtio_balloon_receive_stats()
can re-pop out the previous entry given by the guest.
Recall how stats_vq_elem works: there is only one stats buffer, which is
used by the
guest to report stats, and also used by the host to ask the guest for
stats report.
So the host can roll back one previous entry and what it gets will
always be stat_vq_elem.
Our case is a little more complex than that - we have both free_page_cmd_in
(for host to guest command) and free_page_cmd_out (for guest to host
command) buffer
passed via ctrl_vq. When the host rolls back one entry, it may get the
free_page_cmd_out
buffer which can't be used as the host to guest buffer (i.e.
free_page_elem held by the device).
So a trick in the driver is to refill the free_page_cmd_in buffer every
time after the free_page_cmd_out
was sent to the host, so that when the host rewind one previous entry,
it can always get the
free_page_cmd_in buffer (may be not a very nice method).
>
>> How about another direction which would be easier - using two 32-bit device
>> specific configuration registers,
>> Host2Guest and Guest2Host command registers, to replace the ctrlq for
>> command exchange:
>>
>> The flow can be as follows:
>>
>> 1) Before Host sending a StartCMD, it flushes the free_page_vq in case any
>> old free page hint is left there;
>> 2) Host writes StartCMD to the Host2Guest register, and notifies the guest;
>>
>> 3) Upon receiving a configuration notification, Guest reads the Host2Guest
>> register, and detaches all the used buffers from free_page_vq;
>> (then for each StartCMD, the free_page_vq will always have no obsolete free
>> page hints, right? )
>>
>> 4) Guest start report free pages:
>> 4.1) Host may actively write StopCMD to the Host2Guest register before
>> the guest finishes; or
>> 4.2) Guest finishes reporting, write StopCMD the Guest2HOST register,
>> which traps to QEMU, to stop.
>>
>>
>> Best,
>> Wei
> I am not sure it matters whether a VQ or the config are used to start/stop.
Not matters, in terms of the flushing issue. The config method could
avoid the above rewind issue.
> But I think flushing is very fragile. You will easily run into races
> if one of the actors gets out of sync and keeps adding data.
> I think adding an ID in the free vq stream is a more robust
> approach.
>
Adding ID to the free vq would need the device to distinguish whether it
receives an ID or a free page hint,
so an extra protocol is needed for the two sides to talk. Currently, we
directly assign the free page
address to desc->addr. With ID support, we would need to first allocate
buffer for the protocol header,
and add the free page address to the header, then desc->addr = &header.
How about putting the ID to the command path? This would avoid the above
trouble.
For example, using the 32-bit config registers:
first 16-bit: Command field
send 16-bit: ID field
Then, the working flow would look like this:
1) Host writes "Start, 1" to the Host2Guest register and notify;
2) Guest reads Host2Guest register, and ACKs by writing "Start, 1" to
Guest2Host register;
3) Guest starts report free pages;
4) Each time when the host receives a free page hint from the
free_page_vq, it compares the ID fields of
the Host2Guest and Guest2Host register. If matching, then filter out the
free page from the migration dirty bitmap,
otherwise, simply push back without doing the filtering.
Best,
Wei
^ permalink raw reply
* Re: [PATCH] virtio: avoid possible OOM lockup at virtballoon_oom_notify()
From: Wei Wang @ 2017-10-12 2:36 UTC (permalink / raw)
To: Tetsuo Handa, mst, mhocko; +Cc: linux-mm, virtualization
In-Reply-To: <1507632457-4611-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
On 10/10/2017 06:47 PM, Tetsuo Handa wrote:
> In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to
> serialize against fill_balloon(). But in fill_balloon(),
> alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is
> called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE]
> implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY
> is specified, this allocation attempt might indirectly depend on somebody
> else's __GFP_DIRECT_RECLAIM memory allocation. And such indirect
> __GFP_DIRECT_RECLAIM memory allocation might call leak_balloon() via
> virtballoon_oom_notify() via blocking_notifier_call_chain() callback via
> out_of_memory() when it reached __alloc_pages_may_oom() and held oom_lock
> mutex. Since vb->balloon_lock mutex is already held by fill_balloon(), it
> will cause OOM lockup. Thus, do not wait for vb->balloon_lock mutex if
> leak_balloon() is called from out_of_memory().
>
> Thread1 Thread2
> fill_balloon()
> takes a balloon_lock
> balloon_page_enqueue()
> alloc_page(GFP_HIGHUSER_MOVABLE)
> direct reclaim (__GFP_FS context) takes a fs lock
> waits for that fs lock alloc_page(GFP_NOFS)
> __alloc_pages_may_oom()
> takes the oom_lock
> out_of_memory()
> blocking_notifier_call_chain()
> leak_balloon()
> tries to take that balloon_lock and deadlocks
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
I think we could also use 'bool wait' to let the OOM use the traditional
leak_balloon code path,
which doesn't need memory allocation from xb_preload(). That is, inside
leak_balloon(), we can have
use_sg = virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_SG) & wait;
Reviewed-by: Wei Wang <wei.w.wang@intel.com>
> ---
> drivers/virtio/virtio_balloon.c | 16 +++++++++++-----
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index f0b3a0b..03e6078 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -192,7 +192,7 @@ static void release_pages_balloon(struct virtio_balloon *vb,
> }
> }
>
> -static unsigned leak_balloon(struct virtio_balloon *vb, size_t num)
> +static unsigned leak_balloon(struct virtio_balloon *vb, size_t num, bool wait)
> {
> unsigned num_freed_pages;
> struct page *page;
> @@ -202,7 +202,13 @@ static unsigned leak_balloon(struct virtio_balloon *vb, size_t num)
> /* We can only do one array worth at a time. */
> num = min(num, ARRAY_SIZE(vb->pfns));
>
> - mutex_lock(&vb->balloon_lock);
> + if (wait)
> + mutex_lock(&vb->balloon_lock);
> + else if (!mutex_trylock(&vb->balloon_lock)) {
> + pr_info("virtio_balloon: Unable to release %lu pages due to lock contention.\n",
> + (unsigned long) min(num, (size_t)vb->num_pages));
> + return 0;
> + }
> /* We can't release more pages than taken */
> num = min(num, (size_t)vb->num_pages);
> for (vb->num_pfns = 0; vb->num_pfns < num;
> @@ -367,7 +373,7 @@ static int virtballoon_oom_notify(struct notifier_block *self,
> return NOTIFY_OK;
>
> freed = parm;
> - num_freed_pages = leak_balloon(vb, oom_pages);
> + num_freed_pages = leak_balloon(vb, oom_pages, false);
> update_balloon_size(vb);
> *freed += num_freed_pages;
>
> @@ -395,7 +401,7 @@ static void update_balloon_size_func(struct work_struct *work)
> if (diff > 0)
> diff -= fill_balloon(vb, diff);
> else if (diff < 0)
> - diff += leak_balloon(vb, -diff);
> + diff += leak_balloon(vb, -diff, true);
> update_balloon_size(vb);
>
> if (diff)
> @@ -597,7 +603,7 @@ static void remove_common(struct virtio_balloon *vb)
> {
> /* There might be pages left in the balloon: free them. */
> while (vb->num_pages)
> - leak_balloon(vb, vb->num_pages);
> + leak_balloon(vb, vb->num_pages, true);
> update_balloon_size(vb);
>
> /* Now we reset the device so we can clean up the queues. */
^ permalink raw reply
* Re: [PATCH v1 00/27] x86: PIE support and option to extend KASLR randomization
From: Tom Lendacky @ 2017-10-11 21:34 UTC (permalink / raw)
To: Thomas Garnier, Herbert Xu, David S . Miller, Thomas Gleixner,
Ingo Molnar, H . Peter Anvin, Peter Zijlstra, Josh Poimboeuf,
Arnd Bergmann, Kees Cook, Andrey Ryabinin, Matthias Kaehlcke,
Andy Lutomirski, Kirill A . Shutemov, Borislav Petkov,
Rafael J . Wysocki, Len Brown, Pavel Machek, Juergen Gross,
Chris Wright, Alok Kataria, Rusty Russell, Tejun Heo,
Christoph Lameter
Cc: linux-arch, kvm, linux-pm, x86, linux-doc, linux-kernel,
virtualization, linux-sparse, linux-crypto, kernel-hardening,
xen-devel
In-Reply-To: <20171011203027.11248-1-thgarnie@google.com>
On 10/11/2017 3:30 PM, Thomas Garnier wrote:
> Changes:
> - patch v1:
> - Simplify ftrace implementation.
> - Use gcc mstack-protector-guard-reg=%gs with PIE when possible.
> - rfc v3:
> - Use --emit-relocs instead of -pie to reduce dynamic relocation space on
> mapped memory. It also simplifies the relocation process.
> - Move the start the module section next to the kernel. Remove the need for
> -mcmodel=large on modules. Extends module space from 1 to 2G maximum.
> - Support for XEN PVH as 32-bit relocations can be ignored with
> --emit-relocs.
> - Support for GOT relocations previously done automatically with -pie.
> - Remove need for dynamic PLT in modules.
> - Support dymamic GOT for modules.
> - rfc v2:
> - Add support for global stack cookie while compiler default to fs without
> mcmodel=kernel
> - Change patch 7 to correctly jump out of the identity mapping on kexec load
> preserve.
>
> These patches make the changes necessary to build the kernel as Position
> Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
> the top 2G of the virtual address space. It allows to optionally extend the
> KASLR randomization range from 1G to 3G.
Hi Thomas,
I've applied your patches so that I can verify that SME works with PIE.
Unfortunately, I'm running into build warnings and errors when I enable
PIE.
With CONFIG_STACK_VALIDATION=y I receive lots of messages like this:
drivers/scsi/libfc/fc_exch.o: warning: objtool: fc_destroy_exch_mgr()+0x0: call without frame pointer save/setup
Disabling CONFIG_STACK_VALIDATION suppresses those.
But near the end of the build, I receive errors like this:
arch/x86/kernel/setup.o: In function `dump_kernel_offset':
.../arch/x86/kernel/setup.c:801:(.text+0x32): relocation truncated to fit: R_X86_64_32S against symbol `_text' defined in .text section in .tmp_vmlinux1
.
. about 10 more of the above type messages
.
make: *** [vmlinux] Error 1
Error building kernel, exiting
Are there any config options that should or should not be enabled when
building with PIE enabled? Is there a compiler requirement for PIE (I'm
using gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5))?
Thanks,
Tom
>
> Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler
> changes, PIE support and KASLR in general. Thanks to Roland McGrath on his
> feedback for using -pie versus --emit-relocs and details on compiler code
> generation.
>
> The patches:
> - 1-3, 5-1#, 17-18: Change in assembly code to be PIE compliant.
> - 4: Add a new _ASM_GET_PTR macro to fetch a symbol address generically.
> - 14: Adapt percpu design to work correctly when PIE is enabled.
> - 15: Provide an option to default visibility to hidden except for key symbols.
> It removes errors between compilation units.
> - 16: Adapt relocation tool to handle PIE binary correctly.
> - 19: Add support for global cookie.
> - 20: Support ftrace with PIE (used on Ubuntu config).
> - 21: Fix incorrect address marker on dump_pagetables.
> - 22: Add option to move the module section just after the kernel.
> - 23: Adapt module loading to support PIE with dynamic GOT.
> - 24: Make the GOT read-only.
> - 25: Add the CONFIG_X86_PIE option (off by default).
> - 26: Adapt relocation tool to generate a 64-bit relocation table.
> - 27: Add the CONFIG_RANDOMIZE_BASE_LARGE option to increase relocation range
> from 1G to 3G (off by default).
>
> Performance/Size impact:
>
> Size of vmlinux (Default configuration):
> File size:
> - PIE disabled: +0.000031%
> - PIE enabled: -3.210% (less relocations)
> .text section:
> - PIE disabled: +0.000644%
> - PIE enabled: +0.837%
>
> Size of vmlinux (Ubuntu configuration):
> File size:
> - PIE disabled: -0.201%
> - PIE enabled: -0.082%
> .text section:
> - PIE disabled: same
> - PIE enabled: +1.319%
>
> Size of vmlinux (Default configuration + ORC):
> File size:
> - PIE enabled: -3.167%
> .text section:
> - PIE enabled: +0.814%
>
> Size of vmlinux (Ubuntu configuration + ORC):
> File size:
> - PIE enabled: -3.167%
> .text section:
> - PIE enabled: +1.26%
>
> The size increase is mainly due to not having access to the 32-bit signed
> relocation that can be used with mcmodel=kernel. A small part is due to reduced
> optimization for PIE code. This bug [1] was opened with gcc to provide a better
> code generation for kernel PIE.
>
> Hackbench (50% and 1600% on thread/process for pipe/sockets):
> - PIE disabled: no significant change (avg +0.1% on latest test).
> - PIE enabled: between -0.50% to +0.86% in average (default and Ubuntu config).
>
> slab_test (average of 10 runs):
> - PIE disabled: no significant change (-2% on latest run, likely noise).
> - PIE enabled: between -1% and +0.8% on latest runs.
>
> Kernbench (average of 10 Half and Optimal runs):
> Elapsed Time:
> - PIE disabled: no significant change (avg -0.239%)
> - PIE enabled: average +0.07%
> System Time:
> - PIE disabled: no significant change (avg -0.277%)
> - PIE enabled: average +0.7%
>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303
>
> diffstat:
> Documentation/x86/x86_64/mm.txt | 3
> arch/x86/Kconfig | 43 ++++++
> arch/x86/Makefile | 40 +++++
> arch/x86/boot/boot.h | 2
> arch/x86/boot/compressed/Makefile | 5
> arch/x86/boot/compressed/misc.c | 10 +
> arch/x86/crypto/aes-x86_64-asm_64.S | 45 ++++--
> arch/x86/crypto/aesni-intel_asm.S | 14 +-
> arch/x86/crypto/aesni-intel_avx-x86_64.S | 6
> arch/x86/crypto/camellia-aesni-avx-asm_64.S | 42 +++---
> arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 44 +++---
> arch/x86/crypto/camellia-x86_64-asm_64.S | 8 -
> arch/x86/crypto/cast5-avx-x86_64-asm_64.S | 50 ++++---
> arch/x86/crypto/cast6-avx-x86_64-asm_64.S | 44 +++---
> arch/x86/crypto/des3_ede-asm_64.S | 96 +++++++++-----
> arch/x86/crypto/ghash-clmulni-intel_asm.S | 4
> arch/x86/crypto/glue_helper-asm-avx.S | 4
> arch/x86/crypto/glue_helper-asm-avx2.S | 6
> arch/x86/entry/entry_32.S | 3
> arch/x86/entry/entry_64.S | 29 ++--
> arch/x86/include/asm/asm.h | 13 +
> arch/x86/include/asm/bug.h | 2
> arch/x86/include/asm/ftrace.h | 6
> arch/x86/include/asm/jump_label.h | 8 -
> arch/x86/include/asm/kvm_host.h | 6
> arch/x86/include/asm/module.h | 11 +
> arch/x86/include/asm/page_64_types.h | 9 +
> arch/x86/include/asm/paravirt_types.h | 12 +
> arch/x86/include/asm/percpu.h | 25 ++-
> arch/x86/include/asm/pgtable_64_types.h | 6
> arch/x86/include/asm/pm-trace.h | 2
> arch/x86/include/asm/processor.h | 12 +
> arch/x86/include/asm/sections.h | 8 +
> arch/x86/include/asm/setup.h | 2
> arch/x86/include/asm/stackprotector.h | 19 ++
> arch/x86/kernel/acpi/wakeup_64.S | 31 ++--
> arch/x86/kernel/asm-offsets.c | 3
> arch/x86/kernel/asm-offsets_32.c | 3
> arch/x86/kernel/asm-offsets_64.c | 3
> arch/x86/kernel/cpu/common.c | 7 -
> arch/x86/kernel/cpu/microcode/core.c | 4
> arch/x86/kernel/ftrace.c | 42 +++++-
> arch/x86/kernel/head64.c | 32 +++-
> arch/x86/kernel/head_32.S | 3
> arch/x86/kernel/head_64.S | 41 +++++-
> arch/x86/kernel/kvm.c | 6
> arch/x86/kernel/module.c | 182 ++++++++++++++++++++++++++-
> arch/x86/kernel/module.lds | 3
> arch/x86/kernel/process.c | 5
> arch/x86/kernel/relocate_kernel_64.S | 8 -
> arch/x86/kernel/setup_percpu.c | 2
> arch/x86/kernel/vmlinux.lds.S | 13 +
> arch/x86/kvm/svm.c | 4
> arch/x86/lib/cmpxchg16b_emu.S | 8 -
> arch/x86/mm/dump_pagetables.c | 11 +
> arch/x86/power/hibernate_asm_64.S | 4
> arch/x86/tools/relocs.c | 170 +++++++++++++++++++++++--
> arch/x86/tools/relocs.h | 4
> arch/x86/tools/relocs_common.c | 15 +-
> arch/x86/xen/xen-asm.S | 12 -
> arch/x86/xen/xen-head.S | 9 -
> arch/x86/xen/xen-pvh.S | 13 +
> drivers/base/firmware_class.c | 4
> include/asm-generic/sections.h | 6
> include/asm-generic/vmlinux.lds.h | 12 +
> include/linux/compiler.h | 8 +
> init/Kconfig | 9 +
> kernel/kallsyms.c | 16 +-
> kernel/trace/trace.h | 4
> lib/dynamic_debug.c | 4
> 70 files changed, 1032 insertions(+), 308 deletions(-)
>
^ permalink raw reply
* [PATCH v1 27/27] x86/kaslr: Add option to extend KASLR range from 1GB to 3GB
From: Thomas Garnier via Virtualization @ 2017-10-11 20:30 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
H . Peter Anvin, Peter Zijlstra, Josh Poimboeuf, Arnd Bergmann,
Thomas Garnier, Kees Cook, Andrey Ryabinin, Matthias Kaehlcke,
Tom Lendacky, Andy Lutomirski, Kirill A . Shutemov,
Borislav Petkov, Rafael J . Wysocki, Len Brown, Pavel Machek,
Juergen Gross, Chris Wright, Alok Kataria, Rusty Russell,
Tejun Heo
Cc: linux-arch, kvm, linux-pm, x86, linux-doc, linux-kernel,
virtualization, linux-sparse, linux-crypto, kernel-hardening,
xen-devel
In-Reply-To: <20171011203027.11248-1-thgarnie@google.com>
Add a new CONFIG_RANDOMIZE_BASE_LARGE option to benefit from PIE
support. It increases the KASLR range from 1GB to 3GB. The new range
stars at 0xffffffff00000000 just above the EFI memory region. This
option is off by default.
The boot code is adapted to create the appropriate page table spanning
three PUD pages.
The relocation table uses 64-bit integers generated with the updated
relocation tool with the large-reloc option.
Signed-off-by: Thomas Garnier <thgarnie@google.com>
---
arch/x86/Kconfig | 21 +++++++++++++++++++++
arch/x86/boot/compressed/Makefile | 5 +++++
arch/x86/boot/compressed/misc.c | 10 +++++++++-
arch/x86/include/asm/page_64_types.h | 9 +++++++++
arch/x86/kernel/head64.c | 15 ++++++++++++---
arch/x86/kernel/head_64.S | 11 ++++++++++-
6 files changed, 66 insertions(+), 5 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bbd28a46ab55..54627dd06348 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2155,6 +2155,27 @@ config X86_PIE
select DYNAMIC_MODULE_BASE
select MODULE_REL_CRCS if MODVERSIONS
+config RANDOMIZE_BASE_LARGE
+ bool "Increase the randomization range of the kernel image"
+ depends on X86_64 && RANDOMIZE_BASE
+ select X86_PIE
+ select X86_MODULE_PLTS if MODULES
+ default n
+ ---help---
+ Build the kernel as a Position Independent Executable (PIE) and
+ increase the available randomization range from 1GB to 3GB.
+
+ This option impacts performance on kernel CPU intensive workloads up
+ to 10% due to PIE generated code. Impact on user-mode processes and
+ typical usage would be significantly less (0.50% when you build the
+ kernel).
+
+ The kernel and modules will generate slightly more assembly (1 to 2%
+ increase on the .text sections). The vmlinux binary will be
+ significantly smaller due to less relocations.
+
+ If unsure say N
+
config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index 8a958274b54c..94dfee5a7cd2 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -112,7 +112,12 @@ $(obj)/vmlinux.bin: vmlinux FORCE
targets += $(patsubst $(obj)/%,%,$(vmlinux-objs-y)) vmlinux.bin.all vmlinux.relocs
+# Large randomization require bigger relocation table
+ifeq ($(CONFIG_RANDOMIZE_BASE_LARGE),y)
+CMD_RELOCS = arch/x86/tools/relocs --large-reloc
+else
CMD_RELOCS = arch/x86/tools/relocs
+endif
quiet_cmd_relocs = RELOCS $@
cmd_relocs = $(CMD_RELOCS) $< > $@;$(CMD_RELOCS) --abs-relocs $<
$(obj)/vmlinux.relocs: vmlinux FORCE
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index c14217cd0155..c1ac9f2e283d 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -169,10 +169,18 @@ void __puthex(unsigned long value)
}
#if CONFIG_X86_NEED_RELOCS
+
+/* Large randomization go lower than -2G and use large relocation table */
+#ifdef CONFIG_RANDOMIZE_BASE_LARGE
+typedef long rel_t;
+#else
+typedef int rel_t;
+#endif
+
static void handle_relocations(void *output, unsigned long output_len,
unsigned long virt_addr)
{
- int *reloc;
+ rel_t *reloc;
unsigned long delta, map, ptr;
unsigned long min_addr = (unsigned long)output;
unsigned long max_addr = min_addr + (VO___bss_start - VO__text);
diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x86/include/asm/page_64_types.h
index 3f5f08b010d0..6b65f846dd64 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -48,7 +48,11 @@
#define __PAGE_OFFSET __PAGE_OFFSET_BASE
#endif /* CONFIG_RANDOMIZE_MEMORY */
+#ifdef CONFIG_RANDOMIZE_BASE_LARGE
+#define __START_KERNEL_map _AC(0xffffffff00000000, UL)
+#else
#define __START_KERNEL_map _AC(0xffffffff80000000, UL)
+#endif /* CONFIG_RANDOMIZE_BASE_LARGE */
/* See Documentation/x86/x86_64/mm.txt for a description of the memory map. */
#ifdef CONFIG_X86_5LEVEL
@@ -65,9 +69,14 @@
* 512MiB by default, leaving 1.5GiB for modules once the page tables
* are fully set up. If kernel ASLR is configured, it can extend the
* kernel page table mapping, reducing the size of the modules area.
+ * On PIE, we relocate the binary 2G lower so add this extra space.
*/
#if defined(CONFIG_RANDOMIZE_BASE)
+#ifdef CONFIG_RANDOMIZE_BASE_LARGE
+#define KERNEL_IMAGE_SIZE (_AC(3, UL) * 1024 * 1024 * 1024)
+#else
#define KERNEL_IMAGE_SIZE (1024 * 1024 * 1024)
+#endif
#else
#define KERNEL_IMAGE_SIZE (512 * 1024 * 1024)
#endif
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index b6363f0d11a7..d603d0f5a40a 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -39,6 +39,7 @@ static unsigned int __initdata next_early_pgt;
pmdval_t early_pmd_flags = __PAGE_KERNEL_LARGE & ~(_PAGE_GLOBAL | _PAGE_NX);
#define __head __section(.head.text)
+#define pud_count(x) (((x + (PUD_SIZE - 1)) & ~(PUD_SIZE - 1)) >> PUD_SHIFT)
static void __head *fixup_pointer(void *ptr, unsigned long physaddr)
{
@@ -56,6 +57,8 @@ unsigned long __head notrace __startup_64(unsigned long physaddr,
{
unsigned long load_delta, *p;
unsigned long pgtable_flags;
+ unsigned long level3_kernel_start, level3_kernel_count;
+ unsigned long level3_fixmap_start;
pgdval_t *pgd;
p4dval_t *p4d;
pudval_t *pud;
@@ -83,6 +86,11 @@ unsigned long __head notrace __startup_64(unsigned long physaddr,
/* Include the SME encryption mask in the fixup value */
load_delta += sme_get_me_mask();
+ /* Look at the randomization spread to adapt page table used */
+ level3_kernel_start = pud_index(__START_KERNEL_map);
+ level3_kernel_count = pud_count(KERNEL_IMAGE_SIZE);
+ level3_fixmap_start = level3_kernel_start + level3_kernel_count;
+
/* Fixup the physical addresses in the page table */
pgd = fixup_pointer(&early_top_pgt, physaddr);
@@ -94,8 +102,9 @@ unsigned long __head notrace __startup_64(unsigned long physaddr,
}
pud = fixup_pointer(&level3_kernel_pgt, physaddr);
- pud[510] += load_delta;
- pud[511] += load_delta;
+ for (i = 0; i < level3_kernel_count; i++)
+ pud[level3_kernel_start + i] += load_delta;
+ pud[level3_fixmap_start] += load_delta;
pmd = fixup_pointer(level2_fixmap_pgt, physaddr);
pmd[506] += load_delta;
@@ -150,7 +159,7 @@ unsigned long __head notrace __startup_64(unsigned long physaddr,
*/
pmd = fixup_pointer(level2_kernel_pgt, physaddr);
- for (i = 0; i < PTRS_PER_PMD; i++) {
+ for (i = 0; i < PTRS_PER_PMD * level3_kernel_count; i++) {
if (pmd[i] & _PAGE_PRESENT)
pmd[i] += load_delta;
}
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index df5198e310fc..7918ffefc9c9 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -39,11 +39,15 @@
#define p4d_index(x) (((x) >> P4D_SHIFT) & (PTRS_PER_P4D-1))
#define pud_index(x) (((x) >> PUD_SHIFT) & (PTRS_PER_PUD-1))
+#define pud_count(x) (((x + (PUD_SIZE - 1)) & ~(PUD_SIZE - 1)) >> PUD_SHIFT)
PGD_PAGE_OFFSET = pgd_index(__PAGE_OFFSET_BASE)
PGD_START_KERNEL = pgd_index(__START_KERNEL_map)
L3_START_KERNEL = pud_index(__START_KERNEL_map)
+/* Adapt page table L3 space based on range of randomization */
+L3_KERNEL_ENTRY_COUNT = pud_count(KERNEL_IMAGE_SIZE)
+
.text
__HEAD
.code64
@@ -413,7 +417,12 @@ NEXT_PAGE(level4_kernel_pgt)
NEXT_PAGE(level3_kernel_pgt)
.fill L3_START_KERNEL,8,0
/* (2^48-(2*1024*1024*1024)-((2^39)*511))/(2^30) = 510 */
- .quad level2_kernel_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC
+ i = 0
+ .rept L3_KERNEL_ENTRY_COUNT
+ .quad level2_kernel_pgt - __START_KERNEL_map + _KERNPG_TABLE_NOENC \
+ + PAGE_SIZE*i
+ i = i + 1
+ .endr
.quad level2_fixmap_pgt - __START_KERNEL_map + _PAGE_TABLE_NOENC
NEXT_PAGE(level2_kernel_pgt)
--
2.15.0.rc0.271.g36b669edcc-goog
^ permalink raw reply related
* [PATCH v1 26/27] x86/relocs: Add option to generate 64-bit relocations
From: Thomas Garnier via Virtualization @ 2017-10-11 20:30 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
H . Peter Anvin, Peter Zijlstra, Josh Poimboeuf, Arnd Bergmann,
Thomas Garnier, Kees Cook, Andrey Ryabinin, Matthias Kaehlcke,
Tom Lendacky, Andy Lutomirski, Kirill A . Shutemov,
Borislav Petkov, Rafael J . Wysocki, Len Brown, Pavel Machek,
Juergen Gross, Chris Wright, Alok Kataria, Rusty Russell,
Tejun Heo
Cc: linux-arch, kvm, linux-pm, x86, linux-doc, linux-kernel,
virtualization, linux-sparse, linux-crypto, kernel-hardening,
xen-devel
In-Reply-To: <20171011203027.11248-1-thgarnie@google.com>
The x86 relocation tool generates a list of 32-bit signed integers. There
was no need to use 64-bit integers because all addresses where above the 2G
top of the memory.
This change add a large-reloc option to generate 64-bit unsigned integers.
It can be used when the kernel plan to go below the top 2G and 32-bit
integers are not enough.
Signed-off-by: Thomas Garnier <thgarnie@google.com>
---
arch/x86/tools/relocs.c | 60 +++++++++++++++++++++++++++++++++---------
arch/x86/tools/relocs.h | 4 +--
arch/x86/tools/relocs_common.c | 15 +++++++----
3 files changed, 60 insertions(+), 19 deletions(-)
diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index bc032ad88b22..e7497ea1fe76 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -12,8 +12,14 @@
static Elf_Ehdr ehdr;
+#if ELF_BITS == 64
+typedef uint64_t rel_off_t;
+#else
+typedef uint32_t rel_off_t;
+#endif
+
struct relocs {
- uint32_t *offset;
+ rel_off_t *offset;
unsigned long count;
unsigned long size;
};
@@ -684,7 +690,7 @@ static void print_absolute_relocs(void)
printf("\n");
}
-static void add_reloc(struct relocs *r, uint32_t offset)
+static void add_reloc(struct relocs *r, rel_off_t offset)
{
if (r->count == r->size) {
unsigned long newsize = r->size + 50000;
@@ -1058,26 +1064,48 @@ static void sort_relocs(struct relocs *r)
qsort(r->offset, r->count, sizeof(r->offset[0]), cmp_relocs);
}
-static int write32(uint32_t v, FILE *f)
+static int write32(rel_off_t rel, FILE *f)
{
- unsigned char buf[4];
+ unsigned char buf[sizeof(uint32_t)];
+ uint32_t v = (uint32_t)rel;
put_unaligned_le32(v, buf);
- return fwrite(buf, 1, 4, f) == 4 ? 0 : -1;
+ return fwrite(buf, 1, sizeof(buf), f) == sizeof(buf) ? 0 : -1;
}
-static int write32_as_text(uint32_t v, FILE *f)
+static int write32_as_text(rel_off_t rel, FILE *f)
{
+ uint32_t v = (uint32_t)rel;
return fprintf(f, "\t.long 0x%08"PRIx32"\n", v) > 0 ? 0 : -1;
}
-static void emit_relocs(int as_text, int use_real_mode)
+static int write64(rel_off_t rel, FILE *f)
+{
+ unsigned char buf[sizeof(uint64_t)];
+ uint64_t v = (uint64_t)rel;
+
+ put_unaligned_le64(v, buf);
+ return fwrite(buf, 1, sizeof(buf), f) == sizeof(buf) ? 0 : -1;
+}
+
+static int write64_as_text(rel_off_t rel, FILE *f)
+{
+ uint64_t v = (uint64_t)rel;
+ return fprintf(f, "\t.quad 0x%016"PRIx64"\n", v) > 0 ? 0 : -1;
+}
+
+static void emit_relocs(int as_text, int use_real_mode, int use_large_reloc)
{
int i;
- int (*write_reloc)(uint32_t, FILE *) = write32;
+ int (*write_reloc)(rel_off_t, FILE *);
int (*do_reloc)(struct section *sec, Elf_Rel *rel, Elf_Sym *sym,
const char *symname);
+ if (use_large_reloc)
+ write_reloc = write64;
+ else
+ write_reloc = write32;
+
#if ELF_BITS == 64
if (!use_real_mode)
do_reloc = do_reloc64;
@@ -1088,6 +1116,9 @@ static void emit_relocs(int as_text, int use_real_mode)
do_reloc = do_reloc32;
else
do_reloc = do_reloc_real;
+
+ /* Large relocations only for 64-bit */
+ use_large_reloc = 0;
#endif
/* Collect up the relocations */
@@ -1111,8 +1142,13 @@ static void emit_relocs(int as_text, int use_real_mode)
* gas will like.
*/
printf(".section \".data.reloc\",\"a\"\n");
- printf(".balign 4\n");
- write_reloc = write32_as_text;
+ if (use_large_reloc) {
+ printf(".balign 8\n");
+ write_reloc = write64_as_text;
+ } else {
+ printf(".balign 4\n");
+ write_reloc = write32_as_text;
+ }
}
if (use_real_mode) {
@@ -1180,7 +1216,7 @@ static void print_reloc_info(void)
void process(FILE *fp, int use_real_mode, int as_text,
int show_absolute_syms, int show_absolute_relocs,
- int show_reloc_info)
+ int show_reloc_info, int use_large_reloc)
{
regex_init(use_real_mode);
read_ehdr(fp);
@@ -1203,5 +1239,5 @@ void process(FILE *fp, int use_real_mode, int as_text,
print_reloc_info();
return;
}
- emit_relocs(as_text, use_real_mode);
+ emit_relocs(as_text, use_real_mode, use_large_reloc);
}
diff --git a/arch/x86/tools/relocs.h b/arch/x86/tools/relocs.h
index 1d23bf953a4a..cb771cc4412d 100644
--- a/arch/x86/tools/relocs.h
+++ b/arch/x86/tools/relocs.h
@@ -30,8 +30,8 @@ enum symtype {
void process_32(FILE *fp, int use_real_mode, int as_text,
int show_absolute_syms, int show_absolute_relocs,
- int show_reloc_info);
+ int show_reloc_info, int use_large_reloc);
void process_64(FILE *fp, int use_real_mode, int as_text,
int show_absolute_syms, int show_absolute_relocs,
- int show_reloc_info);
+ int show_reloc_info, int use_large_reloc);
#endif /* RELOCS_H */
diff --git a/arch/x86/tools/relocs_common.c b/arch/x86/tools/relocs_common.c
index acab636bcb34..9cf1391af50a 100644
--- a/arch/x86/tools/relocs_common.c
+++ b/arch/x86/tools/relocs_common.c
@@ -11,14 +11,14 @@ void die(char *fmt, ...)
static void usage(void)
{
- die("relocs [--abs-syms|--abs-relocs|--reloc-info|--text|--realmode]" \
- " vmlinux\n");
+ die("relocs [--abs-syms|--abs-relocs|--reloc-info|--text|--realmode|" \
+ "--large-reloc] vmlinux\n");
}
int main(int argc, char **argv)
{
int show_absolute_syms, show_absolute_relocs, show_reloc_info;
- int as_text, use_real_mode;
+ int as_text, use_real_mode, use_large_reloc;
const char *fname;
FILE *fp;
int i;
@@ -29,6 +29,7 @@ int main(int argc, char **argv)
show_reloc_info = 0;
as_text = 0;
use_real_mode = 0;
+ use_large_reloc = 0;
fname = NULL;
for (i = 1; i < argc; i++) {
char *arg = argv[i];
@@ -53,6 +54,10 @@ int main(int argc, char **argv)
use_real_mode = 1;
continue;
}
+ if (strcmp(arg, "--large-reloc") == 0) {
+ use_large_reloc = 1;
+ continue;
+ }
}
else if (!fname) {
fname = arg;
@@ -74,11 +79,11 @@ int main(int argc, char **argv)
if (e_ident[EI_CLASS] == ELFCLASS64)
process_64(fp, use_real_mode, as_text,
show_absolute_syms, show_absolute_relocs,
- show_reloc_info);
+ show_reloc_info, use_large_reloc);
else
process_32(fp, use_real_mode, as_text,
show_absolute_syms, show_absolute_relocs,
- show_reloc_info);
+ show_reloc_info, use_large_reloc);
fclose(fp);
return 0;
}
--
2.15.0.rc0.271.g36b669edcc-goog
^ permalink raw reply related
* [PATCH v1 25/27] x86/pie: Add option to build the kernel as PIE
From: Thomas Garnier via Virtualization @ 2017-10-11 20:30 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
H . Peter Anvin, Peter Zijlstra, Josh Poimboeuf, Arnd Bergmann,
Thomas Garnier, Kees Cook, Andrey Ryabinin, Matthias Kaehlcke,
Tom Lendacky, Andy Lutomirski, Kirill A . Shutemov,
Borislav Petkov, Rafael J . Wysocki, Len Brown, Pavel Machek,
Juergen Gross, Chris Wright, Alok Kataria, Rusty Russell,
Tejun Heo
Cc: linux-arch, kvm, linux-pm, x86, linux-doc, linux-kernel,
virtualization, linux-sparse, linux-crypto, kernel-hardening,
xen-devel
In-Reply-To: <20171011203027.11248-1-thgarnie@google.com>
Add the CONFIG_X86_PIE option which builds the kernel as a Position
Independent Executable (PIE). The kernel is currently build with the
mcmodel=kernel option which forces it to stay on the top 2G of the
virtual address space. With PIE, the kernel will be able to move below
the current limit.
The --emit-relocs linker option was kept instead of using -pie to limit
the impact on mapped sections. Any incompatible relocation will be
catch by the arch/x86/tools/relocs binary at compile time.
If segment based stack cookies are enabled, try to use the compiler
option to select the segment register. If not available, automatically
enabled global stack cookie in auto mode. Otherwise, recommend
compiler update or global stack cookie option.
Performance/Size impact:
Size of vmlinux (Default configuration):
File size:
- PIE disabled: +0.000031%
- PIE enabled: -3.210% (less relocations)
.text section:
- PIE disabled: +0.000644%
- PIE enabled: +0.837%
Size of vmlinux (Ubuntu configuration):
File size:
- PIE disabled: -0.201%
- PIE enabled: -0.082%
.text section:
- PIE disabled: same
- PIE enabled: +1.319%
Size of vmlinux (Default configuration + ORC):
File size:
- PIE enabled: -3.167%
.text section:
- PIE enabled: +0.814%
Size of vmlinux (Ubuntu configuration + ORC):
File size:
- PIE enabled: -3.167%
.text section:
- PIE enabled: +1.26%
The size increase is mainly due to not having access to the 32-bit signed
relocation that can be used with mcmodel=kernel. A small part is due to reduced
optimization for PIE code. This bug [1] was opened with gcc to provide a better
code generation for kernel PIE.
Hackbench (50% and 1600% on thread/process for pipe/sockets):
- PIE disabled: no significant change (avg +0.1% on latest test).
- PIE enabled: between -0.50% to +0.86% in average (default and Ubuntu config).
slab_test (average of 10 runs):
- PIE disabled: no significant change (-2% on latest run, likely noise).
- PIE enabled: between -1% and +0.8% on latest runs.
Kernbench (average of 10 Half and Optimal runs):
Elapsed Time:
- PIE disabled: no significant change (avg -0.239%)
- PIE enabled: average +0.07%
System Time:
- PIE disabled: no significant change (avg -0.277%)
- PIE enabled: average +0.7%
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303
Signed-off-by: Thomas Garnier <thgarnie@google.com>
merge PIE
---
arch/x86/Kconfig | 7 +++++++
arch/x86/Makefile | 27 +++++++++++++++++++++++++++
2 files changed, 34 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1f2b731c9ec3..bbd28a46ab55 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2148,6 +2148,13 @@ config X86_GLOBAL_STACKPROTECTOR
If unsure, say N
+config X86_PIE
+ bool
+ depends on X86_64
+ select DEFAULT_HIDDEN
+ select DYNAMIC_MODULE_BASE
+ select MODULE_REL_CRCS if MODVERSIONS
+
config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index b592d57c531b..beae9504c3f4 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -135,7 +135,34 @@ else
KBUILD_CFLAGS += -mno-red-zone
ifdef CONFIG_X86_PIE
+ KBUILD_CFLAGS += -fPIC
KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/x86/kernel/module.lds
+
+ifndef CONFIG_CC_STACKPROTECTOR_NONE
+ifndef CONFIG_X86_GLOBAL_STACKPROTECTOR
+ stackseg-flag := -mstack-protector-guard-reg=%gs
+ ifeq ($(call cc-option-yn,$(stackseg-flag)),n)
+ ifdef CONFIG_CC_STACKPROTECTOR_AUTO
+ $(warning Cannot use CONFIG_CC_STACKPROTECTOR_* while \
+ building a position independent kernel. \
+ Default to global stack protector \
+ (CONFIG_X86_GLOBAL_STACKPROTECTOR).)
+ CONFIG_X86_GLOBAL_STACKPROTECTOR := y
+ KBUILD_CFLAGS += -DCONFIG_X86_GLOBAL_STACKPROTECTOR
+ KBUILD_AFLAGS += -DCONFIG_X86_GLOBAL_STACKPROTECTOR
+ else
+ $(error echo Cannot use \
+ CONFIG_CC_STACKPROTECTOR_(REGULAR|STRONG) \
+ while building a position independent binary \
+ Update your compiler or use \
+ CONFIG_X86_GLOBAL_STACKPROTECTOR)
+ endif
+ else
+ KBUILD_CFLAGS += $(stackseg-flag)
+ endif
+endif
+endif
+
else
KBUILD_CFLAGS += -mcmodel=kernel
endif
--
2.15.0.rc0.271.g36b669edcc-goog
^ permalink raw reply related
* [PATCH v1 24/27] x86/mm: Make the x86 GOT read-only
From: Thomas Garnier via Virtualization @ 2017-10-11 20:30 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
H . Peter Anvin, Peter Zijlstra, Josh Poimboeuf, Arnd Bergmann,
Thomas Garnier, Kees Cook, Andrey Ryabinin, Matthias Kaehlcke,
Tom Lendacky, Andy Lutomirski, Kirill A . Shutemov,
Borislav Petkov, Rafael J . Wysocki, Len Brown, Pavel Machek,
Juergen Gross, Chris Wright, Alok Kataria, Rusty Russell,
Tejun Heo
Cc: linux-arch, kvm, linux-pm, x86, linux-doc, linux-kernel,
virtualization, linux-sparse, linux-crypto, kernel-hardening,
xen-devel
In-Reply-To: <20171011203027.11248-1-thgarnie@google.com>
The GOT is changed during early boot when relocations are applied. Make
it read-only directly. This table exists only for PIE binary.
Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.
Signed-off-by: Thomas Garnier <thgarnie@google.com>
---
include/asm-generic/vmlinux.lds.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index e549bff87c5b..a2301c292e26 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -279,6 +279,17 @@
VMLINUX_SYMBOL(__end_ro_after_init) = .;
#endif
+#ifdef CONFIG_X86_PIE
+#define RO_GOT_X86 \
+ .got : AT(ADDR(.got) - LOAD_OFFSET) { \
+ VMLINUX_SYMBOL(__start_got) = .; \
+ *(.got); \
+ VMLINUX_SYMBOL(__end_got) = .; \
+ }
+#else
+#define RO_GOT_X86
+#endif
+
/*
* Read only Data
*/
@@ -335,6 +346,7 @@
VMLINUX_SYMBOL(__end_builtin_fw) = .; \
} \
\
+ RO_GOT_X86 \
TRACEDATA \
\
/* Kernel symbol table: Normal symbols */ \
--
2.15.0.rc0.271.g36b669edcc-goog
^ permalink raw reply related
* [PATCH v1 23/27] x86/modules: Adapt module loading for PIE support
From: Thomas Garnier via Virtualization @ 2017-10-11 20:30 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
H . Peter Anvin, Peter Zijlstra, Josh Poimboeuf, Arnd Bergmann,
Thomas Garnier, Kees Cook, Andrey Ryabinin, Matthias Kaehlcke,
Tom Lendacky, Andy Lutomirski, Kirill A . Shutemov,
Borislav Petkov, Rafael J . Wysocki, Len Brown, Pavel Machek,
Juergen Gross, Chris Wright, Alok Kataria, Rusty Russell,
Tejun Heo
Cc: linux-arch, kvm, linux-pm, x86, linux-doc, linux-kernel,
virtualization, linux-sparse, linux-crypto, kernel-hardening,
xen-devel
In-Reply-To: <20171011203027.11248-1-thgarnie@google.com>
Adapt module loading to support PIE relocations. Generate dynamic GOT if
a symbol requires it but no entry exist in the kernel GOT.
Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.
Signed-off-by: Thomas Garnier <thgarnie@google.com>
---
arch/x86/Makefile | 4 +
arch/x86/include/asm/module.h | 11 +++
arch/x86/include/asm/sections.h | 4 +
arch/x86/kernel/module.c | 182 ++++++++++++++++++++++++++++++++++++++--
arch/x86/kernel/module.lds | 3 +
5 files changed, 199 insertions(+), 5 deletions(-)
create mode 100644 arch/x86/kernel/module.lds
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index de228200ef2a..b592d57c531b 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -134,7 +134,11 @@ else
KBUILD_CFLAGS += $(cflags-y)
KBUILD_CFLAGS += -mno-red-zone
+ifdef CONFIG_X86_PIE
+ KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/x86/kernel/module.lds
+else
KBUILD_CFLAGS += -mcmodel=kernel
+endif
# -funit-at-a-time shrinks the kernel .text considerably
# unfortunately it makes reading oopses harder.
diff --git a/arch/x86/include/asm/module.h b/arch/x86/include/asm/module.h
index 9eb7c718aaf8..21e0e02c0343 100644
--- a/arch/x86/include/asm/module.h
+++ b/arch/x86/include/asm/module.h
@@ -4,12 +4,23 @@
#include <asm-generic/module.h>
#include <asm/orc_types.h>
+#ifdef CONFIG_X86_PIE
+struct mod_got_sec {
+ struct elf64_shdr *got;
+ int got_num_entries;
+ int got_max_entries;
+};
+#endif
+
struct mod_arch_specific {
#ifdef CONFIG_ORC_UNWINDER
unsigned int num_orcs;
int *orc_unwind_ip;
struct orc_entry *orc_unwind;
#endif
+#ifdef CONFIG_X86_PIE
+ struct mod_got_sec core;
+#endif
};
#ifdef CONFIG_X86_64
diff --git a/arch/x86/include/asm/sections.h b/arch/x86/include/asm/sections.h
index 6b2d496cf1aa..92d796109da1 100644
--- a/arch/x86/include/asm/sections.h
+++ b/arch/x86/include/asm/sections.h
@@ -15,4 +15,8 @@ extern char __end_rodata_hpage_align[];
extern char __start_got[], __end_got[];
#endif
+#if defined(CONFIG_X86_PIE)
+extern char __start_got[], __end_got[];
+#endif
+
#endif /* _ASM_X86_SECTIONS_H */
diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
index 62e7d70aadd5..aed24dfac1d3 100644
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -30,6 +30,7 @@
#include <linux/gfp.h>
#include <linux/jump_label.h>
#include <linux/random.h>
+#include <linux/sort.h>
#include <asm/text-patching.h>
#include <asm/page.h>
@@ -77,6 +78,173 @@ static unsigned long int get_module_load_offset(void)
}
#endif
+#ifdef CONFIG_X86_PIE
+static u64 find_got_kernel_entry(Elf64_Sym *sym, const Elf64_Rela *rela)
+{
+ u64 *pos;
+
+ for (pos = (u64*)__start_got; pos < (u64*)__end_got; pos++) {
+ if (*pos == sym->st_value)
+ return (u64)pos + rela->r_addend;
+ }
+
+ return 0;
+}
+
+static u64 module_emit_got_entry(struct module *mod, void *loc,
+ const Elf64_Rela *rela, Elf64_Sym *sym)
+{
+ struct mod_got_sec *gotsec = &mod->arch.core;
+ u64 *got = (u64*)gotsec->got->sh_addr;
+ int i = gotsec->got_num_entries;
+ u64 ret;
+
+ /* Check if we can use the kernel GOT */
+ ret = find_got_kernel_entry(sym, rela);
+ if (ret)
+ return ret;
+
+ got[i] = sym->st_value;
+
+ /*
+ * Check if the entry we just created is a duplicate. Given that the
+ * relocations are sorted, this will be the last entry we allocated.
+ * (if one exists).
+ */
+ if (i > 0 && got[i] == got[i - 2]) {
+ ret = (u64)&got[i - 1];
+ } else {
+ gotsec->got_num_entries++;
+ BUG_ON(gotsec->got_num_entries > gotsec->got_max_entries);
+ ret = (u64)&got[i];
+ }
+
+ return ret + rela->r_addend;
+}
+
+#define cmp_3way(a,b) ((a) < (b) ? -1 : (a) > (b))
+
+static int cmp_rela(const void *a, const void *b)
+{
+ const Elf64_Rela *x = a, *y = b;
+ int i;
+
+ /* sort by type, symbol index and addend */
+ i = cmp_3way(ELF64_R_TYPE(x->r_info), ELF64_R_TYPE(y->r_info));
+ if (i == 0)
+ i = cmp_3way(ELF64_R_SYM(x->r_info), ELF64_R_SYM(y->r_info));
+ if (i == 0)
+ i = cmp_3way(x->r_addend, y->r_addend);
+ return i;
+}
+
+static bool duplicate_rel(const Elf64_Rela *rela, int num)
+{
+ /*
+ * Entries are sorted by type, symbol index and addend. That means
+ * that, if a duplicate entry exists, it must be in the preceding
+ * slot.
+ */
+ return num > 0 && cmp_rela(rela + num, rela + num - 1) == 0;
+}
+
+static unsigned int count_gots(Elf64_Sym *syms, Elf64_Rela *rela, int num)
+{
+ unsigned int ret = 0;
+ Elf64_Sym *s;
+ int i;
+
+ for (i = 0; i < num; i++) {
+ switch (ELF64_R_TYPE(rela[i].r_info)) {
+ case R_X86_64_GOTPCREL:
+ s = syms + ELF64_R_SYM(rela[i].r_info);
+
+ /*
+ * Use the kernel GOT when possible, else reserve a
+ * custom one for this module.
+ */
+ if (!duplicate_rel(rela, i) &&
+ !find_got_kernel_entry(s, rela + i))
+ ret++;
+ break;
+ }
+ }
+ return ret;
+}
+
+/*
+ * Generate GOT entries for GOTPCREL relocations that do not exists in the
+ * kernel GOT. Based on arm64 module-plts implementation.
+ */
+int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
+ char *secstrings, struct module *mod)
+{
+ unsigned long gots = 0;
+ Elf_Shdr *symtab = NULL;
+ Elf64_Sym *syms = NULL;
+ char *strings, *name;
+ int i;
+
+ /*
+ * Find the empty .got section so we can expand it to store the PLT
+ * entries. Record the symtab address as well.
+ */
+ for (i = 0; i < ehdr->e_shnum; i++) {
+ if (!strcmp(secstrings + sechdrs[i].sh_name, ".got")) {
+ mod->arch.core.got = sechdrs + i;
+ } else if (sechdrs[i].sh_type == SHT_SYMTAB) {
+ symtab = sechdrs + i;
+ syms = (Elf64_Sym *)symtab->sh_addr;
+ }
+ }
+
+ if (!mod->arch.core.got) {
+ pr_err("%s: module GOT section missing\n", mod->name);
+ return -ENOEXEC;
+ }
+ if (!syms) {
+ pr_err("%s: module symtab section missing\n", mod->name);
+ return -ENOEXEC;
+ }
+
+ for (i = 0; i < ehdr->e_shnum; i++) {
+ Elf64_Rela *rels = (void *)ehdr + sechdrs[i].sh_offset;
+ int numrels = sechdrs[i].sh_size / sizeof(Elf64_Rela);
+
+ if (sechdrs[i].sh_type != SHT_RELA)
+ continue;
+
+ /* sort by type, symbol index and addend */
+ sort(rels, numrels, sizeof(Elf64_Rela), cmp_rela, NULL);
+
+ gots += count_gots(syms, rels, numrels);
+ }
+
+ mod->arch.core.got->sh_type = SHT_NOBITS;
+ mod->arch.core.got->sh_flags = SHF_ALLOC;
+ mod->arch.core.got->sh_addralign = L1_CACHE_BYTES;
+ mod->arch.core.got->sh_size = (gots + 1) * sizeof(u64);
+ mod->arch.core.got_num_entries = 0;
+ mod->arch.core.got_max_entries = gots;
+
+ /*
+ * If a _GLOBAL_OFFSET_TABLE_ symbol exists, make it absolute for
+ * modules to correctly reference it. Similar to s390 implementation.
+ */
+ strings = (void *) ehdr + sechdrs[symtab->sh_link].sh_offset;
+ for (i = 0; i < symtab->sh_size/sizeof(Elf_Sym); i++) {
+ if (syms[i].st_shndx != SHN_UNDEF)
+ continue;
+ name = strings + syms[i].st_name;
+ if (!strcmp(name, "_GLOBAL_OFFSET_TABLE_")) {
+ syms[i].st_shndx = SHN_ABS;
+ break;
+ }
+ }
+ return 0;
+}
+#endif
+
void *module_alloc(unsigned long size)
{
void *p;
@@ -184,13 +352,18 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
if ((s64)val != *(s32 *)loc)
goto overflow;
break;
+#ifdef CONFIG_X86_PIE
+ case R_X86_64_GOTPCREL:
+ val = module_emit_got_entry(me, loc, rel + i, sym);
+ /* fallthrough */
+#endif
+ case R_X86_64_PLT32:
case R_X86_64_PC32:
val -= (u64)loc;
*(u32 *)loc = val;
-#if 0
- if ((s64)val != *(s32 *)loc)
+ if (IS_ENABLED(CONFIG_X86_PIE) &&
+ (s64)val != *(s32 *)loc)
goto overflow;
-#endif
break;
default:
pr_err("%s: Unknown rela relocation: %llu\n",
@@ -203,8 +376,7 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
overflow:
pr_err("overflow in relocation type %d val %Lx\n",
(int)ELF64_R_TYPE(rel[i].r_info), val);
- pr_err("`%s' likely not compiled with -mcmodel=kernel\n",
- me->name);
+ pr_err("`%s' likely too far from the kernel\n", me->name);
return -ENOEXEC;
}
#endif
diff --git a/arch/x86/kernel/module.lds b/arch/x86/kernel/module.lds
new file mode 100644
index 000000000000..fd6e95a4b454
--- /dev/null
+++ b/arch/x86/kernel/module.lds
@@ -0,0 +1,3 @@
+SECTIONS {
+ .got (NOLOAD) : { BYTE(0) }
+}
--
2.15.0.rc0.271.g36b669edcc-goog
^ permalink raw reply related
* [PATCH v1 22/27] x86/modules: Add option to start module section after kernel
From: Thomas Garnier via Virtualization @ 2017-10-11 20:30 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
H . Peter Anvin, Peter Zijlstra, Josh Poimboeuf, Arnd Bergmann,
Thomas Garnier, Kees Cook, Andrey Ryabinin, Matthias Kaehlcke,
Tom Lendacky, Andy Lutomirski, Kirill A . Shutemov,
Borislav Petkov, Rafael J . Wysocki, Len Brown, Pavel Machek,
Juergen Gross, Chris Wright, Alok Kataria, Rusty Russell,
Tejun Heo
Cc: linux-arch, kvm, linux-pm, x86, linux-doc, linux-kernel,
virtualization, linux-sparse, linux-crypto, kernel-hardening,
xen-devel
In-Reply-To: <20171011203027.11248-1-thgarnie@google.com>
Add an option so the module section is just after the mapped kernel. It
will ensure position independent modules are always at the right
distance from the kernel and do not require mcmodule=large. It also
optimize the available size for modules by getting rid of the empty
space on kernel randomization range.
Signed-off-by: Thomas Garnier <thgarnie@google.com>
---
Documentation/x86/x86_64/mm.txt | 3 +++
arch/x86/Kconfig | 4 ++++
arch/x86/include/asm/pgtable_64_types.h | 6 +++++-
arch/x86/kernel/head64.c | 5 ++++-
arch/x86/mm/dump_pagetables.c | 4 ++--
5 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index b0798e281aa6..b51d66386e32 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -73,4 +73,7 @@ Note that if CONFIG_RANDOMIZE_MEMORY is enabled, the direct mapping of all
physical memory, vmalloc/ioremap space and virtual memory map are randomized.
Their order is preserved but their base will be offset early at boot time.
+If CONFIG_DYNAMIC_MODULE_BASE is enabled, the module section follows the end of
+the mapped kernel.
+
-Andi Kleen, Jul 2004
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 772ff3e0f623..1f2b731c9ec3 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2133,6 +2133,10 @@ config RANDOMIZE_MEMORY_PHYSICAL_PADDING
If unsure, leave at the default value.
+# Module section starts just after the end of the kernel module
+config DYNAMIC_MODULE_BASE
+ bool
+
config X86_GLOBAL_STACKPROTECTOR
bool "Stack cookie using a global variable"
select CC_STACKPROTECTOR
diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h
index 06470da156ba..e00fc429b898 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -6,6 +6,7 @@
#ifndef __ASSEMBLY__
#include <linux/types.h>
#include <asm/kaslr.h>
+#include <asm/sections.h>
/*
* These are used to make use of C type-checking..
@@ -18,7 +19,6 @@ typedef unsigned long pgdval_t;
typedef unsigned long pgprotval_t;
typedef struct { pteval_t pte; } pte_t;
-
#endif /* !__ASSEMBLY__ */
#define SHARED_KERNEL_PMD 0
@@ -93,7 +93,11 @@ typedef struct { pteval_t pte; } pte_t;
#define VMEMMAP_START __VMEMMAP_BASE
#endif /* CONFIG_RANDOMIZE_MEMORY */
#define VMALLOC_END (VMALLOC_START + _AC((VMALLOC_SIZE_TB << 40) - 1, UL))
+#ifdef CONFIG_DYNAMIC_MODULE_BASE
+#define MODULES_VADDR ALIGN(((unsigned long)_end + PAGE_SIZE), PMD_SIZE)
+#else
#define MODULES_VADDR (__START_KERNEL_map + KERNEL_IMAGE_SIZE)
+#endif
/* The module sections ends with the start of the fixmap */
#define MODULES_END __fix_to_virt(__end_of_fixed_addresses + 1)
#define MODULES_LEN (MODULES_END - MODULES_VADDR)
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 675f1dba3b21..b6363f0d11a7 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -321,12 +321,15 @@ asmlinkage __visible void __init x86_64_start_kernel(char * real_mode_data)
* Build-time sanity checks on the kernel image and module
* area mappings. (these are purely build-time and produce no code)
*/
+#ifndef CONFIG_DYNAMIC_MODULE_BASE
BUILD_BUG_ON(MODULES_VADDR < __START_KERNEL_map);
BUILD_BUG_ON(MODULES_VADDR - __START_KERNEL_map < KERNEL_IMAGE_SIZE);
- BUILD_BUG_ON(MODULES_LEN + KERNEL_IMAGE_SIZE > 2*PUD_SIZE);
+ BUILD_BUG_ON(!IS_ENABLED(CONFIG_RANDOMIZE_BASE_LARGE) &&
+ MODULES_LEN + KERNEL_IMAGE_SIZE > 2*PUD_SIZE);
BUILD_BUG_ON((__START_KERNEL_map & ~PMD_MASK) != 0);
BUILD_BUG_ON((MODULES_VADDR & ~PMD_MASK) != 0);
BUILD_BUG_ON(!(MODULES_VADDR > __START_KERNEL));
+#endif
BUILD_BUG_ON(!(((MODULES_END - 1) & PGDIR_MASK) ==
(__START_KERNEL & PGDIR_MASK)));
BUILD_BUG_ON(__fix_to_virt(__end_of_fixed_addresses) <= MODULES_END);
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 8691a57da63e..8565b2b45848 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -95,7 +95,7 @@ static struct addr_marker address_markers[] = {
{ EFI_VA_END, "EFI Runtime Services" },
# endif
{ __START_KERNEL_map, "High Kernel Mapping" },
- { MODULES_VADDR, "Modules" },
+ { 0/* MODULES_VADDR */, "Modules" },
{ MODULES_END, "End Modules" },
#else
{ PAGE_OFFSET, "Kernel Mapping" },
@@ -529,7 +529,7 @@ static int __init pt_dump_init(void)
# endif
address_markers[FIXADDR_START_NR].start_address = FIXADDR_START;
#endif
-
+ address_markers[MODULES_VADDR_NR].start_address = MODULES_VADDR;
return 0;
}
__initcall(pt_dump_init);
--
2.15.0.rc0.271.g36b669edcc-goog
^ permalink raw reply related
* [PATCH v1 21/27] x86/mm/dump_pagetables: Fix address markers index on x86_64
From: Thomas Garnier via Virtualization @ 2017-10-11 20:30 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
H . Peter Anvin, Peter Zijlstra, Josh Poimboeuf, Arnd Bergmann,
Thomas Garnier, Kees Cook, Andrey Ryabinin, Matthias Kaehlcke,
Tom Lendacky, Andy Lutomirski, Kirill A . Shutemov,
Borislav Petkov, Rafael J . Wysocki, Len Brown, Pavel Machek,
Juergen Gross, Chris Wright, Alok Kataria, Rusty Russell,
Tejun Heo
Cc: linux-arch, kvm, linux-pm, x86, linux-doc, linux-kernel,
virtualization, linux-sparse, linux-crypto, kernel-hardening,
xen-devel
In-Reply-To: <20171011203027.11248-1-thgarnie@google.com>
The address_markers_idx enum is not aligned with the table when EFI is
enabled. Add an EFI_VA_END_NR entry in this case.
Signed-off-by: Thomas Garnier <thgarnie@google.com>
---
arch/x86/mm/dump_pagetables.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 5e3ac6fe6c9e..8691a57da63e 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -52,12 +52,15 @@ enum address_markers_idx {
LOW_KERNEL_NR,
VMALLOC_START_NR,
VMEMMAP_START_NR,
-#ifdef CONFIG_KASAN
+# ifdef CONFIG_KASAN
KASAN_SHADOW_START_NR,
KASAN_SHADOW_END_NR,
-#endif
+# endif
# ifdef CONFIG_X86_ESPFIX64
ESPFIX_START_NR,
+# endif
+# ifdef CONFIG_EFI
+ EFI_VA_END_NR,
# endif
HIGH_KERNEL_NR,
MODULES_VADDR_NR,
--
2.15.0.rc0.271.g36b669edcc-goog
^ permalink raw reply related
* [PATCH v1 20/27] x86/ftrace: Adapt function tracing for PIE support
From: Thomas Garnier via Virtualization @ 2017-10-11 20:30 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
H . Peter Anvin, Peter Zijlstra, Josh Poimboeuf, Arnd Bergmann,
Thomas Garnier, Kees Cook, Andrey Ryabinin, Matthias Kaehlcke,
Tom Lendacky, Andy Lutomirski, Kirill A . Shutemov,
Borislav Petkov, Rafael J . Wysocki, Len Brown, Pavel Machek,
Juergen Gross, Chris Wright, Alok Kataria, Rusty Russell,
Tejun Heo
Cc: linux-arch, kvm, linux-pm, x86, linux-doc, linux-kernel,
virtualization, linux-sparse, linux-crypto, kernel-hardening,
xen-devel
In-Reply-To: <20171011203027.11248-1-thgarnie@google.com>
When using -fPIE/PIC with function tracing, the compiler generates a
call through the GOT (call *__fentry__@GOTPCREL). This instruction
takes 6 bytes instead of 5 on the usual relative call.
If PIE is enabled, replace the 6th byte of the GOT call by a 1-byte nop
so ftrace can handle the previous 5-bytes as before.
Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.
Signed-off-by: Thomas Garnier <thgarnie@google.com>
---
arch/x86/include/asm/ftrace.h | 6 ++++--
arch/x86/include/asm/sections.h | 4 ++++
arch/x86/kernel/ftrace.c | 42 +++++++++++++++++++++++++++++++++++++++--
3 files changed, 48 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index eccd0ac6bc38..183990157a5e 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -24,9 +24,11 @@ extern void __fentry__(void);
static inline unsigned long ftrace_call_adjust(unsigned long addr)
{
/*
- * addr is the address of the mcount call instruction.
- * recordmcount does the necessary offset calculation.
+ * addr is the address of the mcount call instruction. PIE has always a
+ * byte added to the start of the function.
*/
+ if (IS_ENABLED(CONFIG_X86_PIE))
+ addr -= 1;
return addr;
}
diff --git a/arch/x86/include/asm/sections.h b/arch/x86/include/asm/sections.h
index 2f75f30cb2f6..6b2d496cf1aa 100644
--- a/arch/x86/include/asm/sections.h
+++ b/arch/x86/include/asm/sections.h
@@ -11,4 +11,8 @@ extern struct exception_table_entry __stop___ex_table[];
extern char __end_rodata_hpage_align[];
#endif
+#if defined(CONFIG_X86_PIE)
+extern char __start_got[], __end_got[];
+#endif
+
#endif /* _ASM_X86_SECTIONS_H */
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index 9bef1bbeba63..a253601e783b 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -101,7 +101,7 @@ static const unsigned char *ftrace_nop_replace(void)
static int
ftrace_modify_code_direct(unsigned long ip, unsigned const char *old_code,
- unsigned const char *new_code)
+ unsigned const char *new_code)
{
unsigned char replaced[MCOUNT_INSN_SIZE];
@@ -134,6 +134,44 @@ ftrace_modify_code_direct(unsigned long ip, unsigned const char *old_code,
return 0;
}
+/* Bytes before call GOT offset */
+const unsigned char got_call_preinsn[] = { 0xff, 0x15 };
+
+static int
+ftrace_modify_initial_code(unsigned long ip, unsigned const char *old_code,
+ unsigned const char *new_code)
+{
+ unsigned char replaced[MCOUNT_INSN_SIZE + 1];
+
+ ftrace_expected = old_code;
+
+ /*
+ * If PIE is not enabled or no GOT call was found, default to the
+ * original approach to code modification.
+ */
+ if (!IS_ENABLED(CONFIG_X86_PIE)
+ || probe_kernel_read(replaced, (void *)ip, sizeof(replaced))
+ || memcmp(replaced, got_call_preinsn, sizeof(got_call_preinsn)))
+ return ftrace_modify_code_direct(ip, old_code, new_code);
+
+ /*
+ * Build a nop slide with a 5-byte nop and 1-byte nop to keep the ftrace
+ * hooking algorithm working with the expected 5 bytes instruction.
+ */
+ memcpy(replaced, new_code, MCOUNT_INSN_SIZE);
+ replaced[MCOUNT_INSN_SIZE] = ideal_nops[1][0];
+
+ ip = text_ip_addr(ip);
+
+ if (probe_kernel_write((void *)ip, replaced, sizeof(replaced)))
+ return -EPERM;
+
+ sync_core();
+
+ return 0;
+
+}
+
int ftrace_make_nop(struct module *mod,
struct dyn_ftrace *rec, unsigned long addr)
{
@@ -152,7 +190,7 @@ int ftrace_make_nop(struct module *mod,
* just modify the code directly.
*/
if (addr == MCOUNT_ADDR)
- return ftrace_modify_code_direct(rec->ip, old, new);
+ return ftrace_modify_initial_code(rec->ip, old, new);
ftrace_expected = NULL;
--
2.15.0.rc0.271.g36b669edcc-goog
^ permalink raw reply related
* [PATCH v1 19/27] x86: Support global stack cookie
From: Thomas Garnier via Virtualization @ 2017-10-11 20:30 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
H . Peter Anvin, Peter Zijlstra, Josh Poimboeuf, Arnd Bergmann,
Thomas Garnier, Kees Cook, Andrey Ryabinin, Matthias Kaehlcke,
Tom Lendacky, Andy Lutomirski, Kirill A . Shutemov,
Borislav Petkov, Rafael J . Wysocki, Len Brown, Pavel Machek,
Juergen Gross, Chris Wright, Alok Kataria, Rusty Russell,
Tejun Heo
Cc: linux-arch, kvm, linux-pm, x86, linux-doc, linux-kernel,
virtualization, linux-sparse, linux-crypto, kernel-hardening,
xen-devel
In-Reply-To: <20171011203027.11248-1-thgarnie@google.com>
Add an off-by-default configuration option to use a global stack cookie
instead of the default TLS. This configuration option will only be used
with PIE binaries.
For kernel stack cookie, the compiler uses the mcmodel=kernel to switch
between the fs segment to gs segment. A PIE binary does not use
mcmodel=kernel because it can be relocated anywhere, therefore the
compiler will default to the fs segment register. This is going to be
fixed with a compiler change allowing to pick the segment register as
done on PowerPC. In the meantime, this configuration can be used to
support older compilers.
Signed-off-by: Thomas Garnier <thgarnie@google.com>
---
arch/x86/Kconfig | 11 +++++++++++
arch/x86/Makefile | 9 +++++++++
arch/x86/entry/entry_32.S | 3 ++-
arch/x86/entry/entry_64.S | 3 ++-
arch/x86/include/asm/processor.h | 3 ++-
arch/x86/include/asm/stackprotector.h | 19 ++++++++++++++-----
arch/x86/kernel/asm-offsets.c | 3 ++-
arch/x86/kernel/asm-offsets_32.c | 3 ++-
arch/x86/kernel/asm-offsets_64.c | 3 ++-
arch/x86/kernel/cpu/common.c | 3 ++-
arch/x86/kernel/head_32.S | 3 ++-
arch/x86/kernel/process.c | 5 +++++
12 files changed, 55 insertions(+), 13 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 063f1e0d51aa..772ff3e0f623 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2133,6 +2133,17 @@ config RANDOMIZE_MEMORY_PHYSICAL_PADDING
If unsure, leave at the default value.
+config X86_GLOBAL_STACKPROTECTOR
+ bool "Stack cookie using a global variable"
+ select CC_STACKPROTECTOR
+ ---help---
+ This option turns on the "stack-protector" GCC feature using a global
+ variable instead of a segment register. It is useful when the
+ compiler does not support custom segment registers when building a
+ position independent (PIE) binary.
+
+ If unsure, say N
+
config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 6276572259c8..de228200ef2a 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -141,6 +141,15 @@ else
KBUILD_CFLAGS += $(call cc-option,-funit-at-a-time)
endif
+ifdef CONFIG_X86_GLOBAL_STACKPROTECTOR
+ ifeq ($(call cc-option, -mstack-protector-guard=global),)
+ $(error Cannot use CONFIG_X86_GLOBAL_STACKPROTECTOR: \
+ -mstack-protector-guard=global not supported \
+ by compiler)
+ endif
+ KBUILD_CFLAGS += -mstack-protector-guard=global
+endif
+
ifdef CONFIG_X86_X32
x32_ld_ok := $(call try-run,\
/bin/echo -e '1: .quad 1b' | \
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 8a13d468635a..ab3e5056722f 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -237,7 +237,8 @@ ENTRY(__switch_to_asm)
movl %esp, TASK_threadsp(%eax)
movl TASK_threadsp(%edx), %esp
-#ifdef CONFIG_CC_STACKPROTECTOR
+#if defined(CONFIG_CC_STACKPROTECTOR) && \
+ !defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
movl TASK_stack_canary(%edx), %ebx
movl %ebx, PER_CPU_VAR(stack_canary)+stack_canary_offset
#endif
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index d3a52d2342af..01be62c1b436 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -390,7 +390,8 @@ ENTRY(__switch_to_asm)
movq %rsp, TASK_threadsp(%rdi)
movq TASK_threadsp(%rsi), %rsp
-#ifdef CONFIG_CC_STACKPROTECTOR
+#if defined(CONFIG_CC_STACKPROTECTOR) && \
+ !defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
movq TASK_stack_canary(%rsi), %rbx
movq %rbx, PER_CPU_VAR(irq_stack_union + stack_canary_offset)
#endif
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index b09bd50b06c7..e3a7ef8d5fb8 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -394,7 +394,8 @@ DECLARE_PER_CPU(char *, irq_stack_ptr);
DECLARE_PER_CPU(unsigned int, irq_count);
extern asmlinkage void ignore_sysret(void);
#else /* X86_64 */
-#ifdef CONFIG_CC_STACKPROTECTOR
+#if defined(CONFIG_CC_STACKPROTECTOR) && \
+ defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
/*
* Make sure stack canary segment base is cached-aligned:
* "For Intel Atom processors, avoid non zero segment base address
diff --git a/arch/x86/include/asm/stackprotector.h b/arch/x86/include/asm/stackprotector.h
index 8abedf1d650e..66462d778dc5 100644
--- a/arch/x86/include/asm/stackprotector.h
+++ b/arch/x86/include/asm/stackprotector.h
@@ -51,6 +51,10 @@
#define GDT_STACK_CANARY_INIT \
[GDT_ENTRY_STACK_CANARY] = GDT_ENTRY_INIT(0x4090, 0, 0x18),
+#ifdef CONFIG_X86_GLOBAL_STACKPROTECTOR
+extern unsigned long __stack_chk_guard;
+#endif
+
/*
* Initialize the stackprotector canary value.
*
@@ -62,7 +66,7 @@ static __always_inline void boot_init_stack_canary(void)
u64 canary;
u64 tsc;
-#ifdef CONFIG_X86_64
+#if defined(CONFIG_X86_64) && !defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
BUILD_BUG_ON(offsetof(union irq_stack_union, stack_canary) != 40);
#endif
/*
@@ -76,17 +80,22 @@ static __always_inline void boot_init_stack_canary(void)
canary += tsc + (tsc << 32UL);
canary &= CANARY_MASK;
+#ifdef CONFIG_X86_GLOBAL_STACKPROTECTOR
+ if (__stack_chk_guard == 0)
+ __stack_chk_guard = canary ?: 1;
+#else /* !CONFIG_X86_GLOBAL_STACKPROTECTOR */
current->stack_canary = canary;
#ifdef CONFIG_X86_64
this_cpu_write(irq_stack_union.stack_canary, canary);
-#else
+#else /* CONFIG_X86_32 */
this_cpu_write(stack_canary.canary, canary);
#endif
+#endif
}
static inline void setup_stack_canary_segment(int cpu)
{
-#ifdef CONFIG_X86_32
+#if defined(CONFIG_X86_32) && !defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
unsigned long canary = (unsigned long)&per_cpu(stack_canary, cpu);
struct desc_struct *gdt_table = get_cpu_gdt_rw(cpu);
struct desc_struct desc;
@@ -99,7 +108,7 @@ static inline void setup_stack_canary_segment(int cpu)
static inline void load_stack_canary_segment(void)
{
-#ifdef CONFIG_X86_32
+#if defined(CONFIG_X86_32) && !defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
asm("mov %0, %%gs" : : "r" (__KERNEL_STACK_CANARY) : "memory");
#endif
}
@@ -115,7 +124,7 @@ static inline void setup_stack_canary_segment(int cpu)
static inline void load_stack_canary_segment(void)
{
-#ifdef CONFIG_X86_32
+#if defined(CONFIG_X86_32) && !defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
asm volatile ("mov %0, %%gs" : : "r" (0));
#endif
}
diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c
index de827d6ac8c2..b30a12cd021e 100644
--- a/arch/x86/kernel/asm-offsets.c
+++ b/arch/x86/kernel/asm-offsets.c
@@ -30,7 +30,8 @@
void common(void) {
BLANK();
OFFSET(TASK_threadsp, task_struct, thread.sp);
-#ifdef CONFIG_CC_STACKPROTECTOR
+#if defined(CONFIG_CC_STACKPROTECTOR) && \
+ !defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
OFFSET(TASK_stack_canary, task_struct, stack_canary);
#endif
diff --git a/arch/x86/kernel/asm-offsets_32.c b/arch/x86/kernel/asm-offsets_32.c
index 710edab9e644..33584e7e486b 100644
--- a/arch/x86/kernel/asm-offsets_32.c
+++ b/arch/x86/kernel/asm-offsets_32.c
@@ -54,7 +54,8 @@ void foo(void)
/* Size of SYSENTER_stack */
DEFINE(SIZEOF_SYSENTER_stack, sizeof(((struct tss_struct *)0)->SYSENTER_stack));
-#ifdef CONFIG_CC_STACKPROTECTOR
+#if defined(CONFIG_CC_STACKPROTECTOR) && \
+ !defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
BLANK();
OFFSET(stack_canary_offset, stack_canary, canary);
#endif
diff --git a/arch/x86/kernel/asm-offsets_64.c b/arch/x86/kernel/asm-offsets_64.c
index cf42206926af..06feb31a09f5 100644
--- a/arch/x86/kernel/asm-offsets_64.c
+++ b/arch/x86/kernel/asm-offsets_64.c
@@ -64,7 +64,8 @@ int main(void)
OFFSET(TSS_sp0, tss_struct, x86_tss.sp0);
BLANK();
-#ifdef CONFIG_CC_STACKPROTECTOR
+#if defined(CONFIG_CC_STACKPROTECTOR) && \
+ !defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
DEFINE(stack_canary_offset, offsetof(union irq_stack_union, stack_canary));
BLANK();
#endif
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index fac71a3ee0b5..99c8af974874 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1431,7 +1431,8 @@ DEFINE_PER_CPU(unsigned long, cpu_current_top_of_stack) =
(unsigned long)&init_thread_union + THREAD_SIZE;
EXPORT_PER_CPU_SYMBOL(cpu_current_top_of_stack);
-#ifdef CONFIG_CC_STACKPROTECTOR
+#if defined(CONFIG_CC_STACKPROTECTOR) && \
+ !defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
DEFINE_PER_CPU_ALIGNED(struct stack_canary, stack_canary);
#endif
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index 9ed3074d0d27..a55a67b33934 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -377,7 +377,8 @@ ENDPROC(startup_32_smp)
*/
__INIT
setup_once:
-#ifdef CONFIG_CC_STACKPROTECTOR
+#if defined(CONFIG_CC_STACKPROTECTOR) && \
+ !defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
/*
* Configure the stack canary. The linker can't handle this by
* relocation. Manually set base address in stack canary
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index bd6b85fac666..66ea1a35413e 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -73,6 +73,11 @@ EXPORT_PER_CPU_SYMBOL(cpu_tss);
DEFINE_PER_CPU(bool, __tss_limit_invalid);
EXPORT_PER_CPU_SYMBOL_GPL(__tss_limit_invalid);
+#ifdef CONFIG_X86_GLOBAL_STACKPROTECTOR
+unsigned long __stack_chk_guard __read_mostly;
+EXPORT_SYMBOL(__stack_chk_guard);
+#endif
+
/*
* this gets called so that we can store lazy state into memory and copy the
* current task into the new thread.
--
2.15.0.rc0.271.g36b669edcc-goog
^ permalink raw reply related
* [PATCH v1 18/27] kvm: Adapt assembly for PIE support
From: Thomas Garnier via Virtualization @ 2017-10-11 20:30 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
H . Peter Anvin, Peter Zijlstra, Josh Poimboeuf, Arnd Bergmann,
Thomas Garnier, Kees Cook, Andrey Ryabinin, Matthias Kaehlcke,
Tom Lendacky, Andy Lutomirski, Kirill A . Shutemov,
Borislav Petkov, Rafael J . Wysocki, Len Brown, Pavel Machek,
Juergen Gross, Chris Wright, Alok Kataria, Rusty Russell,
Tejun Heo
Cc: linux-arch, kvm, linux-pm, x86, linux-doc, linux-kernel,
virtualization, linux-sparse, linux-crypto, kernel-hardening,
xen-devel
In-Reply-To: <20171011203027.11248-1-thgarnie@google.com>
Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible. The new __ASM_GET_PTR_PRE macro is used to
get the address of a symbol on both 32 and 64-bit with PIE support.
Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.
Signed-off-by: Thomas Garnier <thgarnie@google.com>
---
arch/x86/include/asm/kvm_host.h | 6 ++++--
arch/x86/kernel/kvm.c | 6 ++++--
arch/x86/kvm/svm.c | 4 ++--
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 9d7d856b2d89..14073fda75fb 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1342,9 +1342,11 @@ asmlinkage void kvm_spurious_fault(void);
".pushsection .fixup, \"ax\" \n" \
"667: \n\t" \
cleanup_insn "\n\t" \
- "cmpb $0, kvm_rebooting \n\t" \
+ "cmpb $0, kvm_rebooting" __ASM_SEL(,(%%rip)) " \n\t" \
"jne 668b \n\t" \
- __ASM_SIZE(push) " $666b \n\t" \
+ __ASM_SIZE(push) "%%" _ASM_AX " \n\t" \
+ __ASM_GET_PTR_PRE(666b) "%%" _ASM_AX "\n\t" \
+ "xchg %%" _ASM_AX ", (%%" _ASM_SP ") \n\t" \
"call kvm_spurious_fault \n\t" \
".popsection \n\t" \
_ASM_EXTABLE(666b, 667b)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 8bb9594d0761..4464c3667831 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -627,8 +627,10 @@ asm(
".global __raw_callee_save___kvm_vcpu_is_preempted;"
".type __raw_callee_save___kvm_vcpu_is_preempted, @function;"
"__raw_callee_save___kvm_vcpu_is_preempted:"
-"movq __per_cpu_offset(,%rdi,8), %rax;"
-"cmpb $0, " __stringify(KVM_STEAL_TIME_preempted) "+steal_time(%rax);"
+"leaq __per_cpu_offset(%rip), %rax;"
+"movq (%rax,%rdi,8), %rax;"
+"addq " __stringify(KVM_STEAL_TIME_preempted) "+steal_time(%rip), %rax;"
+"cmpb $0, (%rax);"
"setne %al;"
"ret;"
".popsection");
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 0e68f0b3cbf7..364536080438 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -568,12 +568,12 @@ static u32 svm_msrpm_offset(u32 msr)
static inline void clgi(void)
{
- asm volatile (__ex(SVM_CLGI));
+ asm volatile (__ex(SVM_CLGI) : :);
}
static inline void stgi(void)
{
- asm volatile (__ex(SVM_STGI));
+ asm volatile (__ex(SVM_STGI) : :);
}
static inline void invlpga(unsigned long addr, u32 asid)
--
2.15.0.rc0.271.g36b669edcc-goog
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox