WSL2-Linux-Kernel/drivers/video/console/vgacon.c

1208 строки
36 KiB
C
Исходник Обычный вид История

/*
* linux/drivers/video/vgacon.c -- Low level VGA based console driver
*
* Created 28 Sep 1997 by Geert Uytterhoeven
*
* Rewritten by Martin Mares <mj@ucw.cz>, July 1998
*
* This file is based on the old console.c, vga.c and vesa_blank.c drivers.
*
* Copyright (C) 1991, 1992 Linus Torvalds
* 1995 Jay Estabrook
*
* User definable mapping table and font loading by Eugene G. Crosser,
* <crosser@average.org>
*
* Improved loadable font/UTF-8 support by H. Peter Anvin
* Feb-Sep 1995 <peter.anvin@linux.org>
*
* Colour palette handling, by Simon Tatham
* 17-Jun-95 <sgt20@cam.ac.uk>
*
* if 512 char mode is already enabled don't re-enable it,
* because it causes screen to flicker, by Mitja Horvat
* 5-May-96 <mitja.horvat@guest.arnes.si>
*
* Use 2 outw instead of 4 outb_p to reduce erroneous text
* flashing on RHS of screen during heavy console scrolling .
* Oct 1996, Paul Gortmaker.
*
*
* This file is subject to the terms and conditions of the GNU General Public
* License. See the file COPYING in the main directory of this archive for
* more details.
*/
#include <linux/module.h>
#include <linux/types.h>
#include <linux/fs.h>
#include <linux/kernel.h>
#include <linux/console.h>
#include <linux/string.h>
#include <linux/kd.h>
#include <linux/slab.h>
#include <linux/vt_kern.h>
#include <linux/sched.h>
#include <linux/selection.h>
#include <linux/spinlock.h>
#include <linux/ioport.h>
#include <linux/init.h>
#include <linux/screen_info.h>
#include <video/vga.h>
#include <asm/io.h>
static DEFINE_RAW_SPINLOCK(vga_lock);
static int cursor_size_lastfrom;
static int cursor_size_lastto;
static u32 vgacon_xres;
static u32 vgacon_yres;
static struct vgastate vgastate;
#define BLANK 0x0020
#define VGA_FONTWIDTH 8 /* VGA does not support fontwidths != 8 */
/*
* Interface used by the world
*/
static const char *vgacon_startup(void);
static void vgacon_init(struct vc_data *c, int init);
static void vgacon_deinit(struct vc_data *c);
static void vgacon_cursor(struct vc_data *c, int mode);
static int vgacon_switch(struct vc_data *c);
static int vgacon_blank(struct vc_data *c, int blank, int mode_switch);
static void vgacon_scrolldelta(struct vc_data *c, int lines);
static int vgacon_set_origin(struct vc_data *c);
static void vgacon_save_screen(struct vc_data *c);
static void vgacon_invert_region(struct vc_data *c, u16 * p, int count);
static struct uni_pagedict *vgacon_uni_pagedir;
static int vgacon_refcount;
/* Description of the hardware situation */
static unsigned long vga_vram_base __read_mostly; /* Base of video memory */
static unsigned long vga_vram_end __read_mostly; /* End of video memory */
static unsigned int vga_vram_size __read_mostly; /* Size of video memory */
static u16 vga_video_port_reg __read_mostly; /* Video register select port */
static u16 vga_video_port_val __read_mostly; /* Video register value port */
static unsigned int vga_video_num_columns; /* Number of text columns */
static unsigned int vga_video_num_lines; /* Number of text lines */
static bool vga_can_do_color; /* Do we support colors? */
static unsigned int vga_default_font_height __read_mostly; /* Height of default screen font */
static unsigned char vga_video_type __read_mostly; /* Card type */
static int vga_vesa_blanked;
static bool vga_palette_blanked;
static bool vga_is_gfx;
static bool vga_512_chars;
static int vga_video_font_height;
static int vga_scan_lines __read_mostly;
static unsigned int vga_rolled_over; /* last vc_origin offset before wrap */
static bool vga_hardscroll_enabled;
static bool vga_hardscroll_user_enable = true;
static int __init no_scroll(char *str)
{
/*
* Disabling scrollback is required for the Braillex ib80-piezo
* Braille reader made by F.H. Papenmeier (Germany).
* Use the "no-scroll" bootflag.
*/
vga_hardscroll_user_enable = vga_hardscroll_enabled = false;
return 1;
}
__setup("no-scroll", no_scroll);
/*
* By replacing the four outb_p with two back to back outw, we can reduce
* the window of opportunity to see text mislocated to the RHS of the
* console during heavy scrolling activity. However there is the remote
* possibility that some pre-dinosaur hardware won't like the back to back
* I/O. Since the Xservers get away with it, we should be able to as well.
*/
static inline void write_vga(unsigned char reg, unsigned int val)
{
unsigned int v1, v2;
unsigned long flags;
/*
* ddprintk might set the console position from interrupt
* handlers, thus the write has to be IRQ-atomic.
*/
raw_spin_lock_irqsave(&vga_lock, flags);
v1 = reg + (val & 0xff00);
v2 = reg + 1 + ((val << 8) & 0xff00);
outw(v1, vga_video_port_reg);
outw(v2, vga_video_port_reg);
raw_spin_unlock_irqrestore(&vga_lock, flags);
}
static inline void vga_set_mem_top(struct vc_data *c)
{
write_vga(12, (c->vc_visible_origin - vga_vram_base) / 2);
}
static void vgacon_restore_screen(struct vc_data *c)
{
if (c->vc_origin != c->vc_visible_origin)
vgacon_scrolldelta(c, 0);
}
static void vgacon_scrolldelta(struct vc_data *c, int lines)
{
vc_scrolldelta_helper(c, lines, vga_rolled_over, (void *)vga_vram_base,
vga_vram_size);
vga_set_mem_top(c);
}
[PATCH] Detaching fbcon: fix vgacon to allow retaking of the console One of the limitations of the framebuffer console system is its inablity to unload or detach itself from the console layer. And once it loads, it also locks in framebuffer drivers preventing their unload. Although the con2fbmap utility does provide a means to unload individual drivers, it requires that at least one framebuffer driver is loaded for use by fbcon. With this change, it is possible to detach fbcon from the console layer. If it is detached, it will reattach the boot console driver (which is permanently loaded) back to the console layer so the system can continue to work. As a consequence, fbcon will also decrement its reference count of individual framebuffer drivers, allowing all of these drivers to be unloaded even if fbcon is still loaded. Unless you use drivers that restores the display to text mode (rivafb and i810fb, for example), detaching fbcon does require assistance from userspace tools (ie, vbetools) for text mode to be restored completely. Without the help of these tools, fbcon will leave the VGA console corrupted. The methods that can be used will be described in Documentation/fb/fbcon.txt. Because the vt layer also increments the module reference count for each console driver, fbcon cannot be directly unloaded. It must be detached first prior to unload. Similarly, fbcon can be reattached to the console layer without having to reload the module. A nice feature if fbcon is compiled statically. Attaching and detaching fbcon is done via sysfs attributes. A class device entry for fbcon is created in /sys/class/graphics. The two attributes that controls this feature are detach and attach. Two other attributes that are piggybacked under /sys/class/graphics/fb[n] that are fbcon-specific, 'con_rotate' and 'con_rotate_all' are moved to fbcon. They are renamed as 'rotate' and 'rotate_all' respectively. Overall, this feature is a great help for developers working in the framebuffer or console layer. There is not need to continually reboot the kernel for every small change. It is also useful for regular users who wants to choose between a graphical console or a text console without having to reboot. Example usage for x86: /* start in text mode */ modprobe xxxfb modprobe fbcon /* graphical mode with fbcon using xxxfb */ echo 1 > /sys/class/graphics/fbcon/detach /* back to text mode, will produce corrupt display unless vbetool is used */ rmmod xxxfb modprobe yyyfb /* back to graphical mode with fbcon using yyyfb */ Before trying out this feature, please read Documentation/fb/fbcon.txt. This patch: In order for fbcon to detach itself from the console layer, vgacon, which is a boot console driver, must be fixed so it can retake the console multiple times, not just during init. The following needs to be done: - remove __init from the vgacon_startup, this is called again by take_over_console(). - vc->rows and vc->cols are set manually by vgacon during init. After init, vc_resize() can be used - make sure the scrollback_buffer is not reallocated Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 11:27:02 +04:00
static const char *vgacon_startup(void)
{
const char *display_desc = NULL;
u16 saved1, saved2;
volatile u16 *p;
if (screen_info.orig_video_isVGA == VIDEO_TYPE_VLFB ||
screen_info.orig_video_isVGA == VIDEO_TYPE_EFI) {
no_vga:
#ifdef CONFIG_DUMMY_CONSOLE
conswitchp = &dummy_con;
return conswitchp->con_startup();
#else
return NULL;
#endif
}
/* boot_params.screen_info reasonably initialized? */
if ((screen_info.orig_video_lines == 0) ||
(screen_info.orig_video_cols == 0))
goto no_vga;
/* VGA16 modes are not handled by VGACON */
if ((screen_info.orig_video_mode == 0x0D) || /* 320x200/4 */
(screen_info.orig_video_mode == 0x0E) || /* 640x200/4 */
(screen_info.orig_video_mode == 0x10) || /* 640x350/4 */
(screen_info.orig_video_mode == 0x12) || /* 640x480/4 */
(screen_info.orig_video_mode == 0x6A)) /* 800x600/4 (VESA) */
goto no_vga;
vga_video_num_lines = screen_info.orig_video_lines;
vga_video_num_columns = screen_info.orig_video_cols;
vgastate.vgabase = NULL;
if (screen_info.orig_video_mode == 7) {
/* Monochrome display */
vga_vram_base = 0xb0000;
vga_video_port_reg = VGA_CRT_IM;
vga_video_port_val = VGA_CRT_DM;
if ((screen_info.orig_video_ega_bx & 0xff) != 0x10) {
static struct resource ega_console_resource =
{ .name = "ega",
.flags = IORESOURCE_IO,
.start = 0x3B0,
.end = 0x3BF };
vga_video_type = VIDEO_TYPE_EGAM;
vga_vram_size = 0x8000;
display_desc = "EGA+";
request_resource(&ioport_resource,
&ega_console_resource);
} else {
static struct resource mda1_console_resource =
{ .name = "mda",
.flags = IORESOURCE_IO,
.start = 0x3B0,
.end = 0x3BB };
static struct resource mda2_console_resource =
{ .name = "mda",
.flags = IORESOURCE_IO,
.start = 0x3BF,
.end = 0x3BF };
vga_video_type = VIDEO_TYPE_MDA;
vga_vram_size = 0x2000;
display_desc = "*MDA";
request_resource(&ioport_resource,
&mda1_console_resource);
request_resource(&ioport_resource,
&mda2_console_resource);
vga_video_font_height = 14;
}
} else {
/* If not, it is color. */
vga_can_do_color = true;
vga_vram_base = 0xb8000;
vga_video_port_reg = VGA_CRT_IC;
vga_video_port_val = VGA_CRT_DC;
if ((screen_info.orig_video_ega_bx & 0xff) != 0x10) {
int i;
vga_vram_size = 0x8000;
if (!screen_info.orig_video_isVGA) {
static struct resource ega_console_resource =
{ .name = "ega",
.flags = IORESOURCE_IO,
.start = 0x3C0,
.end = 0x3DF };
vga_video_type = VIDEO_TYPE_EGAC;
display_desc = "EGA";
request_resource(&ioport_resource,
&ega_console_resource);
} else {
static struct resource vga_console_resource =
{ .name = "vga+",
.flags = IORESOURCE_IO,
.start = 0x3C0,
.end = 0x3DF };
vga_video_type = VIDEO_TYPE_VGAC;
display_desc = "VGA+";
request_resource(&ioport_resource,
&vga_console_resource);
/*
* Normalise the palette registers, to point
* the 16 screen colours to the first 16
* DAC entries.
*/
for (i = 0; i < 16; i++) {
inb_p(VGA_IS1_RC);
outb_p(i, VGA_ATT_W);
outb_p(i, VGA_ATT_W);
}
outb_p(0x20, VGA_ATT_W);
/*
* Now set the DAC registers back to their
* default values
*/
for (i = 0; i < 16; i++) {
outb_p(color_table[i], VGA_PEL_IW);
outb_p(default_red[i], VGA_PEL_D);
outb_p(default_grn[i], VGA_PEL_D);
outb_p(default_blu[i], VGA_PEL_D);
}
}
} else {
static struct resource cga_console_resource =
{ .name = "cga",
.flags = IORESOURCE_IO,
.start = 0x3D4,
.end = 0x3D5 };
vga_video_type = VIDEO_TYPE_CGA;
vga_vram_size = 0x2000;
display_desc = "*CGA";
request_resource(&ioport_resource,
&cga_console_resource);
vga_video_font_height = 8;
}
}
vga_vram_base = VGA_MAP_MEM(vga_vram_base, vga_vram_size);
vga_vram_end = vga_vram_base + vga_vram_size;
/*
* Find out if there is a graphics card present.
* Are there smarter methods around?
*/
p = (volatile u16 *) vga_vram_base;
saved1 = scr_readw(p);
saved2 = scr_readw(p + 1);
scr_writew(0xAA55, p);
scr_writew(0x55AA, p + 1);
if (scr_readw(p) != 0xAA55 || scr_readw(p + 1) != 0x55AA) {
scr_writew(saved1, p);
scr_writew(saved2, p + 1);
goto no_vga;
}
scr_writew(0x55AA, p);
scr_writew(0xAA55, p + 1);
if (scr_readw(p) != 0x55AA || scr_readw(p + 1) != 0xAA55) {
scr_writew(saved1, p);
scr_writew(saved2, p + 1);
goto no_vga;
}
scr_writew(saved1, p);
scr_writew(saved2, p + 1);
if (vga_video_type == VIDEO_TYPE_EGAC
|| vga_video_type == VIDEO_TYPE_VGAC
|| vga_video_type == VIDEO_TYPE_EGAM) {
vga_hardscroll_enabled = vga_hardscroll_user_enable;
vga_default_font_height = screen_info.orig_video_points;
vga_video_font_height = screen_info.orig_video_points;
/* This may be suboptimal but is a safe bet - go with it */
vga_scan_lines =
vga_video_font_height * vga_video_num_lines;
}
vgacon_xres = screen_info.orig_video_cols * VGA_FONTWIDTH;
vgacon_yres = vga_scan_lines;
[PATCH] Detaching fbcon: fix vgacon to allow retaking of the console One of the limitations of the framebuffer console system is its inablity to unload or detach itself from the console layer. And once it loads, it also locks in framebuffer drivers preventing their unload. Although the con2fbmap utility does provide a means to unload individual drivers, it requires that at least one framebuffer driver is loaded for use by fbcon. With this change, it is possible to detach fbcon from the console layer. If it is detached, it will reattach the boot console driver (which is permanently loaded) back to the console layer so the system can continue to work. As a consequence, fbcon will also decrement its reference count of individual framebuffer drivers, allowing all of these drivers to be unloaded even if fbcon is still loaded. Unless you use drivers that restores the display to text mode (rivafb and i810fb, for example), detaching fbcon does require assistance from userspace tools (ie, vbetools) for text mode to be restored completely. Without the help of these tools, fbcon will leave the VGA console corrupted. The methods that can be used will be described in Documentation/fb/fbcon.txt. Because the vt layer also increments the module reference count for each console driver, fbcon cannot be directly unloaded. It must be detached first prior to unload. Similarly, fbcon can be reattached to the console layer without having to reload the module. A nice feature if fbcon is compiled statically. Attaching and detaching fbcon is done via sysfs attributes. A class device entry for fbcon is created in /sys/class/graphics. The two attributes that controls this feature are detach and attach. Two other attributes that are piggybacked under /sys/class/graphics/fb[n] that are fbcon-specific, 'con_rotate' and 'con_rotate_all' are moved to fbcon. They are renamed as 'rotate' and 'rotate_all' respectively. Overall, this feature is a great help for developers working in the framebuffer or console layer. There is not need to continually reboot the kernel for every small change. It is also useful for regular users who wants to choose between a graphical console or a text console without having to reboot. Example usage for x86: /* start in text mode */ modprobe xxxfb modprobe fbcon /* graphical mode with fbcon using xxxfb */ echo 1 > /sys/class/graphics/fbcon/detach /* back to text mode, will produce corrupt display unless vbetool is used */ rmmod xxxfb modprobe yyyfb /* back to graphical mode with fbcon using yyyfb */ Before trying out this feature, please read Documentation/fb/fbcon.txt. This patch: In order for fbcon to detach itself from the console layer, vgacon, which is a boot console driver, must be fixed so it can retake the console multiple times, not just during init. The following needs to be done: - remove __init from the vgacon_startup, this is called again by take_over_console(). - vc->rows and vc->cols are set manually by vgacon during init. After init, vc_resize() can be used - make sure the scrollback_buffer is not reallocated Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 11:27:02 +04:00
return display_desc;
}
static void vgacon_init(struct vc_data *c, int init)
{
struct uni_pagedict *p;
[PATCH] Detaching fbcon: fix vgacon to allow retaking of the console One of the limitations of the framebuffer console system is its inablity to unload or detach itself from the console layer. And once it loads, it also locks in framebuffer drivers preventing their unload. Although the con2fbmap utility does provide a means to unload individual drivers, it requires that at least one framebuffer driver is loaded for use by fbcon. With this change, it is possible to detach fbcon from the console layer. If it is detached, it will reattach the boot console driver (which is permanently loaded) back to the console layer so the system can continue to work. As a consequence, fbcon will also decrement its reference count of individual framebuffer drivers, allowing all of these drivers to be unloaded even if fbcon is still loaded. Unless you use drivers that restores the display to text mode (rivafb and i810fb, for example), detaching fbcon does require assistance from userspace tools (ie, vbetools) for text mode to be restored completely. Without the help of these tools, fbcon will leave the VGA console corrupted. The methods that can be used will be described in Documentation/fb/fbcon.txt. Because the vt layer also increments the module reference count for each console driver, fbcon cannot be directly unloaded. It must be detached first prior to unload. Similarly, fbcon can be reattached to the console layer without having to reload the module. A nice feature if fbcon is compiled statically. Attaching and detaching fbcon is done via sysfs attributes. A class device entry for fbcon is created in /sys/class/graphics. The two attributes that controls this feature are detach and attach. Two other attributes that are piggybacked under /sys/class/graphics/fb[n] that are fbcon-specific, 'con_rotate' and 'con_rotate_all' are moved to fbcon. They are renamed as 'rotate' and 'rotate_all' respectively. Overall, this feature is a great help for developers working in the framebuffer or console layer. There is not need to continually reboot the kernel for every small change. It is also useful for regular users who wants to choose between a graphical console or a text console without having to reboot. Example usage for x86: /* start in text mode */ modprobe xxxfb modprobe fbcon /* graphical mode with fbcon using xxxfb */ echo 1 > /sys/class/graphics/fbcon/detach /* back to text mode, will produce corrupt display unless vbetool is used */ rmmod xxxfb modprobe yyyfb /* back to graphical mode with fbcon using yyyfb */ Before trying out this feature, please read Documentation/fb/fbcon.txt. This patch: In order for fbcon to detach itself from the console layer, vgacon, which is a boot console driver, must be fixed so it can retake the console multiple times, not just during init. The following needs to be done: - remove __init from the vgacon_startup, this is called again by take_over_console(). - vc->rows and vc->cols are set manually by vgacon during init. After init, vc_resize() can be used - make sure the scrollback_buffer is not reallocated Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 11:27:02 +04:00
/*
vgacon: Propagate console boot parameters before calling `vc_resize' Fix a division by zero in `vgacon_resize' with a backtrace like: vgacon_resize vc_do_resize vgacon_init do_bind_con_driver do_unbind_con_driver fbcon_fb_unbind do_unregister_framebuffer do_register_framebuffer register_framebuffer __drm_fb_helper_initial_config_and_unlock drm_helper_hpd_irq_event dw_hdmi_irq irq_thread kthread caused by `c->vc_cell_height' not having been initialized. This has only started to trigger with commit 860dafa90259 ("vt: Fix character height handling with VT_RESIZEX"), however the ultimate offender is commit 50ec42edd978 ("[PATCH] Detaching fbcon: fix vgacon to allow retaking of the console"). Said commit has added a call to `vc_resize' whenever `vgacon_init' is called with the `init' argument set to 0, which did not happen before. And the call is made before a key vgacon boot parameter retrieved in `vgacon_startup' has been propagated in `vgacon_init' for `vc_resize' to use to the console structure being worked on. Previously the parameter was `c->vc_font.height' and now it is `c->vc_cell_height'. In this particular scenario the registration of fbcon has failed and vt resorts to vgacon. Now fbcon does have initialized `c->vc_font.height' somehow, unlike `c->vc_cell_height', which is why this code did not crash before, but either way the boot parameters should have been copied to the console structure ahead of the call to `vc_resize' rather than afterwards, so that first the call has a chance to use them and second they do not change the console structure to something possibly different from what was used by `vc_resize'. Move the propagation of the vgacon boot parameters ahead of the call to `vc_resize' then. Adjust the comment accordingly. Fixes: 50ec42edd978 ("[PATCH] Detaching fbcon: fix vgacon to allow retaking of the console") Cc: stable@vger.kernel.org # v2.6.18+ Reported-by: Wim Osterholt <wim@djo.tudelft.nl> Reported-by: Pavel V. Panteleev <panteleev_p@mcst.ru> Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2110252317110.58149@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-26 01:26:22 +03:00
* We cannot be loaded as a module, therefore init will be 1
* if we are the default console, however if we are a fallback
* console, for example if fbcon has failed registration, then
* init will be 0, so we need to make sure our boot parameters
* have been copied to the console structure for vgacon_resize
* ultimately called by vc_resize. Any subsequent calls to
* vgacon_init init will have init set to 0 too.
[PATCH] Detaching fbcon: fix vgacon to allow retaking of the console One of the limitations of the framebuffer console system is its inablity to unload or detach itself from the console layer. And once it loads, it also locks in framebuffer drivers preventing their unload. Although the con2fbmap utility does provide a means to unload individual drivers, it requires that at least one framebuffer driver is loaded for use by fbcon. With this change, it is possible to detach fbcon from the console layer. If it is detached, it will reattach the boot console driver (which is permanently loaded) back to the console layer so the system can continue to work. As a consequence, fbcon will also decrement its reference count of individual framebuffer drivers, allowing all of these drivers to be unloaded even if fbcon is still loaded. Unless you use drivers that restores the display to text mode (rivafb and i810fb, for example), detaching fbcon does require assistance from userspace tools (ie, vbetools) for text mode to be restored completely. Without the help of these tools, fbcon will leave the VGA console corrupted. The methods that can be used will be described in Documentation/fb/fbcon.txt. Because the vt layer also increments the module reference count for each console driver, fbcon cannot be directly unloaded. It must be detached first prior to unload. Similarly, fbcon can be reattached to the console layer without having to reload the module. A nice feature if fbcon is compiled statically. Attaching and detaching fbcon is done via sysfs attributes. A class device entry for fbcon is created in /sys/class/graphics. The two attributes that controls this feature are detach and attach. Two other attributes that are piggybacked under /sys/class/graphics/fb[n] that are fbcon-specific, 'con_rotate' and 'con_rotate_all' are moved to fbcon. They are renamed as 'rotate' and 'rotate_all' respectively. Overall, this feature is a great help for developers working in the framebuffer or console layer. There is not need to continually reboot the kernel for every small change. It is also useful for regular users who wants to choose between a graphical console or a text console without having to reboot. Example usage for x86: /* start in text mode */ modprobe xxxfb modprobe fbcon /* graphical mode with fbcon using xxxfb */ echo 1 > /sys/class/graphics/fbcon/detach /* back to text mode, will produce corrupt display unless vbetool is used */ rmmod xxxfb modprobe yyyfb /* back to graphical mode with fbcon using yyyfb */ Before trying out this feature, please read Documentation/fb/fbcon.txt. This patch: In order for fbcon to detach itself from the console layer, vgacon, which is a boot console driver, must be fixed so it can retake the console multiple times, not just during init. The following needs to be done: - remove __init from the vgacon_startup, this is called again by take_over_console(). - vc->rows and vc->cols are set manually by vgacon during init. After init, vc_resize() can be used - make sure the scrollback_buffer is not reallocated Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 11:27:02 +04:00
*/
c->vc_can_do_color = vga_can_do_color;
vgacon: Propagate console boot parameters before calling `vc_resize' Fix a division by zero in `vgacon_resize' with a backtrace like: vgacon_resize vc_do_resize vgacon_init do_bind_con_driver do_unbind_con_driver fbcon_fb_unbind do_unregister_framebuffer do_register_framebuffer register_framebuffer __drm_fb_helper_initial_config_and_unlock drm_helper_hpd_irq_event dw_hdmi_irq irq_thread kthread caused by `c->vc_cell_height' not having been initialized. This has only started to trigger with commit 860dafa90259 ("vt: Fix character height handling with VT_RESIZEX"), however the ultimate offender is commit 50ec42edd978 ("[PATCH] Detaching fbcon: fix vgacon to allow retaking of the console"). Said commit has added a call to `vc_resize' whenever `vgacon_init' is called with the `init' argument set to 0, which did not happen before. And the call is made before a key vgacon boot parameter retrieved in `vgacon_startup' has been propagated in `vgacon_init' for `vc_resize' to use to the console structure being worked on. Previously the parameter was `c->vc_font.height' and now it is `c->vc_cell_height'. In this particular scenario the registration of fbcon has failed and vt resorts to vgacon. Now fbcon does have initialized `c->vc_font.height' somehow, unlike `c->vc_cell_height', which is why this code did not crash before, but either way the boot parameters should have been copied to the console structure ahead of the call to `vc_resize' rather than afterwards, so that first the call has a chance to use them and second they do not change the console structure to something possibly different from what was used by `vc_resize'. Move the propagation of the vgacon boot parameters ahead of the call to `vc_resize' then. Adjust the comment accordingly. Fixes: 50ec42edd978 ("[PATCH] Detaching fbcon: fix vgacon to allow retaking of the console") Cc: stable@vger.kernel.org # v2.6.18+ Reported-by: Wim Osterholt <wim@djo.tudelft.nl> Reported-by: Pavel V. Panteleev <panteleev_p@mcst.ru> Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2110252317110.58149@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-26 01:26:22 +03:00
c->vc_scan_lines = vga_scan_lines;
c->vc_font.height = c->vc_cell_height = vga_video_font_height;
[PATCH] Detaching fbcon: fix vgacon to allow retaking of the console One of the limitations of the framebuffer console system is its inablity to unload or detach itself from the console layer. And once it loads, it also locks in framebuffer drivers preventing their unload. Although the con2fbmap utility does provide a means to unload individual drivers, it requires that at least one framebuffer driver is loaded for use by fbcon. With this change, it is possible to detach fbcon from the console layer. If it is detached, it will reattach the boot console driver (which is permanently loaded) back to the console layer so the system can continue to work. As a consequence, fbcon will also decrement its reference count of individual framebuffer drivers, allowing all of these drivers to be unloaded even if fbcon is still loaded. Unless you use drivers that restores the display to text mode (rivafb and i810fb, for example), detaching fbcon does require assistance from userspace tools (ie, vbetools) for text mode to be restored completely. Without the help of these tools, fbcon will leave the VGA console corrupted. The methods that can be used will be described in Documentation/fb/fbcon.txt. Because the vt layer also increments the module reference count for each console driver, fbcon cannot be directly unloaded. It must be detached first prior to unload. Similarly, fbcon can be reattached to the console layer without having to reload the module. A nice feature if fbcon is compiled statically. Attaching and detaching fbcon is done via sysfs attributes. A class device entry for fbcon is created in /sys/class/graphics. The two attributes that controls this feature are detach and attach. Two other attributes that are piggybacked under /sys/class/graphics/fb[n] that are fbcon-specific, 'con_rotate' and 'con_rotate_all' are moved to fbcon. They are renamed as 'rotate' and 'rotate_all' respectively. Overall, this feature is a great help for developers working in the framebuffer or console layer. There is not need to continually reboot the kernel for every small change. It is also useful for regular users who wants to choose between a graphical console or a text console without having to reboot. Example usage for x86: /* start in text mode */ modprobe xxxfb modprobe fbcon /* graphical mode with fbcon using xxxfb */ echo 1 > /sys/class/graphics/fbcon/detach /* back to text mode, will produce corrupt display unless vbetool is used */ rmmod xxxfb modprobe yyyfb /* back to graphical mode with fbcon using yyyfb */ Before trying out this feature, please read Documentation/fb/fbcon.txt. This patch: In order for fbcon to detach itself from the console layer, vgacon, which is a boot console driver, must be fixed so it can retake the console multiple times, not just during init. The following needs to be done: - remove __init from the vgacon_startup, this is called again by take_over_console(). - vc->rows and vc->cols are set manually by vgacon during init. After init, vc_resize() can be used - make sure the scrollback_buffer is not reallocated Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-26 11:27:02 +04:00
/* set dimensions manually if init != 0 since vc_resize() will fail */
if (init) {
c->vc_cols = vga_video_num_columns;
c->vc_rows = vga_video_num_lines;
} else
vc_resize(c, vga_video_num_columns, vga_video_num_lines);
c->vc_complement_mask = 0x7700;
if (vga_512_chars)
c->vc_hi_font_mask = 0x0800;
p = *c->uni_pagedict_loc;
if (c->uni_pagedict_loc != &vgacon_uni_pagedir) {
con_free_unimap(c);
c->uni_pagedict_loc = &vgacon_uni_pagedir;
vgacon_refcount++;
}
if (!vgacon_uni_pagedir && p)
con_set_default_unimap(c);
/* Only set the default if the user didn't deliberately override it */
if (global_cursor_default == -1)
global_cursor_default =
!(screen_info.flags & VIDEO_FLAGS_NOCURSOR);
}
static void vgacon_deinit(struct vc_data *c)
{
/* When closing the active console, reset video origin */
if (con_is_visible(c)) {
c->vc_visible_origin = vga_vram_base;
vga_set_mem_top(c);
}
if (!--vgacon_refcount)
con_free_unimap(c);
c->uni_pagedict_loc = &c->uni_pagedict;
con_set_default_unimap(c);
}
static u8 vgacon_build_attr(struct vc_data *c, u8 color,
enum vc_intensity intensity,
bool blink, bool underline, bool reverse,
bool italic)
{
u8 attr = color;
if (vga_can_do_color) {
if (italic)
attr = (attr & 0xF0) | c->vc_itcolor;
else if (underline)
attr = (attr & 0xf0) | c->vc_ulcolor;
else if (intensity == VCI_HALF_BRIGHT)
attr = (attr & 0xf0) | c->vc_halfcolor;
}
if (reverse)
attr =
((attr) & 0x88) | ((((attr) >> 4) | ((attr) << 4)) &
0x77);
if (blink)
attr ^= 0x80;
if (intensity == VCI_BOLD)
attr ^= 0x08;
if (!vga_can_do_color) {
if (italic)
attr = (attr & 0xF8) | 0x02;
else if (underline)
attr = (attr & 0xf8) | 0x01;
else if (intensity == VCI_HALF_BRIGHT)
attr = (attr & 0xf0) | 0x08;
}
return attr;
}
static void vgacon_invert_region(struct vc_data *c, u16 * p, int count)
{
const bool col = vga_can_do_color;
while (count--) {
u16 a = scr_readw(p);
if (col)
a = ((a) & 0x88ff) | (((a) & 0x7000) >> 4) |
(((a) & 0x0700) << 4);
else
a ^= ((a & 0x0700) == 0x0100) ? 0x7000 : 0x7700;
scr_writew(a, p++);
}
}
static void vgacon_set_cursor_size(int xpos, int from, int to)
{
unsigned long flags;
int curs, cure;
if ((from == cursor_size_lastfrom) && (to == cursor_size_lastto))
return;
cursor_size_lastfrom = from;
cursor_size_lastto = to;
raw_spin_lock_irqsave(&vga_lock, flags);
if (vga_video_type >= VIDEO_TYPE_VGAC) {
outb_p(VGA_CRTC_CURSOR_START, vga_video_port_reg);
curs = inb_p(vga_video_port_val);
outb_p(VGA_CRTC_CURSOR_END, vga_video_port_reg);
cure = inb_p(vga_video_port_val);
} else {
curs = 0;
cure = 0;
}
curs = (curs & 0xc0) | from;
cure = (cure & 0xe0) | to;
outb_p(VGA_CRTC_CURSOR_START, vga_video_port_reg);
outb_p(curs, vga_video_port_val);
outb_p(VGA_CRTC_CURSOR_END, vga_video_port_reg);
outb_p(cure, vga_video_port_val);
raw_spin_unlock_irqrestore(&vga_lock, flags);
}
static void vgacon_cursor(struct vc_data *c, int mode)
{
if (c->vc_mode != KD_TEXT)
return;
vgacon_restore_screen(c);
switch (mode) {
case CM_ERASE:
write_vga(14, (c->vc_pos - vga_vram_base) / 2);
if (vga_video_type >= VIDEO_TYPE_VGAC)
vgacon_set_cursor_size(c->state.x, 31, 30);
else
vgacon_set_cursor_size(c->state.x, 31, 31);
break;
case CM_MOVE:
case CM_DRAW:
write_vga(14, (c->vc_pos - vga_vram_base) / 2);
switch (CUR_SIZE(c->vc_cursor_type)) {
case CUR_UNDERLINE:
vgacon_set_cursor_size(c->state.x,
vt: Fix character height handling with VT_RESIZEX Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter which is the number of pixel rows per character (cell) rather than the height of the font used. For framebuffer devices the two values are always the same, because the former is inferred from the latter one. For VGA used as a true text mode device these two parameters are independent from each other: the number of pixel rows per character is set in the CRT controller, while font height is in fact hardwired to 32 pixel rows and fonts of heights below that value are handled by padding their data with blanks when loaded to hardware for use by the character generator. One can change the setting in the CRT controller and it will update the screen contents accordingly regardless of the font loaded. The `v_clin' parameter is used by the `vgacon' driver to set the height of the character cell and then the cursor position within. Make the parameter explicit then, by defining a new `vc_cell_height' struct member of `vc_data', set it instead of `vc_font.height' from `v_clin' in the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver except where actual font data is accessed which as noted above is independent from the CRTC setting. This way the framebuffer console driver is free to ignore the `v_clin' parameter as irrelevant, as it always should have, avoiding any issues attempts to give the parameter a meaning there could have caused, such as one that has led to commit 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE"): "syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2], for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height larger than actual font height calculated by con_font_set() from ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates minimal amount of memory based on actual font height calculated by con_font_set(), use of vt_resizex() can cause UAF/OOB read for font data." The problem first appeared around Linux 2.5.66 which predates our repo history, but the origin could be identified with the old MIPS/Linux repo also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git> as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX code in `vt_ioctl' was updated as follows: if (clin) - video_font_height = clin; + vc->vc_font.height = clin; making the parameter apply to framebuffer devices as well, perhaps due to the use of "font" in the name of the original `video_font_height' variable. Use "cell" in the new struct member then to avoid ambiguity. References: [1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837 [2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3 Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # v2.6.12+ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-05-13 12:51:50 +03:00
c->vc_cell_height -
(c->vc_cell_height <
10 ? 2 : 3),
vt: Fix character height handling with VT_RESIZEX Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter which is the number of pixel rows per character (cell) rather than the height of the font used. For framebuffer devices the two values are always the same, because the former is inferred from the latter one. For VGA used as a true text mode device these two parameters are independent from each other: the number of pixel rows per character is set in the CRT controller, while font height is in fact hardwired to 32 pixel rows and fonts of heights below that value are handled by padding their data with blanks when loaded to hardware for use by the character generator. One can change the setting in the CRT controller and it will update the screen contents accordingly regardless of the font loaded. The `v_clin' parameter is used by the `vgacon' driver to set the height of the character cell and then the cursor position within. Make the parameter explicit then, by defining a new `vc_cell_height' struct member of `vc_data', set it instead of `vc_font.height' from `v_clin' in the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver except where actual font data is accessed which as noted above is independent from the CRTC setting. This way the framebuffer console driver is free to ignore the `v_clin' parameter as irrelevant, as it always should have, avoiding any issues attempts to give the parameter a meaning there could have caused, such as one that has led to commit 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE"): "syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2], for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height larger than actual font height calculated by con_font_set() from ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates minimal amount of memory based on actual font height calculated by con_font_set(), use of vt_resizex() can cause UAF/OOB read for font data." The problem first appeared around Linux 2.5.66 which predates our repo history, but the origin could be identified with the old MIPS/Linux repo also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git> as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX code in `vt_ioctl' was updated as follows: if (clin) - video_font_height = clin; + vc->vc_font.height = clin; making the parameter apply to framebuffer devices as well, perhaps due to the use of "font" in the name of the original `video_font_height' variable. Use "cell" in the new struct member then to avoid ambiguity. References: [1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837 [2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3 Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # v2.6.12+ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-05-13 12:51:50 +03:00
c->vc_cell_height -
(c->vc_cell_height <
10 ? 1 : 2));
break;
case CUR_TWO_THIRDS:
vgacon_set_cursor_size(c->state.x,
vt: Fix character height handling with VT_RESIZEX Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter which is the number of pixel rows per character (cell) rather than the height of the font used. For framebuffer devices the two values are always the same, because the former is inferred from the latter one. For VGA used as a true text mode device these two parameters are independent from each other: the number of pixel rows per character is set in the CRT controller, while font height is in fact hardwired to 32 pixel rows and fonts of heights below that value are handled by padding their data with blanks when loaded to hardware for use by the character generator. One can change the setting in the CRT controller and it will update the screen contents accordingly regardless of the font loaded. The `v_clin' parameter is used by the `vgacon' driver to set the height of the character cell and then the cursor position within. Make the parameter explicit then, by defining a new `vc_cell_height' struct member of `vc_data', set it instead of `vc_font.height' from `v_clin' in the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver except where actual font data is accessed which as noted above is independent from the CRTC setting. This way the framebuffer console driver is free to ignore the `v_clin' parameter as irrelevant, as it always should have, avoiding any issues attempts to give the parameter a meaning there could have caused, such as one that has led to commit 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE"): "syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2], for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height larger than actual font height calculated by con_font_set() from ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates minimal amount of memory based on actual font height calculated by con_font_set(), use of vt_resizex() can cause UAF/OOB read for font data." The problem first appeared around Linux 2.5.66 which predates our repo history, but the origin could be identified with the old MIPS/Linux repo also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git> as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX code in `vt_ioctl' was updated as follows: if (clin) - video_font_height = clin; + vc->vc_font.height = clin; making the parameter apply to framebuffer devices as well, perhaps due to the use of "font" in the name of the original `video_font_height' variable. Use "cell" in the new struct member then to avoid ambiguity. References: [1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837 [2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3 Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # v2.6.12+ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-05-13 12:51:50 +03:00
c->vc_cell_height / 3,
c->vc_cell_height -
(c->vc_cell_height <
10 ? 1 : 2));
break;
case CUR_LOWER_THIRD:
vgacon_set_cursor_size(c->state.x,
vt: Fix character height handling with VT_RESIZEX Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter which is the number of pixel rows per character (cell) rather than the height of the font used. For framebuffer devices the two values are always the same, because the former is inferred from the latter one. For VGA used as a true text mode device these two parameters are independent from each other: the number of pixel rows per character is set in the CRT controller, while font height is in fact hardwired to 32 pixel rows and fonts of heights below that value are handled by padding their data with blanks when loaded to hardware for use by the character generator. One can change the setting in the CRT controller and it will update the screen contents accordingly regardless of the font loaded. The `v_clin' parameter is used by the `vgacon' driver to set the height of the character cell and then the cursor position within. Make the parameter explicit then, by defining a new `vc_cell_height' struct member of `vc_data', set it instead of `vc_font.height' from `v_clin' in the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver except where actual font data is accessed which as noted above is independent from the CRTC setting. This way the framebuffer console driver is free to ignore the `v_clin' parameter as irrelevant, as it always should have, avoiding any issues attempts to give the parameter a meaning there could have caused, such as one that has led to commit 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE"): "syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2], for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height larger than actual font height calculated by con_font_set() from ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates minimal amount of memory based on actual font height calculated by con_font_set(), use of vt_resizex() can cause UAF/OOB read for font data." The problem first appeared around Linux 2.5.66 which predates our repo history, but the origin could be identified with the old MIPS/Linux repo also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git> as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX code in `vt_ioctl' was updated as follows: if (clin) - video_font_height = clin; + vc->vc_font.height = clin; making the parameter apply to framebuffer devices as well, perhaps due to the use of "font" in the name of the original `video_font_height' variable. Use "cell" in the new struct member then to avoid ambiguity. References: [1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837 [2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3 Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # v2.6.12+ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-05-13 12:51:50 +03:00
(c->vc_cell_height * 2) / 3,
c->vc_cell_height -
(c->vc_cell_height <
10 ? 1 : 2));
break;
case CUR_LOWER_HALF:
vgacon_set_cursor_size(c->state.x,
vt: Fix character height handling with VT_RESIZEX Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter which is the number of pixel rows per character (cell) rather than the height of the font used. For framebuffer devices the two values are always the same, because the former is inferred from the latter one. For VGA used as a true text mode device these two parameters are independent from each other: the number of pixel rows per character is set in the CRT controller, while font height is in fact hardwired to 32 pixel rows and fonts of heights below that value are handled by padding their data with blanks when loaded to hardware for use by the character generator. One can change the setting in the CRT controller and it will update the screen contents accordingly regardless of the font loaded. The `v_clin' parameter is used by the `vgacon' driver to set the height of the character cell and then the cursor position within. Make the parameter explicit then, by defining a new `vc_cell_height' struct member of `vc_data', set it instead of `vc_font.height' from `v_clin' in the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver except where actual font data is accessed which as noted above is independent from the CRTC setting. This way the framebuffer console driver is free to ignore the `v_clin' parameter as irrelevant, as it always should have, avoiding any issues attempts to give the parameter a meaning there could have caused, such as one that has led to commit 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE"): "syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2], for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height larger than actual font height calculated by con_font_set() from ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates minimal amount of memory based on actual font height calculated by con_font_set(), use of vt_resizex() can cause UAF/OOB read for font data." The problem first appeared around Linux 2.5.66 which predates our repo history, but the origin could be identified with the old MIPS/Linux repo also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git> as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX code in `vt_ioctl' was updated as follows: if (clin) - video_font_height = clin; + vc->vc_font.height = clin; making the parameter apply to framebuffer devices as well, perhaps due to the use of "font" in the name of the original `video_font_height' variable. Use "cell" in the new struct member then to avoid ambiguity. References: [1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837 [2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3 Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # v2.6.12+ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-05-13 12:51:50 +03:00
c->vc_cell_height / 2,
c->vc_cell_height -
(c->vc_cell_height <
10 ? 1 : 2));
break;
case CUR_NONE:
if (vga_video_type >= VIDEO_TYPE_VGAC)
vgacon_set_cursor_size(c->state.x, 31, 30);
else
vgacon_set_cursor_size(c->state.x, 31, 31);
break;
default:
vgacon_set_cursor_size(c->state.x, 1,
vt: Fix character height handling with VT_RESIZEX Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter which is the number of pixel rows per character (cell) rather than the height of the font used. For framebuffer devices the two values are always the same, because the former is inferred from the latter one. For VGA used as a true text mode device these two parameters are independent from each other: the number of pixel rows per character is set in the CRT controller, while font height is in fact hardwired to 32 pixel rows and fonts of heights below that value are handled by padding their data with blanks when loaded to hardware for use by the character generator. One can change the setting in the CRT controller and it will update the screen contents accordingly regardless of the font loaded. The `v_clin' parameter is used by the `vgacon' driver to set the height of the character cell and then the cursor position within. Make the parameter explicit then, by defining a new `vc_cell_height' struct member of `vc_data', set it instead of `vc_font.height' from `v_clin' in the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver except where actual font data is accessed which as noted above is independent from the CRTC setting. This way the framebuffer console driver is free to ignore the `v_clin' parameter as irrelevant, as it always should have, avoiding any issues attempts to give the parameter a meaning there could have caused, such as one that has led to commit 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE"): "syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2], for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height larger than actual font height calculated by con_font_set() from ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates minimal amount of memory based on actual font height calculated by con_font_set(), use of vt_resizex() can cause UAF/OOB read for font data." The problem first appeared around Linux 2.5.66 which predates our repo history, but the origin could be identified with the old MIPS/Linux repo also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git> as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX code in `vt_ioctl' was updated as follows: if (clin) - video_font_height = clin; + vc->vc_font.height = clin; making the parameter apply to framebuffer devices as well, perhaps due to the use of "font" in the name of the original `video_font_height' variable. Use "cell" in the new struct member then to avoid ambiguity. References: [1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837 [2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3 Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # v2.6.12+ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-05-13 12:51:50 +03:00
c->vc_cell_height);
break;
}
break;
}
}
static int vgacon_doresize(struct vc_data *c,
unsigned int width, unsigned int height)
{
unsigned long flags;
vt: Fix character height handling with VT_RESIZEX Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter which is the number of pixel rows per character (cell) rather than the height of the font used. For framebuffer devices the two values are always the same, because the former is inferred from the latter one. For VGA used as a true text mode device these two parameters are independent from each other: the number of pixel rows per character is set in the CRT controller, while font height is in fact hardwired to 32 pixel rows and fonts of heights below that value are handled by padding their data with blanks when loaded to hardware for use by the character generator. One can change the setting in the CRT controller and it will update the screen contents accordingly regardless of the font loaded. The `v_clin' parameter is used by the `vgacon' driver to set the height of the character cell and then the cursor position within. Make the parameter explicit then, by defining a new `vc_cell_height' struct member of `vc_data', set it instead of `vc_font.height' from `v_clin' in the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver except where actual font data is accessed which as noted above is independent from the CRTC setting. This way the framebuffer console driver is free to ignore the `v_clin' parameter as irrelevant, as it always should have, avoiding any issues attempts to give the parameter a meaning there could have caused, such as one that has led to commit 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE"): "syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2], for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height larger than actual font height calculated by con_font_set() from ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates minimal amount of memory based on actual font height calculated by con_font_set(), use of vt_resizex() can cause UAF/OOB read for font data." The problem first appeared around Linux 2.5.66 which predates our repo history, but the origin could be identified with the old MIPS/Linux repo also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git> as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX code in `vt_ioctl' was updated as follows: if (clin) - video_font_height = clin; + vc->vc_font.height = clin; making the parameter apply to framebuffer devices as well, perhaps due to the use of "font" in the name of the original `video_font_height' variable. Use "cell" in the new struct member then to avoid ambiguity. References: [1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837 [2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3 Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # v2.6.12+ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-05-13 12:51:50 +03:00
unsigned int scanlines = height * c->vc_cell_height;
u8 scanlines_lo = 0, r7 = 0, vsync_end = 0, mode, max_scan;
raw_spin_lock_irqsave(&vga_lock, flags);
vgacon_xres = width * VGA_FONTWIDTH;
vt: Fix character height handling with VT_RESIZEX Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter which is the number of pixel rows per character (cell) rather than the height of the font used. For framebuffer devices the two values are always the same, because the former is inferred from the latter one. For VGA used as a true text mode device these two parameters are independent from each other: the number of pixel rows per character is set in the CRT controller, while font height is in fact hardwired to 32 pixel rows and fonts of heights below that value are handled by padding their data with blanks when loaded to hardware for use by the character generator. One can change the setting in the CRT controller and it will update the screen contents accordingly regardless of the font loaded. The `v_clin' parameter is used by the `vgacon' driver to set the height of the character cell and then the cursor position within. Make the parameter explicit then, by defining a new `vc_cell_height' struct member of `vc_data', set it instead of `vc_font.height' from `v_clin' in the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver except where actual font data is accessed which as noted above is independent from the CRTC setting. This way the framebuffer console driver is free to ignore the `v_clin' parameter as irrelevant, as it always should have, avoiding any issues attempts to give the parameter a meaning there could have caused, such as one that has led to commit 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE"): "syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2], for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height larger than actual font height calculated by con_font_set() from ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates minimal amount of memory based on actual font height calculated by con_font_set(), use of vt_resizex() can cause UAF/OOB read for font data." The problem first appeared around Linux 2.5.66 which predates our repo history, but the origin could be identified with the old MIPS/Linux repo also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git> as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX code in `vt_ioctl' was updated as follows: if (clin) - video_font_height = clin; + vc->vc_font.height = clin; making the parameter apply to framebuffer devices as well, perhaps due to the use of "font" in the name of the original `video_font_height' variable. Use "cell" in the new struct member then to avoid ambiguity. References: [1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837 [2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3 Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # v2.6.12+ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-05-13 12:51:50 +03:00
vgacon_yres = height * c->vc_cell_height;
if (vga_video_type >= VIDEO_TYPE_VGAC) {
outb_p(VGA_CRTC_MAX_SCAN, vga_video_port_reg);
max_scan = inb_p(vga_video_port_val);
if (max_scan & 0x80)
scanlines <<= 1;
outb_p(VGA_CRTC_MODE, vga_video_port_reg);
mode = inb_p(vga_video_port_val);
if (mode & 0x04)
scanlines >>= 1;
scanlines -= 1;
scanlines_lo = scanlines & 0xff;
outb_p(VGA_CRTC_OVERFLOW, vga_video_port_reg);
r7 = inb_p(vga_video_port_val) & ~0x42;
if (scanlines & 0x100)
r7 |= 0x02;
if (scanlines & 0x200)
r7 |= 0x40;
/* deprotect registers */
outb_p(VGA_CRTC_V_SYNC_END, vga_video_port_reg);
vsync_end = inb_p(vga_video_port_val);
outb_p(VGA_CRTC_V_SYNC_END, vga_video_port_reg);
outb_p(vsync_end & ~0x80, vga_video_port_val);
}
outb_p(VGA_CRTC_H_DISP, vga_video_port_reg);
outb_p(width - 1, vga_video_port_val);
outb_p(VGA_CRTC_OFFSET, vga_video_port_reg);
outb_p(width >> 1, vga_video_port_val);
if (vga_video_type >= VIDEO_TYPE_VGAC) {
outb_p(VGA_CRTC_V_DISP_END, vga_video_port_reg);
outb_p(scanlines_lo, vga_video_port_val);
outb_p(VGA_CRTC_OVERFLOW, vga_video_port_reg);
outb_p(r7,vga_video_port_val);
/* reprotect registers */
outb_p(VGA_CRTC_V_SYNC_END, vga_video_port_reg);
outb_p(vsync_end, vga_video_port_val);
}
raw_spin_unlock_irqrestore(&vga_lock, flags);
return 0;
}
static int vgacon_switch(struct vc_data *c)
{
int x = c->vc_cols * VGA_FONTWIDTH;
vt: Fix character height handling with VT_RESIZEX Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter which is the number of pixel rows per character (cell) rather than the height of the font used. For framebuffer devices the two values are always the same, because the former is inferred from the latter one. For VGA used as a true text mode device these two parameters are independent from each other: the number of pixel rows per character is set in the CRT controller, while font height is in fact hardwired to 32 pixel rows and fonts of heights below that value are handled by padding their data with blanks when loaded to hardware for use by the character generator. One can change the setting in the CRT controller and it will update the screen contents accordingly regardless of the font loaded. The `v_clin' parameter is used by the `vgacon' driver to set the height of the character cell and then the cursor position within. Make the parameter explicit then, by defining a new `vc_cell_height' struct member of `vc_data', set it instead of `vc_font.height' from `v_clin' in the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver except where actual font data is accessed which as noted above is independent from the CRTC setting. This way the framebuffer console driver is free to ignore the `v_clin' parameter as irrelevant, as it always should have, avoiding any issues attempts to give the parameter a meaning there could have caused, such as one that has led to commit 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE"): "syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2], for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height larger than actual font height calculated by con_font_set() from ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates minimal amount of memory based on actual font height calculated by con_font_set(), use of vt_resizex() can cause UAF/OOB read for font data." The problem first appeared around Linux 2.5.66 which predates our repo history, but the origin could be identified with the old MIPS/Linux repo also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git> as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX code in `vt_ioctl' was updated as follows: if (clin) - video_font_height = clin; + vc->vc_font.height = clin; making the parameter apply to framebuffer devices as well, perhaps due to the use of "font" in the name of the original `video_font_height' variable. Use "cell" in the new struct member then to avoid ambiguity. References: [1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837 [2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3 Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # v2.6.12+ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-05-13 12:51:50 +03:00
int y = c->vc_rows * c->vc_cell_height;
int rows = screen_info.orig_video_lines * vga_default_font_height/
vt: Fix character height handling with VT_RESIZEX Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter which is the number of pixel rows per character (cell) rather than the height of the font used. For framebuffer devices the two values are always the same, because the former is inferred from the latter one. For VGA used as a true text mode device these two parameters are independent from each other: the number of pixel rows per character is set in the CRT controller, while font height is in fact hardwired to 32 pixel rows and fonts of heights below that value are handled by padding their data with blanks when loaded to hardware for use by the character generator. One can change the setting in the CRT controller and it will update the screen contents accordingly regardless of the font loaded. The `v_clin' parameter is used by the `vgacon' driver to set the height of the character cell and then the cursor position within. Make the parameter explicit then, by defining a new `vc_cell_height' struct member of `vc_data', set it instead of `vc_font.height' from `v_clin' in the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver except where actual font data is accessed which as noted above is independent from the CRTC setting. This way the framebuffer console driver is free to ignore the `v_clin' parameter as irrelevant, as it always should have, avoiding any issues attempts to give the parameter a meaning there could have caused, such as one that has led to commit 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE"): "syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2], for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height larger than actual font height calculated by con_font_set() from ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates minimal amount of memory based on actual font height calculated by con_font_set(), use of vt_resizex() can cause UAF/OOB read for font data." The problem first appeared around Linux 2.5.66 which predates our repo history, but the origin could be identified with the old MIPS/Linux repo also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git> as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX code in `vt_ioctl' was updated as follows: if (clin) - video_font_height = clin; + vc->vc_font.height = clin; making the parameter apply to framebuffer devices as well, perhaps due to the use of "font" in the name of the original `video_font_height' variable. Use "cell" in the new struct member then to avoid ambiguity. References: [1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837 [2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3 Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # v2.6.12+ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-05-13 12:51:50 +03:00
c->vc_cell_height;
/*
* We need to save screen size here as it's the only way
* we can spot the screen has been resized and we need to
* set size of freshly allocated screens ourselves.
*/
vga_video_num_columns = c->vc_cols;
vga_video_num_lines = c->vc_rows;
/* We can only copy out the size of the video buffer here,
* otherwise we get into VGA BIOS */
if (!vga_is_gfx) {
scr_memcpyw((u16 *) c->vc_origin, (u16 *) c->vc_screenbuf,
c->vc_screenbuf_size > vga_vram_size ?
vga_vram_size : c->vc_screenbuf_size);
if ((vgacon_xres != x || vgacon_yres != y) &&
(!(vga_video_num_columns % 2) &&
vga_video_num_columns <= screen_info.orig_video_cols &&
vga_video_num_lines <= rows))
vgacon_doresize(c, c->vc_cols, c->vc_rows);
}
return 0; /* Redrawing not needed */
}
static void vga_set_palette(struct vc_data *vc, const unsigned char *table)
{
int i, j;
vga_w(vgastate.vgabase, VGA_PEL_MSK, 0xff);
for (i = j = 0; i < 16; i++) {
vga_w(vgastate.vgabase, VGA_PEL_IW, table[i]);
vga_w(vgastate.vgabase, VGA_PEL_D, vc->vc_palette[j++] >> 2);
vga_w(vgastate.vgabase, VGA_PEL_D, vc->vc_palette[j++] >> 2);
vga_w(vgastate.vgabase, VGA_PEL_D, vc->vc_palette[j++] >> 2);
}
}
static void vgacon_set_palette(struct vc_data *vc, const unsigned char *table)
{
if (vga_video_type != VIDEO_TYPE_VGAC || vga_palette_blanked
|| !con_is_visible(vc))
return;
vga_set_palette(vc, table);
}
/* structure holding original VGA register settings */
static struct {
unsigned char SeqCtrlIndex; /* Sequencer Index reg. */
unsigned char CrtCtrlIndex; /* CRT-Contr. Index reg. */
unsigned char CrtMiscIO; /* Miscellaneous register */
unsigned char HorizontalTotal; /* CRT-Controller:00h */
unsigned char HorizDisplayEnd; /* CRT-Controller:01h */
unsigned char StartHorizRetrace; /* CRT-Controller:04h */
unsigned char EndHorizRetrace; /* CRT-Controller:05h */
unsigned char Overflow; /* CRT-Controller:07h */
unsigned char StartVertRetrace; /* CRT-Controller:10h */
unsigned char EndVertRetrace; /* CRT-Controller:11h */
unsigned char ModeControl; /* CRT-Controller:17h */
unsigned char ClockingMode; /* Seq-Controller:01h */
} vga_state;
static void vga_vesa_blank(struct vgastate *state, int mode)
{
/* save original values of VGA controller registers */
if (!vga_vesa_blanked) {
raw_spin_lock_irq(&vga_lock);
vga_state.SeqCtrlIndex = vga_r(state->vgabase, VGA_SEQ_I);
vga_state.CrtCtrlIndex = inb_p(vga_video_port_reg);
vga_state.CrtMiscIO = vga_r(state->vgabase, VGA_MIS_R);
raw_spin_unlock_irq(&vga_lock);
outb_p(0x00, vga_video_port_reg); /* HorizontalTotal */
vga_state.HorizontalTotal = inb_p(vga_video_port_val);
outb_p(0x01, vga_video_port_reg); /* HorizDisplayEnd */
vga_state.HorizDisplayEnd = inb_p(vga_video_port_val);
outb_p(0x04, vga_video_port_reg); /* StartHorizRetrace */
vga_state.StartHorizRetrace = inb_p(vga_video_port_val);
outb_p(0x05, vga_video_port_reg); /* EndHorizRetrace */
vga_state.EndHorizRetrace = inb_p(vga_video_port_val);
outb_p(0x07, vga_video_port_reg); /* Overflow */
vga_state.Overflow = inb_p(vga_video_port_val);
outb_p(0x10, vga_video_port_reg); /* StartVertRetrace */
vga_state.StartVertRetrace = inb_p(vga_video_port_val);
outb_p(0x11, vga_video_port_reg); /* EndVertRetrace */
vga_state.EndVertRetrace = inb_p(vga_video_port_val);
outb_p(0x17, vga_video_port_reg); /* ModeControl */
vga_state.ModeControl = inb_p(vga_video_port_val);
vga_state.ClockingMode = vga_rseq(state->vgabase, VGA_SEQ_CLOCK_MODE);
}
/* assure that video is enabled */
/* "0x20" is VIDEO_ENABLE_bit in register 01 of sequencer */
raw_spin_lock_irq(&vga_lock);
vga_wseq(state->vgabase, VGA_SEQ_CLOCK_MODE, vga_state.ClockingMode | 0x20);
/* test for vertical retrace in process.... */
if ((vga_state.CrtMiscIO & 0x80) == 0x80)
vga_w(state->vgabase, VGA_MIS_W, vga_state.CrtMiscIO & 0xEF);
/*
* Set <End of vertical retrace> to minimum (0) and
* <Start of vertical Retrace> to maximum (incl. overflow)
* Result: turn off vertical sync (VSync) pulse.
*/
if (mode & VESA_VSYNC_SUSPEND) {
outb_p(0x10, vga_video_port_reg); /* StartVertRetrace */
outb_p(0xff, vga_video_port_val); /* maximum value */
outb_p(0x11, vga_video_port_reg); /* EndVertRetrace */
outb_p(0x40, vga_video_port_val); /* minimum (bits 0..3) */
outb_p(0x07, vga_video_port_reg); /* Overflow */
outb_p(vga_state.Overflow | 0x84, vga_video_port_val); /* bits 9,10 of vert. retrace */
}
if (mode & VESA_HSYNC_SUSPEND) {
/*
* Set <End of horizontal retrace> to minimum (0) and
* <Start of horizontal Retrace> to maximum
* Result: turn off horizontal sync (HSync) pulse.
*/
outb_p(0x04, vga_video_port_reg); /* StartHorizRetrace */
outb_p(0xff, vga_video_port_val); /* maximum */
outb_p(0x05, vga_video_port_reg); /* EndHorizRetrace */
outb_p(0x00, vga_video_port_val); /* minimum (0) */
}
/* restore both index registers */
vga_w(state->vgabase, VGA_SEQ_I, vga_state.SeqCtrlIndex);
outb_p(vga_state.CrtCtrlIndex, vga_video_port_reg);
raw_spin_unlock_irq(&vga_lock);
}
static void vga_vesa_unblank(struct vgastate *state)
{
/* restore original values of VGA controller registers */
raw_spin_lock_irq(&vga_lock);
vga_w(state->vgabase, VGA_MIS_W, vga_state.CrtMiscIO);
outb_p(0x00, vga_video_port_reg); /* HorizontalTotal */
outb_p(vga_state.HorizontalTotal, vga_video_port_val);
outb_p(0x01, vga_video_port_reg); /* HorizDisplayEnd */
outb_p(vga_state.HorizDisplayEnd, vga_video_port_val);
outb_p(0x04, vga_video_port_reg); /* StartHorizRetrace */
outb_p(vga_state.StartHorizRetrace, vga_video_port_val);
outb_p(0x05, vga_video_port_reg); /* EndHorizRetrace */
outb_p(vga_state.EndHorizRetrace, vga_video_port_val);
outb_p(0x07, vga_video_port_reg); /* Overflow */
outb_p(vga_state.Overflow, vga_video_port_val);
outb_p(0x10, vga_video_port_reg); /* StartVertRetrace */
outb_p(vga_state.StartVertRetrace, vga_video_port_val);
outb_p(0x11, vga_video_port_reg); /* EndVertRetrace */
outb_p(vga_state.EndVertRetrace, vga_video_port_val);
outb_p(0x17, vga_video_port_reg); /* ModeControl */
outb_p(vga_state.ModeControl, vga_video_port_val);
/* ClockingMode */
vga_wseq(state->vgabase, VGA_SEQ_CLOCK_MODE, vga_state.ClockingMode);
/* restore index/control registers */
vga_w(state->vgabase, VGA_SEQ_I, vga_state.SeqCtrlIndex);
outb_p(vga_state.CrtCtrlIndex, vga_video_port_reg);
raw_spin_unlock_irq(&vga_lock);
}
static void vga_pal_blank(struct vgastate *state)
{
int i;
vga_w(state->vgabase, VGA_PEL_MSK, 0xff);
for (i = 0; i < 16; i++) {
vga_w(state->vgabase, VGA_PEL_IW, i);
vga_w(state->vgabase, VGA_PEL_D, 0);
vga_w(state->vgabase, VGA_PEL_D, 0);
vga_w(state->vgabase, VGA_PEL_D, 0);
}
}
static int vgacon_blank(struct vc_data *c, int blank, int mode_switch)
{
switch (blank) {
case 0: /* Unblank */
if (vga_vesa_blanked) {
vga_vesa_unblank(&vgastate);
vga_vesa_blanked = 0;
}
if (vga_palette_blanked) {
vga_set_palette(c, color_table);
vga_palette_blanked = false;
return 0;
}
vga_is_gfx = false;
/* Tell console.c that it has to restore the screen itself */
return 1;
case 1: /* Normal blanking */
case -1: /* Obsolete */
if (!mode_switch && vga_video_type == VIDEO_TYPE_VGAC) {
vga_pal_blank(&vgastate);
vga_palette_blanked = true;
return 0;
}
vgacon_set_origin(c);
scr_memsetw((void *) vga_vram_base, BLANK,
c->vc_screenbuf_size);
if (mode_switch)
vga_is_gfx = true;
return 1;
default: /* VESA blanking */
if (vga_video_type == VIDEO_TYPE_VGAC) {
vga_vesa_blank(&vgastate, blank - 1);
vga_vesa_blanked = blank;
}
return 0;
}
}
/*
* PIO_FONT support.
*
* The font loading code goes back to the codepage package by
* Joel Hoffman (joel@wam.umd.edu). (He reports that the original
* reference is: "From: p. 307 of _Programmer's Guide to PC & PS/2
* Video Systems_ by Richard Wilton. 1987. Microsoft Press".)
*
* Change for certain monochrome monitors by Yury Shevchuck
* (sizif@botik.yaroslavl.su).
*/
#define colourmap 0xa0000
/* Pauline Middelink <middelin@polyware.iaf.nl> reports that we
should use 0xA0000 for the bwmap as well.. */
#define blackwmap 0xa0000
#define cmapsz 8192
static int vgacon_do_font_op(struct vgastate *state, char *arg, int set,
bool ch512)
{
unsigned short video_port_status = vga_video_port_reg + 6;
int font_select = 0x00, beg, i;
char *charmap;
bool clear_attribs = false;
if (vga_video_type != VIDEO_TYPE_EGAM) {
charmap = (char *) VGA_MAP_MEM(colourmap, 0);
beg = 0x0e;
} else {
charmap = (char *) VGA_MAP_MEM(blackwmap, 0);
beg = 0x0a;
}
/*
* All fonts are loaded in slot 0 (0:1 for 512 ch)
*/
if (!arg)
return -EINVAL; /* Return to default font not supported */
font_select = ch512 ? 0x04 : 0x00;
raw_spin_lock_irq(&vga_lock);
/* First, the Sequencer */
vga_wseq(state->vgabase, VGA_SEQ_RESET, 0x1);
/* CPU writes only to map 2 */
vga_wseq(state->vgabase, VGA_SEQ_PLANE_WRITE, 0x04);
/* Sequential addressing */
vga_wseq(state->vgabase, VGA_SEQ_MEMORY_MODE, 0x07);
/* Clear synchronous reset */
vga_wseq(state->vgabase, VGA_SEQ_RESET, 0x03);
/* Now, the graphics controller, select map 2 */
vga_wgfx(state->vgabase, VGA_GFX_PLANE_READ, 0x02);
/* disable odd-even addressing */
vga_wgfx(state->vgabase, VGA_GFX_MODE, 0x00);
/* map start at A000:0000 */
vga_wgfx(state->vgabase, VGA_GFX_MISC, 0x00);
raw_spin_unlock_irq(&vga_lock);
if (arg) {
if (set)
for (i = 0; i < cmapsz; i++) {
vga_writeb(arg[i], charmap + i);
cond_resched();
}
else
for (i = 0; i < cmapsz; i++) {
arg[i] = vga_readb(charmap + i);
cond_resched();
}
/*
* In 512-character mode, the character map is not contiguous if
* we want to remain EGA compatible -- which we do
*/
if (ch512) {
charmap += 2 * cmapsz;
arg += cmapsz;
if (set)
for (i = 0; i < cmapsz; i++) {
vga_writeb(arg[i], charmap + i);
cond_resched();
}
else
for (i = 0; i < cmapsz; i++) {
arg[i] = vga_readb(charmap + i);
cond_resched();
}
}
}
raw_spin_lock_irq(&vga_lock);
/* First, the sequencer, Synchronous reset */
vga_wseq(state->vgabase, VGA_SEQ_RESET, 0x01);
/* CPU writes to maps 0 and 1 */
vga_wseq(state->vgabase, VGA_SEQ_PLANE_WRITE, 0x03);
/* odd-even addressing */
vga_wseq(state->vgabase, VGA_SEQ_MEMORY_MODE, 0x03);
/* Character Map Select */
if (set)
vga_wseq(state->vgabase, VGA_SEQ_CHARACTER_MAP, font_select);
/* clear synchronous reset */
vga_wseq(state->vgabase, VGA_SEQ_RESET, 0x03);
/* Now, the graphics controller, select map 0 for CPU */
vga_wgfx(state->vgabase, VGA_GFX_PLANE_READ, 0x00);
/* enable even-odd addressing */
vga_wgfx(state->vgabase, VGA_GFX_MODE, 0x10);
/* map starts at b800:0 or b000:0 */
vga_wgfx(state->vgabase, VGA_GFX_MISC, beg);
/* if 512 char mode is already enabled don't re-enable it. */
if ((set) && (ch512 != vga_512_chars)) {
vga_512_chars = ch512;
/* 256-char: enable intensity bit
512-char: disable intensity bit */
inb_p(video_port_status); /* clear address flip-flop */
/* color plane enable register */
vga_wattr(state->vgabase, VGA_ATC_PLANE_ENABLE, ch512 ? 0x07 : 0x0f);
/* Wilton (1987) mentions the following; I don't know what
it means, but it works, and it appears necessary */
inb_p(video_port_status);
vga_wattr(state->vgabase, VGA_AR_ENABLE_DISPLAY, 0);
clear_attribs = true;
}
raw_spin_unlock_irq(&vga_lock);
if (clear_attribs) {
for (i = 0; i < MAX_NR_CONSOLES; i++) {
struct vc_data *c = vc_cons[i].d;
if (c && c->vc_sw == &vga_con) {
/* force hi font mask to 0, so we always clear
the bit on either transition */
c->vc_hi_font_mask = 0x00;
clear_buffer_attributes(c);
c->vc_hi_font_mask = ch512 ? 0x0800 : 0;
}
}
}
return 0;
}
/*
* Adjust the screen to fit a font of a certain height
*/
static int vgacon_adjust_height(struct vc_data *vc, unsigned fontheight)
{
unsigned char ovr, vde, fsr;
int rows, maxscan, i;
rows = vc->vc_scan_lines / fontheight; /* Number of video rows we end up with */
maxscan = rows * fontheight - 1; /* Scan lines to actually display-1 */
/* Reprogram the CRTC for the new font size
Note: the attempt to read the overflow register will fail
on an EGA, but using 0xff for the previous value appears to
be OK for EGA text modes in the range 257-512 scan lines, so I
guess we don't need to worry about it.
The same applies for the spill bits in the font size and cursor
registers; they are write-only on EGA, but it appears that they
are all don't care bits on EGA, so I guess it doesn't matter. */
raw_spin_lock_irq(&vga_lock);
outb_p(0x07, vga_video_port_reg); /* CRTC overflow register */
ovr = inb_p(vga_video_port_val);
outb_p(0x09, vga_video_port_reg); /* Font size register */
fsr = inb_p(vga_video_port_val);
raw_spin_unlock_irq(&vga_lock);
vde = maxscan & 0xff; /* Vertical display end reg */
ovr = (ovr & 0xbd) + /* Overflow register */
((maxscan & 0x100) >> 7) + ((maxscan & 0x200) >> 3);
fsr = (fsr & 0xe0) + (fontheight - 1); /* Font size register */
raw_spin_lock_irq(&vga_lock);
outb_p(0x07, vga_video_port_reg); /* CRTC overflow register */
outb_p(ovr, vga_video_port_val);
outb_p(0x09, vga_video_port_reg); /* Font size */
outb_p(fsr, vga_video_port_val);
outb_p(0x12, vga_video_port_reg); /* Vertical display limit */
outb_p(vde, vga_video_port_val);
raw_spin_unlock_irq(&vga_lock);
vga_video_font_height = fontheight;
for (i = 0; i < MAX_NR_CONSOLES; i++) {
struct vc_data *c = vc_cons[i].d;
if (c && c->vc_sw == &vga_con) {
if (con_is_visible(c)) {
/* void size to cause regs to be rewritten */
cursor_size_lastfrom = 0;
cursor_size_lastto = 0;
c->vc_sw->con_cursor(c, CM_DRAW);
}
vt: Fix character height handling with VT_RESIZEX Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter which is the number of pixel rows per character (cell) rather than the height of the font used. For framebuffer devices the two values are always the same, because the former is inferred from the latter one. For VGA used as a true text mode device these two parameters are independent from each other: the number of pixel rows per character is set in the CRT controller, while font height is in fact hardwired to 32 pixel rows and fonts of heights below that value are handled by padding their data with blanks when loaded to hardware for use by the character generator. One can change the setting in the CRT controller and it will update the screen contents accordingly regardless of the font loaded. The `v_clin' parameter is used by the `vgacon' driver to set the height of the character cell and then the cursor position within. Make the parameter explicit then, by defining a new `vc_cell_height' struct member of `vc_data', set it instead of `vc_font.height' from `v_clin' in the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver except where actual font data is accessed which as noted above is independent from the CRTC setting. This way the framebuffer console driver is free to ignore the `v_clin' parameter as irrelevant, as it always should have, avoiding any issues attempts to give the parameter a meaning there could have caused, such as one that has led to commit 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE"): "syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2], for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height larger than actual font height calculated by con_font_set() from ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates minimal amount of memory based on actual font height calculated by con_font_set(), use of vt_resizex() can cause UAF/OOB read for font data." The problem first appeared around Linux 2.5.66 which predates our repo history, but the origin could be identified with the old MIPS/Linux repo also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git> as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX code in `vt_ioctl' was updated as follows: if (clin) - video_font_height = clin; + vc->vc_font.height = clin; making the parameter apply to framebuffer devices as well, perhaps due to the use of "font" in the name of the original `video_font_height' variable. Use "cell" in the new struct member then to avoid ambiguity. References: [1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837 [2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3 Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # v2.6.12+ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-05-13 12:51:50 +03:00
c->vc_font.height = c->vc_cell_height = fontheight;
vc_resize(c, 0, rows); /* Adjust console size */
}
}
return 0;
}
static int vgacon_font_set(struct vc_data *c, struct console_font *font,
unsigned int flags)
{
unsigned charcount = font->charcount;
int rc;
if (vga_video_type < VIDEO_TYPE_EGAM)
return -EINVAL;
if (font->width != VGA_FONTWIDTH ||
(charcount != 256 && charcount != 512))
return -EINVAL;
rc = vgacon_do_font_op(&vgastate, font->data, 1, charcount == 512);
if (rc)
return rc;
if (!(flags & KD_FONT_FLAG_DONT_RECALC))
rc = vgacon_adjust_height(c, font->height);
return rc;
}
static int vgacon_font_get(struct vc_data *c, struct console_font *font)
{
if (vga_video_type < VIDEO_TYPE_EGAM)
return -EINVAL;
font->width = VGA_FONTWIDTH;
font->height = c->vc_font.height;
font->charcount = vga_512_chars ? 512 : 256;
if (!font->data)
return 0;
return vgacon_do_font_op(&vgastate, font->data, 0, vga_512_chars);
}
static int vgacon_resize(struct vc_data *c, unsigned int width,
unsigned int height, unsigned int user)
{
vgacon: Fix a UAF in vgacon_invert_region When syzkaller tests, there is a UAF: BUG: KASan: use after free in vgacon_invert_region+0x9d/0x110 at addr ffff880000100000 Read of size 2 by task syz-executor.1/16489 page:ffffea0000004000 count:0 mapcount:-127 mapping: (null) index:0x0 page flags: 0xfffff00000000() page dumped because: kasan: bad access detected CPU: 1 PID: 16489 Comm: syz-executor.1 Not tainted Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 Call Trace: [<ffffffffb119f309>] dump_stack+0x1e/0x20 [<ffffffffb04af957>] kasan_report+0x577/0x950 [<ffffffffb04ae652>] __asan_load2+0x62/0x80 [<ffffffffb090f26d>] vgacon_invert_region+0x9d/0x110 [<ffffffffb0a39d95>] invert_screen+0xe5/0x470 [<ffffffffb0a21dcb>] set_selection+0x44b/0x12f0 [<ffffffffb0a3bfae>] tioclinux+0xee/0x490 [<ffffffffb0a1d114>] vt_ioctl+0xff4/0x2670 [<ffffffffb0a0089a>] tty_ioctl+0x46a/0x1a10 [<ffffffffb052db3d>] do_vfs_ioctl+0x5bd/0xc40 [<ffffffffb052e2f2>] SyS_ioctl+0x132/0x170 [<ffffffffb11c9b1b>] system_call_fastpath+0x22/0x27 Memory state around the buggy address: ffff8800000fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8800000fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff880000100000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff It can be reproduce in the linux mainline by the program: #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <fcntl.h> #include <sys/types.h> #include <sys/stat.h> #include <sys/ioctl.h> #include <linux/vt.h> struct tiocl_selection { unsigned short xs; /* X start */ unsigned short ys; /* Y start */ unsigned short xe; /* X end */ unsigned short ye; /* Y end */ unsigned short sel_mode; /* selection mode */ }; #define TIOCL_SETSEL 2 struct tiocl { unsigned char type; unsigned char pad; struct tiocl_selection sel; }; int main() { int fd = 0; const char *dev = "/dev/char/4:1"; struct vt_consize v = {0}; struct tiocl tioc = {0}; fd = open(dev, O_RDWR, 0); v.v_rows = 3346; ioctl(fd, VT_RESIZEX, &v); tioc.type = TIOCL_SETSEL; ioctl(fd, TIOCLINUX, &tioc); return 0; } When resize the screen, update the 'vc->vc_size_row' to the new_row_size, but when 'set_origin' in 'vgacon_set_origin', vgacon use 'vga_vram_base' for 'vc_origin' and 'vc_visible_origin', not 'vc_screenbuf'. It maybe smaller than 'vc_screenbuf'. When TIOCLINUX, use the new_row_size to calc the offset, it maybe larger than the vga_vram_size in vgacon driver, then bad access. Also, if set an larger screenbuf firstly, then set an more larger screenbuf, when copy old_origin to new_origin, a bad access may happen. So, If the screen size larger than vga_vram, resize screen should be failed. This alse fix CVE-2020-8649 and CVE-2020-8647. Linus pointed out that overflow checking seems absent. We're saved by the existing bounds checks in vc_do_resize() with rather strict limits: if (cols > VC_RESIZE_MAXCOL || lines > VC_RESIZE_MAXROW) return -EINVAL; Fixes: 0aec4867dca14 ("[PATCH] SVGATextMode fix") Reference: CVE-2020-8647 and CVE-2020-8649 Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com> [danvet: augment commit message to point out overflow safety] Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200304022429.37738-1-zhangxiaoxu5@huawei.com
2020-03-04 05:24:29 +03:00
if ((width << 1) * height > vga_vram_size)
return -EINVAL;
if (user) {
/*
* Ho ho! Someone (svgatextmode, eh?) may have reprogrammed
* the video mode! Set the new defaults then and go away.
*/
screen_info.orig_video_cols = width;
screen_info.orig_video_lines = height;
vt: Fix character height handling with VT_RESIZEX Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter which is the number of pixel rows per character (cell) rather than the height of the font used. For framebuffer devices the two values are always the same, because the former is inferred from the latter one. For VGA used as a true text mode device these two parameters are independent from each other: the number of pixel rows per character is set in the CRT controller, while font height is in fact hardwired to 32 pixel rows and fonts of heights below that value are handled by padding their data with blanks when loaded to hardware for use by the character generator. One can change the setting in the CRT controller and it will update the screen contents accordingly regardless of the font loaded. The `v_clin' parameter is used by the `vgacon' driver to set the height of the character cell and then the cursor position within. Make the parameter explicit then, by defining a new `vc_cell_height' struct member of `vc_data', set it instead of `vc_font.height' from `v_clin' in the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver except where actual font data is accessed which as noted above is independent from the CRTC setting. This way the framebuffer console driver is free to ignore the `v_clin' parameter as irrelevant, as it always should have, avoiding any issues attempts to give the parameter a meaning there could have caused, such as one that has led to commit 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE"): "syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2], for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height larger than actual font height calculated by con_font_set() from ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates minimal amount of memory based on actual font height calculated by con_font_set(), use of vt_resizex() can cause UAF/OOB read for font data." The problem first appeared around Linux 2.5.66 which predates our repo history, but the origin could be identified with the old MIPS/Linux repo also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git> as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX code in `vt_ioctl' was updated as follows: if (clin) - video_font_height = clin; + vc->vc_font.height = clin; making the parameter apply to framebuffer devices as well, perhaps due to the use of "font" in the name of the original `video_font_height' variable. Use "cell" in the new struct member then to avoid ambiguity. References: [1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837 [2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3 Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # v2.6.12+ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-05-13 12:51:50 +03:00
vga_default_font_height = c->vc_cell_height;
return 0;
}
if (width % 2 || width > screen_info.orig_video_cols ||
height > (screen_info.orig_video_lines * vga_default_font_height)/
vt: Fix character height handling with VT_RESIZEX Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter which is the number of pixel rows per character (cell) rather than the height of the font used. For framebuffer devices the two values are always the same, because the former is inferred from the latter one. For VGA used as a true text mode device these two parameters are independent from each other: the number of pixel rows per character is set in the CRT controller, while font height is in fact hardwired to 32 pixel rows and fonts of heights below that value are handled by padding their data with blanks when loaded to hardware for use by the character generator. One can change the setting in the CRT controller and it will update the screen contents accordingly regardless of the font loaded. The `v_clin' parameter is used by the `vgacon' driver to set the height of the character cell and then the cursor position within. Make the parameter explicit then, by defining a new `vc_cell_height' struct member of `vc_data', set it instead of `vc_font.height' from `v_clin' in the VT_RESIZEX ioctl, and then use it throughout the `vgacon' driver except where actual font data is accessed which as noted above is independent from the CRTC setting. This way the framebuffer console driver is free to ignore the `v_clin' parameter as irrelevant, as it always should have, avoiding any issues attempts to give the parameter a meaning there could have caused, such as one that has led to commit 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE"): "syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2], for vt_resizex() from ioctl(VT_RESIZEX) allows setting font height larger than actual font height calculated by con_font_set() from ioctl(PIO_FONT). Since fbcon_set_font() from con_font_set() allocates minimal amount of memory based on actual font height calculated by con_font_set(), use of vt_resizex() can cause UAF/OOB read for font data." The problem first appeared around Linux 2.5.66 which predates our repo history, but the origin could be identified with the old MIPS/Linux repo also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git> as commit 9736a3546de7 ("Merge with Linux 2.5.66."), where VT_RESIZEX code in `vt_ioctl' was updated as follows: if (clin) - video_font_height = clin; + vc->vc_font.height = clin; making the parameter apply to framebuffer devices as well, perhaps due to the use of "font" in the name of the original `video_font_height' variable. Use "cell" in the new struct member then to avoid ambiguity. References: [1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837 [2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3 Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # v2.6.12+ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-05-13 12:51:50 +03:00
c->vc_cell_height)
return -EINVAL;
if (con_is_visible(c) && !vga_is_gfx) /* who knows */
vgacon_doresize(c, width, height);
return 0;
}
static int vgacon_set_origin(struct vc_data *c)
{
if (vga_is_gfx || /* We don't play origin tricks in graphic modes */
(console_blanked && !vga_palette_blanked)) /* Nor we write to blanked screens */
return 0;
c->vc_origin = c->vc_visible_origin = vga_vram_base;
vga_set_mem_top(c);
vga_rolled_over = 0;
return 1;
}
static void vgacon_save_screen(struct vc_data *c)
{
static int vga_bootup_console = 0;
if (!vga_bootup_console) {
/* This is a gross hack, but here is the only place we can
* set bootup console parameters without messing up generic
* console initialization routines.
*/
vga_bootup_console = 1;
c->state.x = screen_info.orig_x;
c->state.y = screen_info.orig_y;
}
/* We can't copy in more than the size of the video buffer,
* or we'll be copying in VGA BIOS */
if (!vga_is_gfx)
scr_memcpyw((u16 *) c->vc_screenbuf, (u16 *) c->vc_origin,
c->vc_screenbuf_size > vga_vram_size ? vga_vram_size : c->vc_screenbuf_size);
}
static bool vgacon_scroll(struct vc_data *c, unsigned int t, unsigned int b,
enum con_scroll dir, unsigned int lines)
{
unsigned long oldo;
unsigned int delta;
if (t || b != c->vc_rows || vga_is_gfx || c->vc_mode != KD_TEXT)
return false;
if (!vga_hardscroll_enabled || lines >= c->vc_rows / 2)
return false;
vgacon_restore_screen(c);
oldo = c->vc_origin;
delta = lines * c->vc_size_row;
if (dir == SM_UP) {
if (c->vc_scr_end + delta >= vga_vram_end) {
scr_memcpyw((u16 *) vga_vram_base,
(u16 *) (oldo + delta),
c->vc_screenbuf_size - delta);
c->vc_origin = vga_vram_base;
vga_rolled_over = oldo - vga_vram_base;
} else
c->vc_origin += delta;
scr_memsetw((u16 *) (c->vc_origin + c->vc_screenbuf_size -
delta), c->vc_video_erase_char,
delta);
} else {
if (oldo - delta < vga_vram_base) {
scr_memmovew((u16 *) (vga_vram_end -
c->vc_screenbuf_size +
delta), (u16 *) oldo,
c->vc_screenbuf_size - delta);
c->vc_origin = vga_vram_end - c->vc_screenbuf_size;
vga_rolled_over = 0;
} else
c->vc_origin -= delta;
c->vc_scr_end = c->vc_origin + c->vc_screenbuf_size;
scr_memsetw((u16 *) (c->vc_origin), c->vc_video_erase_char,
delta);
}
c->vc_scr_end = c->vc_origin + c->vc_screenbuf_size;
c->vc_visible_origin = c->vc_origin;
vga_set_mem_top(c);
c->vc_pos = (c->vc_pos - oldo) + c->vc_origin;
return true;
}
/*
* The console `switch' structure for the VGA based console
*/
static void vgacon_clear(struct vc_data *vc, int sy, int sx, int height,
int width) { }
static void vgacon_putc(struct vc_data *vc, int c, int ypos, int xpos) { }
static void vgacon_putcs(struct vc_data *vc, const unsigned short *s,
int count, int ypos, int xpos) { }
const struct consw vga_con = {
.owner = THIS_MODULE,
.con_startup = vgacon_startup,
.con_init = vgacon_init,
.con_deinit = vgacon_deinit,
.con_clear = vgacon_clear,
.con_putc = vgacon_putc,
.con_putcs = vgacon_putcs,
.con_cursor = vgacon_cursor,
.con_scroll = vgacon_scroll,
.con_switch = vgacon_switch,
.con_blank = vgacon_blank,
.con_font_set = vgacon_font_set,
.con_font_get = vgacon_font_get,
.con_resize = vgacon_resize,
.con_set_palette = vgacon_set_palette,
.con_scrolldelta = vgacon_scrolldelta,
.con_set_origin = vgacon_set_origin,
.con_save_screen = vgacon_save_screen,
.con_build_attr = vgacon_build_attr,
.con_invert_region = vgacon_invert_region,
};
EXPORT_SYMBOL(vga_con);
MODULE_LICENSE("GPL");